Warum ein längerer Blowfish-Schlüssel einen 64-Bit-Block nicht reparieren kann

Ein VPN-Profil bietet Blowfish mit einem 448-Bit-Schlüssel an, und jemand schlägt vor, den längsten Schlüssel zu verwenden, um die Verschlüsselung zu behalten. Die Schlüssellänge ist real, aber sie ist die falsche Zahl zum Optimieren. Blowfish verarbeitet 64-Bit-Blöcke, egal wie lang der Schlüssel ist, und die Blockbreite begrenzt, wie viel Datenverkehr ein Schlüssel sicher schützen kann. Führen Sie die folgenden Prüfungen der Reihe nach aus und halten Sie bei der ersten an, die den Dienst freigibt, denn ein späterer Schritt kann einen früheren nicht reparieren.

Prüfen Sie, was die Peers tatsächlich aushandeln

Lesen Sie die Datenkanal-Verschlüsselung an beiden Enden ab, nicht aus dem Profil, das Sie bereitstellen wollten. Eine Client-Konfiguration kann mehrere Verschlüsselungen auflisten, und die ausgewählte ist das Ergebnis der Aushandlung zwischen zwei Implementierungen und ihren Versionen. Erhöhen Sie die Protokollausführlichkeit bei einer Testverbindung und lesen Sie die Datenkanal-Zeile, die die tatsächlich initialisierte Verschlüsselung und Schlüsselgröße nennt.

Wenn die ausgehandelte Verschlüsselung AES-GCM oder ChaCha20-Poly1305 ist, hören Sie hier auf. Diese Konstruktionen verwenden einen 128-Bit-Block und authentifizieren die Nutzdaten, daher gilt das folgende 64-Bit-Kollisionsargument für sie nicht.

Trennen Sie Schlüssellänge und Blockbreite

Blowfish akzeptiert Schlüssel von 32 bis 448 Bit, und die Dokumentation des Algorithmus-Autors führt beide Zahlen getrennt auf. Der Schlüssel ist das Geheimnis; der Block ist die Einheit der Transformation. Ein längeres Geheimnis macht das Erraten schwerer und ändert nichts an der Breite des Blocks, den die Verschlüsselung verarbeitet.

Im CBC-Modus wird die Verschlüsselung auf Blöcke fester Breite angewendet, mit dem vorherigen Chiffretextblock verkettet und am Ende aufgefüllt. Bei Blowfish ist diese Breite 64 Bit oder acht Byte. Der Schlüsselplan kann beliebig groß sein; die Kette rückt trotzdem jeweils um acht Byte vor.

Deshalb ist eine längere Schlüssellänge keine Gegenmaßnahme. Sie erschwert Brute-Force-Angriffe auf den Schlüssel, während das Kollisionsrisiko unten eine Eigenschaft der Blockbreite und des Modus ist.

Rechnen Sie die Geburtstagsarithmetik auf die Blockgröße

Ein 64-Bit-Block hat eine Geburtstagsskala von ungefähr 2^32 Blöcken, die unter einem Schlüssel verschlüsselt werden, bevor Kollisionen wahrscheinlich werden. Jeder Block trägt acht Byte, also entspricht dieselbe Skala etwa 2^35 Byte oder 32 GiB Daten unter einem einzigen Schlüssel.

Betrachten Sie das als Skala, nicht als Quote. Kollisionen sind probabilistisch, und ob eine etwas preisgibt, hängt vom Modus, dem Verkehrsmuster und davon ab, ob der Angreifer den umgebenden Klartext erkennen oder beeinflussen kann. Das erste Byte jenseits von 32 GiB ist kein Entschlüsselungsereignis, und die ersten 32 GiB sind nicht als sicher zertifiziert.

Die Sweet32-Forscher demonstrierten 2016 praktische Angriffe gegen 64-Bit-Blockverschlüsselungen, einschließlich eines OpenVPN-Szenarios, unter Bedingungen, die Beobachtung und Verkehrserzeugung erforderten. Ihre veröffentlichten Voreinstellungen und Softwareversionen sind historischer Kontext, keine Beschreibung Ihrer Bereitstellung.

Entscheiden Sie, ob CBC-Wiederverwendung hier relevant ist

In CBC bedeutet ein wiederholter Chiffretextblock, dass sich die beiden Klartextblöcke um eine bekannte Beziehung unterscheiden, weil sich das Verkettungs-XOR aufhebt. Ein Angreifer, der den Chiffretext beobachten kann und einen der Klartexte kennt oder beeinflussen kann, kann möglicherweise Informationen über den anderen gewinnen. Der Blowfish-Schlüssel ist dafür nie nötig.

Die relevanten Fragen sind also, wie lange ein Schlüssel im Einsatz bleibt, wie viel Datenverkehr unter ihm läuft und ob jemand diesen Verkehr beobachten und lenken kann. Eine Neuschlüsselung senkt die Blockzahl pro Schlüssel, aber ein Zeitintervall ist kein Byte-Limit: Ein ausgelasteter Tunnel kann in derselben Stunde weit mehr Daten bewegen als ein leerer. Wenn Sie eine Legacy-Verschlüsselung behalten, leiten Sie das Limit aus der Konstruktion und dem tatsächlichen Volumen ab, nicht aus einer runden Zahl.

Wenn das gemessene Volumen pro Schlüssel weit unter der Geburtstagsskala bleibt, ist die Exposition kleiner. Sie ist trotzdem nicht null und immer noch ein Grund, eine Migration zu planen, statt sich keine Sorgen mehr zu machen.

Ersetzen Sie die Verschlüsselung, nicht den Schlüssel

Stellen Sie den Dienst auf eine unterstützte AEAD-Verschlüsselung um und bestätigen Sie, dass beide Peers, ihre Versionen und ihre kryptografischen Backends sie aushandeln können. Eine längere Blowfish-Schlüssellänge ändert nichts, was zählt, und eine neue Direktive auf einem Client zu raten, ist der Weg, einen funktionierenden Tunnel zu ruinieren. Testen Sie die Änderung an einem Client und einem Server, bevor Sie den Rest des Bestands anfassen. Halten Sie das alte Profil für einen Rollback verfügbar, bis die neue Verschlüsselung einen vollständigen Verbindungszyklus bestanden hat.

Behalten Sie während der Änderung die Zertifikatsprüfung und die Kontauthentifizierung bei. Sie beantworten unterschiedliche Fragen: Eine erfolgreiche Anmeldung kann keinen Block verbreitern, und eine bessere Datenverschlüsselung entschuldigt nicht, dem falschen Server zu vertrauen.

Schließen Sie die Prüfung ab, indem Sie die ausgehandelte Verschlüsselung bei einer neuen Verbindung erneut ablesen und dann bestätigen, dass die alte Verschlüsselung nicht mehr akzeptiert wird. Wenn ein Peer sie noch anbietet, ist die Migration nicht abgeschlossen, egal was das Profil auf der anderen Seite sagt.