Ich habe einmal ein Extra-Wallet verwendet, um einen Test-Task laufen zu lassen, und dann die Tab geschlossen. Zwei Tage später waren das Portfolio-Bild und einige temporäre Datensätze noch in der Verlaufsliste der Requests vorhanden. Aus solchen kleinen Fehlern heraus sehe ich den „ephemeral“-Teil von Newton Protocol als sehr realistisch: Einmal-Daten, die lange leben, werden früher oder später zu einer Schwachstelle.
Das Bemerkenswerte ist, dass Newton Protocol diese Thematik nicht im Vagen lässt. Die Dokumentation trennt Privacy in 3 Streams: identity, confidential und ephemeral; dabei ist ephemeral nur für 1 Task gedacht. Es braucht kein separates Upload, keine onchain-Registrierung, und die Daten werden direkt in wasm_args unter dem Bereich _newton.privacy abgelegt.
Das ist der Punkt, an dem das Projekt sehr nah am Problem ist. In vielen Krypto-Produkten wird ein Snapshot des Kontostands, der um 9 Uhr morgens gemacht wurde, oft sehr lange aufbewahrt, obwohl der Wert zu diesem Zeitpunkt manchmal nur noch wenige Minuten aktuell ist. Newton Protocol wählt den Weg, dass das Gateway den Teil _newton bereits vorab abtrennt, der Operator lokal entschlüsselt und dann den Plaintext in data.privacy einfügt, sodass die Policy genau für diesen Task korrekt lesen kann.
Der technische Teil ist auch klar genug, um ihn zu prüfen. Das Projekt verwendet HPKE mit den drei explizit genannten Komponenten: X25519, HKDF SHA256 und ChaCha20 Poly1305. Außerdem wird der Ciphertext an policy_client und chain_id gebunden, um das Risiko zu verringern, ihn im falschen Kontext zu verwenden. Das Gute liegt darin, dass Lebensdauer und Datenumfang bereits beim Senden begrenzt werden.
Ich bin dennoch vorsichtig. Wenn das Integrationsteam noch unordentlich loggt, könnte die ephemeral-Daten sogar länger eine längere Lebensdauer bekommen, als beabsichtigt. Aber betrachtet man allein die Ebene des Designs: Newton Protocol behebt gerade einen alten Fehler der Krypto-Welt. Informationen, die nur für 1 Task gebraucht werden, sollten nicht zu Lagerbeständen des Systems werden.
@NewtonProtocol #newt $NEWT $EVAA $POWER
Das Bemerkenswerte ist, dass Newton Protocol diese Thematik nicht im Vagen lässt. Die Dokumentation trennt Privacy in 3 Streams: identity, confidential und ephemeral; dabei ist ephemeral nur für 1 Task gedacht. Es braucht kein separates Upload, keine onchain-Registrierung, und die Daten werden direkt in wasm_args unter dem Bereich _newton.privacy abgelegt.
Das ist der Punkt, an dem das Projekt sehr nah am Problem ist. In vielen Krypto-Produkten wird ein Snapshot des Kontostands, der um 9 Uhr morgens gemacht wurde, oft sehr lange aufbewahrt, obwohl der Wert zu diesem Zeitpunkt manchmal nur noch wenige Minuten aktuell ist. Newton Protocol wählt den Weg, dass das Gateway den Teil _newton bereits vorab abtrennt, der Operator lokal entschlüsselt und dann den Plaintext in data.privacy einfügt, sodass die Policy genau für diesen Task korrekt lesen kann.
Der technische Teil ist auch klar genug, um ihn zu prüfen. Das Projekt verwendet HPKE mit den drei explizit genannten Komponenten: X25519, HKDF SHA256 und ChaCha20 Poly1305. Außerdem wird der Ciphertext an policy_client und chain_id gebunden, um das Risiko zu verringern, ihn im falschen Kontext zu verwenden. Das Gute liegt darin, dass Lebensdauer und Datenumfang bereits beim Senden begrenzt werden.
Ich bin dennoch vorsichtig. Wenn das Integrationsteam noch unordentlich loggt, könnte die ephemeral-Daten sogar länger eine längere Lebensdauer bekommen, als beabsichtigt. Aber betrachtet man allein die Ebene des Designs: Newton Protocol behebt gerade einen alten Fehler der Krypto-Welt. Informationen, die nur für 1 Task gebraucht werden, sollten nicht zu Lagerbeständen des Systems werden.
@NewtonProtocol #newt $NEWT $EVAA $POWER