Hvorfor en længere Blowfish-nøgle ikke kan rette en 64-bit-blok

En VPN-profil tilbyder Blowfish med en nøgle på 448 bit, og nogen foreslår at bruge den længste nøgle for at beholde cipheren. Nøglelængden er reel, men det er det forkerte tal at optimere. Blowfish behandler 64-bit-blokke, uanset hvor lang nøglen er, og blokbredden er det, der begrænser, hvor meget trafik én nøgle sikkert kan beskytte. Kør kontrollerne nedenfor i rækkefølge, og stop ved den første, der frikender tjenesten, for et senere trin kan ikke reparere et tidligere.

Kontroller, hvad parterne faktisk forhandler

Læs datakanalens cipher i begge ender, ikke fra den profil, du havde tænkt at udrulle. En klientkonfiguration kan liste flere ciphers, og den valgte er resultatet af forhandling mellem to implementeringer og deres versioner. Hæv logdetaljeringsgraden på en testforbindelse, og læs datakanallinjen, som angiver den cipher og nøglestørrelse, der faktisk blev initialiseret.

Hvis den forhandlede cipher er AES-GCM eller ChaCha20-Poly1305, så stop her. De konstruktioner bruger en 128-bit-blok og autentificerer nyttelasten, så argumentet om 64-bit-kollisioner nedenfor gælder ikke for dem.

Adskil nøglelængde fra blokbredde

Blowfish accepterer nøgler fra 32 til 448 bit, og algoritmens forfatter dokumenterer begge tal hver for sig. Nøglen er hemmeligheden; blokken er transformationsenheden. En længere hemmelighed gør gætteri sværere og gør intet ved bredden af den blok, cipheren behandler.

I CBC-tilstand anvendes cipheren på blokke med fast bredde, kædet sammen med den foregående ciphertextblok og polstret til sidst. For Blowfish er denne bredde 64 bit, eller otte bytes. Nøgleskemaet kan være så stort, du vil; kæden rykker stadig otte bytes ad gangen.

Derfor er en længere nøgle ikke en afbødning. Den adresserer brute force mod nøglen, mens kollisionsrisikoen nedenfor er en egenskab ved blokbredden og tilstanden.

Regn fødselsdagsaritmetikken på blokstørrelsen

En 64-bit-blok har en fødselsdagsskala på cirka 2^32 blokke krypteret under én nøgle, før kollisioner bliver sandsynlige. Hver blok bærer otte bytes, så samme skala er omkring 2^35 bytes, eller 32 GiB data under en enkelt nøgle.

Betragt det som en skala, ikke en kvote. Kollisioner er probabilistiske, og om en lækker noget, afhænger af tilstanden, trafikmønsteret og af, om angriberen kan genkende eller påvirke den omgivende klartekst. Den første byte efter 32 GiB er ikke en dekrypteringshændelse, og de første 32 GiB er ikke certificeret sikre.

Sweet32-forskerne demonstrerede i 2016 praktiske angreb på 64-bit-blokciphers, herunder et OpenVPN-scenario, under betingelser, der krævede observation og trafikgenerering. Deres offentliggjorte standarder og softwareversioner er historisk kontekst, ikke en beskrivelse af din udrulning.

Afgør, om CBC-genbrug betyder noget her

I CBC betyder en gentagen ciphertextblok, at de to klartekstblokke adskiller sig med en kendt relation, fordi kæde-XOR'en ophæves. En angriber, der kan observere ciphertexten og kender eller kan påvirke en af klarteksterne, kan muligvis få information om den anden. Blowfish-nøglen er aldrig nødvendig for det.

De relevante spørgsmål er derfor, hvor længe en nøgle er i brug, hvor meget trafik der passerer under den, og om nogen kan se og styre den trafik. Nøglerotation sænker blokantallet per nøgle, men et tidsinterval er ikke en bytegrænse: en travl tunnel kan flytte langt mere data end en ledig i den samme time. Hvis du beholder en ældre cipher, skal du udlede grænsen af konstruktionen og det faktiske volumen, ikke af et rundt tal.

Hvis det målte volumen per nøgle ligger langt under fødselsdagsskalaen, er eksponeringen mindre. Den er stadig ikke nul og stadig en grund til at planlægge en migrering i stedet for at holde op med at bekymre sig.

Udskift cipheren i stedet for nøglen

Flyt tjenesten til en understøttet AEAD-cipher, og bekræft, at begge parter, deres versioner og deres kryptografiske backends kan forhandle den. En længere Blowfish-nøgle ændrer intet, der betyder noget, og at gætte på en ny direktiv på én klient er måden, en fungerende tunnel bliver en brudt. Test ændringen på én klient og én server, før du rører resten af flåden. Hold den gamle profil tilgængelig til tilbagerulning, indtil den nye cipher har gennemgået en fuld forbindelsescyklus.

Behold certifikatverifikation og kontogodkendelse under ændringen. De besvarer forskellige spørgsmål: et vellykket login kan ikke gøre en blok bredere, og en bedre datacipher er ikke en undskyldning for at stole på den forkerte server.

Afslut kontrollen ved at læse den forhandlede cipher igen på en ny forbindelse og derefter bekræfte, at den gamle cipher ikke længere accepteres. Hvis en part stadig tilbyder den, er migreringen ikke færdig, uanset hvad profilen på den anden side siger.