Waarom een langere Blowfish-sleutel een blok van 64 bits niet kan repareren

Een VPN-profiel biedt Blowfish met een sleutel van 448 bits aan, en iemand stelt voor de langste sleutel te gebruiken om het cijfer te behouden. De sleutellengte is echt, maar het is het verkeerde getal om te optimaliseren. Blowfish verwerkt blokken van 64 bits, hoe lang de sleutel ook is, en de blokbreedte bepaalt hoeveel verkeer één sleutel veilig kan beschermen. Voer de onderstaande controles in volgorde uit en stop bij de eerste die de dienst vrijgeeft, want een latere stap kan een eerdere niet repareren.

Controleer wat de peers werkelijk onderhandelen

Lees het cijfer van het datakanaal aan beide uiteinden af, niet uit het profiel dat u wilde uitrollen. Een clientconfiguratie kan meerdere cijfers vermelden, en het gekozen cijfer is het resultaat van onderhandeling tussen twee implementaties en hun versies. Verhoog de logdetails op een testverbinding en lees de regel van het datakanaal, die het cijfer en de werkelijk geïnitialiseerde sleutelgrootte noemt.

Als het onderhandelde cijfer AES-GCM of ChaCha20-Poly1305 is, stop dan hier. Die constructies gebruiken een blok van 128 bits en authenticeren de payload, dus het onderstaande argument over botsingen bij 64 bits geldt er niet voor.

Scheid sleutellengte van blokbreedte

Blowfish accepteert sleutels van 32 tot 448 bits, en de documentatie van de algoritmeauteur vermeldt beide getallen afzonderlijk. De sleutel is het geheim; het blok is de eenheid van transformatie. Een langer geheim maakt het raden moeilijker en verandert niets aan de breedte van het blok dat het cijfer verwerkt.

In CBC-modus wordt het cijfer toegepast op blokken van vaste breedte, geketend met het vorige ciphertextblok en aan het einde opgevuld. Voor Blowfish is die breedte 64 bits, of acht bytes. Het sleutelschema mag zo groot zijn als u wilt; de keten schuift nog steeds acht bytes per keer op.

Daarom is een langere sleutel geen mitigerende maatregel. Het richt zich op brute force tegen de sleutel, terwijl het botsingsrisico hieronder een eigenschap is van de blokbreedte en de modus.

Reken de verjaardagsaritmetiek op de blokgrootte

Een blok van 64 bits heeft een verjaardagsschaal van ongeveer 2^32 blokken die onder één sleutel worden versleuteld voordat botsingen waarschijnlijk worden. Elk blok draagt acht bytes, dus dezelfde schaal is ongeveer 2^35 bytes, of 32 GiB aan gegevens onder één sleutel.

Beschouw dat als een schaal, niet als een quotum. Botsingen zijn probabilistisch, en of er iets lekt hangt af van de modus, het verkeerspatroon en of de aanvaller de omliggende platte tekst kan herkennen of beïnvloeden. De eerste byte voorbij 32 GiB is geen ontsleutelingsgebeurtenis, en de eerste 32 GiB zijn niet als veilig gecertificeerd.

De Sweet32-onderzoekers demonstreerden in 2016 praktische aanvallen op cijfers met blokken van 64 bits, waaronder een OpenVPN-scenario, onder omstandigheden die observatie en verkeersgeneratie vereisten. Hun gepubliceerde standaardwaarden en softwareversies zijn historische context, geen beschrijving van uw uitrol.

Bepaal of hergebruik van CBC hier uitmaakt

In CBC betekent een herhaald ciphertextblok dat de twee plaintextblokken een bekende relatie hebben, omdat de keten-XOR wegvalt. Een aanvaller die de ciphertext kan observeren en een van de plaintexts kent of kan beïnvloeden, kan mogelijk informatie over de andere achterhalen. De Blowfish-sleutel is daarvoor nooit nodig.

De relevante vragen zijn dus hoe lang een sleutel in gebruik blijft, hoeveel verkeer eronder passeert en of iemand dat verkeer kan bekijken en sturen. Opnieuw versleutelen verlaagt het aantal blokken per sleutel, maar een tijdsinterval is geen bytelimiet: een drukke tunnel kan in hetzelfde uur veel meer gegevens verplaatsen dan een lege. Als u een verouderd cijfer behoudt, leid de limiet dan af uit de constructie en het werkelijke volume, niet uit een rond getal.

Als het gemeten volume per sleutel ver onder de verjaardagsschaal blijft, is de blootstelling kleiner. Die is nog steeds niet nul en nog steeds een reden om een migratie te plannen in plaats van zich geen zorgen meer te maken.

Vervang het cijfer, niet de sleutel

Zet de dienst over op een ondersteund AEAD-cijfer en bevestig dat beide peers, hun versies en hun cryptografische backends het kunnen onderhandelen. Een langere Blowfish-sleutel verandert niets dat ertoe doet, en een nieuwe richtlijn op één client raden is hoe een werkende tunnel een kapotte wordt. Test de wijziging op één client en één server voordat u de rest van de vloot aanraakt. Houd het oude profiel beschikbaar voor terugdraaien tot het nieuwe cijfer een volledige verbindingscyclus heeft doorstaan.

Houd certificaatverificatie en accountauthenticatie tijdens de wijziging in stand. Ze beantwoorden verschillende vragen: een geslaagde aanmelding kan een blok niet breder maken, en een beter datacijfer is geen excuus om de verkeerde server te vertrouwen.

Sluit de controle af door het onderhandelde cijfer opnieuw af te lezen op een nieuwe verbinding en bevestig dan dat het oude cijfer niet meer wordt geaccepteerd. Als een peer het nog aanbiedt, is de migratie niet voltooid, wat het profiel aan de andere kant ook zegt.