Ich musste einmal ein Dokument verschicken, für dessen Öffnung durch den Empfänger zwei Notare erforderlich waren, die zuvor meine Identität verifizieren mussten. Nicht einer. Zwei. Und keiner konnte es allein öffnen. Die Schlüssel wurden zwischen ihnen aufgeteilt. Ich erinnere mich, dass ich dachte, das sei entweder paranoid oder das ehrlichste Sicherheitsdesign, das ich je gesehen hatte.
Dieses Gefühl kam wieder, als ich anfing, über Newtons SecureEnvelope-Struktur zu lesen. Ein Nutzer verschlüsselt sensible Daten mit dem Threshold-HPKE-Öffentlichen-Schlüssel des Systems, wobei X25519 und ChaCha20-Poly1305 verwendet werden. Dieser verschlüsselte Block wird dann in ein SecureEnvelope verpackt, das es über seine AAD-Konstruktion an einen bestimmten Policy-Client und eine Chain-ID bindet. Wenn jemand eines der beiden Felder verändert, schlägt die Entschlüsselung fehl. Danach wird das Envelope an das Gateway hochgeladen, und Operatoren können es nur gemeinsam entschlüsseln, wobei jede Person einen Anteil aus ihrem DKG-Schlüssel beisteuert. Nie hält ein einzelner Operator den vollständigen Schlüssel.
Was jedoch meine Aufmerksamkeit auf sich zog, war die Anforderung an die doppelte Signatur. Sowohl der Endbenutzer als auch das dApp müssen sich mit Ed25519 signieren lassen, bevor Operatoren überhaupt versuchen, zu entschlüsseln. Allein eine gestohlene Referenz-ID reicht nicht. Also schützt das System nicht nur Daten vor Außenstehenden. Es schützt sie auch vor nicht autorisierter Nutzung durch Insidern.
Da musste ich kurz innehalten. Die meisten Datenschutzebenen hören bei der Verschlüsselung auf. Newton fügt eine zusätzliche Ebene hinzu, die sagt, dass die Entschlüsselung selbst eine Autorisierung von beiden Parteien erfordert. Das verschiebt die Vertrauensgrenze. Man braucht nicht nur, dass die Mathematik stimmt. Man braucht auch zwei unabhängige Akteure, die zustimmen, dass diese konkrete Auswertung fortgesetzt werden soll. Ich bin noch immer nicht sicher, ob das das System robuster macht oder ob es nur eine weitere Abhängigkeit hinzufügt. Vermutlich beides.
#newt $NEWT @NewtonProtocol
Dieses Gefühl kam wieder, als ich anfing, über Newtons SecureEnvelope-Struktur zu lesen. Ein Nutzer verschlüsselt sensible Daten mit dem Threshold-HPKE-Öffentlichen-Schlüssel des Systems, wobei X25519 und ChaCha20-Poly1305 verwendet werden. Dieser verschlüsselte Block wird dann in ein SecureEnvelope verpackt, das es über seine AAD-Konstruktion an einen bestimmten Policy-Client und eine Chain-ID bindet. Wenn jemand eines der beiden Felder verändert, schlägt die Entschlüsselung fehl. Danach wird das Envelope an das Gateway hochgeladen, und Operatoren können es nur gemeinsam entschlüsseln, wobei jede Person einen Anteil aus ihrem DKG-Schlüssel beisteuert. Nie hält ein einzelner Operator den vollständigen Schlüssel.
Was jedoch meine Aufmerksamkeit auf sich zog, war die Anforderung an die doppelte Signatur. Sowohl der Endbenutzer als auch das dApp müssen sich mit Ed25519 signieren lassen, bevor Operatoren überhaupt versuchen, zu entschlüsseln. Allein eine gestohlene Referenz-ID reicht nicht. Also schützt das System nicht nur Daten vor Außenstehenden. Es schützt sie auch vor nicht autorisierter Nutzung durch Insidern.
Da musste ich kurz innehalten. Die meisten Datenschutzebenen hören bei der Verschlüsselung auf. Newton fügt eine zusätzliche Ebene hinzu, die sagt, dass die Entschlüsselung selbst eine Autorisierung von beiden Parteien erfordert. Das verschiebt die Vertrauensgrenze. Man braucht nicht nur, dass die Mathematik stimmt. Man braucht auch zwei unabhängige Akteure, die zustimmen, dass diese konkrete Auswertung fortgesetzt werden soll. Ich bin noch immer nicht sicher, ob das das System robuster macht oder ob es nur eine weitere Abhängigkeit hinzufügt. Vermutlich beides.
#newt $NEWT @NewtonProtocol