4. Security Considerations (Sicherheitsaspekte)
4. Security Considerations (Sicherheitsaspekte)
Die ChaCha20-Verschlüsselung ist für 256-Bit-Sicherheit ausgelegt.
Der Poly1305-Authentifikator ist so ausgelegt, dass gefälschte Nachrichten mit einer Wahrscheinlichkeit von 1-(n/(2^102)) für eine Nachricht der Länge 16n Byte abgelehnt werden, selbst nach dem Senden von 2^64 legitimen Nachrichten ; er ist damit in der Terminologie von [AE] SUF-CMA (strong unforgeability against chosen-message attacks, starke Unfälschbarkeit unter gewählten Nachrichtenangriffen).
Den Nachweis der Sicherheit eines der beiden Verfahren zu führen, liegt außerhalb des Rahmens dieses Dokuments. Solche Nachweise finden sich in den zitierten Arbeiten ([ChaCha], [Poly1305], [LatinDances], [LatinDances2] und [Zhenqing2012]).
Die wichtigste Sicherheitsüberlegung bei der Umsetzung dieses Dokuments ist die Eindeutigkeit des in ChaCha20 verwendeten Nonce. Zähler und LFSRs (linear feedback shift registers, linear rückgekoppelte Schieberegister) sind beides zulässige Arten, eindeutige Nonces zu erzeugen, ebenso die Verschlüsselung eines Zählers mit einem Blockcipher mit 64-Bit-Blockgröße wie DES. Eine Abschneidung (Truncation) eines mit Blockciphers mit 128- oder 256-Bit-Blöcken verschlüsselten Zählers ist nicht zulässig, weil eine solche Abschneidung nach kurzer Zeit wiederholt werden kann.
Folgen einer Nonce-Wiederholung: Wird ein Nonce wiederholt, sind sowohl der einmalige Poly1305-Schlüssel als auch der Keystrom zwischen den Nachrichten identisch. Damit wird das XOR der Klartexte offengelegt, denn das XOR der Klartexte ist gleich dem XOR der Geheimtexte.
Der Poly1305-Schlüssel MUSS für einen Angreifer unvorhersehbar sein. Zufällige Schlüsselerzeugung würde diese Anforderung erfüllen, außer dass Poly1305 oft in Kommunikationsprotokollen verwendet wird, sodass der Empfänger den Schlüssel kennen muss. Pseudozufallszahlenerzeugung, etwa durch Verschlüsseln eines Zählers, ist zulässig. Die Verwendung von ChaCha mit geheimem Schlüssel und Nonce ist ebenfalls zulässig.
Die hier vorgestellten Algorithmen sind so entworfen, dass sie sich leicht in konstanter Zeit implementieren lassen, um Seitenkanal-Schwachstellen zu vermeiden. Die in ChaCha20 verwendeten Operationen sind ausschließlich Additionen, XORs und feste Rolls. All dies kann und sollte in konstanter Zeit implementiert werden. Der Zugriff auf Offsets im ChaCha-Zustand und die Anzahl der Operationen hängen nicht von einer Eigenschaft des Schlüssels ab, wodurch ein Auslecken von Schlüsselinformation über das Timing von Cache-Misses ausgeschlossen wird.
Bei Poly1305 sind die Operationen Addition, Multiplikation und Modulo, jeweils auf Zahlen mit mehr als 128 Bits. Das lässt sich in konstanter Zeit umsetzen, aber eine naive Implementierung (etwa mit einer generischen Big-Integer-Bibliothek) ist nicht konstantzeitig. Wird beispielsweise die Multiplikation getrennt vom Modulo ausgeführt, liegt das Ergebnis mal unter 2^256 und mal darüber. Implementierer sollten bei Poly1305 Timing-Seitenkanäle beachten und geeignete Implementierungen dieser Operationen verwenden.
Die Überprüfung der Authentizität einer Nachricht umfasst einen bitweisen Vergleich des berechneten Tags mit dem empfangenen Tag. In den meisten Anwendungsfällen werden Nonces und AAD-Inhalte (associated authenticated data, zugehörige authentifizierte Daten) erst "verbraucht", wenn eine gültige Nachricht empfangen wurde. Dadurch kann ein Angreifer mehrere identische Nachrichten mit unterschiedlichen Tags senden, bis eines den Tag-Vergleich besteht. Das ist schwer, wenn der Angreifer alle 2^128 möglichen Tags nacheinander probieren muss. Offenbart jedoch das Timing des Tag-Vergleichs, wie lang ein gemeinsames Präfix von berechnetem und empfangenem Tag ist, lässt sich die benötigte Anzahl Nachrichten stark reduzieren. Aus diesem Grund MUSS die Implementierung bei Online-Protokollen eine konstantzeitige Vergleichsfunktion verwenden und nicht auf optimierte, aber unsichere Bibliotheksfunktionen wie memcmp() in C setzen.
Darüber hinaus MUSS jedes Protokoll, das diesen Algorithmus nutzt, den vollständigen Tag aufnehmen, um Fälschungsmöglichkeiten zu minimieren. Tag-Truncation DARF NICHT vorgenommen werden.