Was ist die sicherste Möglichkeit für eine Partei, 4 Bytes in weniger als 40 Bytes zu verschlüsseln, die öffentlich verfügbar sein werden?
Ich habe ein Projekt, in dem ein Benutzer ein U32 verschlüsselt in einer Blockchain speichern muss, damit er es selbst wiederherstellen kann: Der Benutzer hat immer seinen Schlüssel zur Verfügung, kann aber den U32-Wert "vergessen". Keine andere Partei muss die Informationen entschlüsseln, aber der Klartext wird schließlich auch in der Kette öffentlich sein.
Der Benutzer hat einen Entropiesamen, aus dem eine unendliche Anzahl von Schlüsseln beliebiger Größe deterministisch abgeleitet werden kann. Ich wollte einen einzelnen AES-Block verwenden, aber mir kam der Gedanke, dass auch ein einfaches XOR ausreichen würde. Gibt es einen Grund, etwas Komplizierteres zu tun, wenn der Benutzer jedes Mal, wenn er diese Art von Operation ausführt, einen eindeutigen "Schlüssel" ableitet?
Antworten
Die offensichtliche Antwort ist die Verwendung eines einmaligen Pads . Wenn Sie wirklich einen eindeutigen zufälligen 4-Byte-Schlüssel für jeden 4-Byte-Block verwenden, ist dieser nachweislich sicher.
Der Benutzer hat einen Entropiesamen, aus dem eine unendliche Anzahl von Schlüsseln beliebiger Größe deterministisch abgeleitet werden kann.
Das eigentliche Problem ist diese "abgeleitete" Zufälligkeit und wie zufällig sie wirklich ist. Mir ist keine unendliche Quelle dafür bekannt.
Mit Salsa / ChaCha können Sie bis zu 2 ^ 64 512-Bit-Schlüssel generieren, wobei jeder Schlüssel 16 verschiedene 4-Byte-Blöcke verschlüsseln kann. Also denke ich unendlich genug.
Benutzer müssten es mit einem 320-Bit-Schlüssel setzen. Sie müssen ihren Schlüssel nach 2 ^ 68 (wenn meine Mathematik nicht falsch ist) Verschlüsselungen ändern. Wenn Sie ein XChaCha-ähnliches Setup verwenden, können Sie dieses auf 2 ^ 132 erweitern.
Zusammenfassend lässt sich sagen, dass Sie nur XOR verwenden können, wenn Sie eine kryptografisch sichere Zufallsquelle haben.
Die Standardlösung eines Kryptographen mit diesen Einschränkungen wäre die Verwendung von AES-128-GCM mit einem 12-Byte-Nonce und einem 16-Byte-Authentifizierungs-Tag unter Verwendung eines festen geheimen Schlüssels.
Die Tatsache, dass dieser Wert in der Blockchain gespeichert ist, ermöglicht jedoch einige eindeutige Größenreduzierungen:
- Die Nonce kann gelöscht und stattdessen aus der Anzahl der in die Blockchain geschriebenen Werte neu abgeleitet werden. Dies kann durch Überprüfen des vorherigen Status der Kette abgerufen werden. Dies setzt voraus, dass der Schlüssel nur für diese Anwendung verwendet wird und keine andere Verwendung des Schlüssels versehentlich dasselbe Schlüssel / Nonce-Paar wie jede Transaktion verwenden kann.
- Das Authentifizierungs-Tag kann gelöscht werden, da Sie immer wissen, was der Chiffretext ist, und es kann nach der Übermittlung aufgrund der Signatur der Transaktion und der unveränderlichen Natur einer Blockchain nicht geändert werden. Beachten Sie, dass dies voraussetzt, dass Sie beim Abrufen des Werts entweder darauf vertrauen, dass der Blockchain-Client keinen falschen Wert liefert, oder dass Sie die entsprechende signierte Transaktion auch irgendwie abrufen und überprüfen können.
Wenn Sie nun beide entfernen, bleibt im Wesentlichen AES-128-CTR übrig, das berechnet $\operatorname{AES}_K(C)\oplus M$ für einen festen Schlüssel $K$ und Ihr Gegenwert $C$ und eine Nachricht $M$. Beachten Sie, dass dies keine Nachrichtenerweiterung erfordert, da Sie nur denselben Teil der AES-Ausgabe zur Entschlüsselung erneut ausführen können.