Hvorfor en lengre Blowfish-nøkkel ikke kan rette opp en 64-bits blokk

En VPN-profil tilbyr Blowfish med en 448-bits nøkkel, og noen foreslår å bruke den lengste nøkkelen for å beholde chifferen. Nøkkellengden er reell, men det er feil tall å optimalisere. Blowfish behandler 64-bits blokker uansett hvor lang nøkkelen er, og det er blokkbredden som begrenser hvor mye trafikk én nøkkel trygt kan beskytte. Kjør kontrollene nedenfor i rekkefølge og stopp ved den første som friskmelder tjenesten, for et senere trinn kan ikke reparere et tidligere.

Sjekk hva partene faktisk forhandler

Les datakanalens chiffer fra begge ender, ikke fra profilen du hadde tenkt å rulle ut. En klientkonfigurasjon kan liste flere chiffer, og det valgte er resultatet av forhandling mellom to implementasjoner og deres versjoner. Øk loggdetaljene på en testtilkobling og les datakanallinjen, som navngir chifferen og nøkkelstørrelsen som faktisk ble initialisert.

Hvis den forhandlede chifferen er AES-GCM eller ChaCha20-Poly1305, stopp her. De konstruksjonene bruker en 128-bits blokk og autentiserer nyttelasten, så argumentet om 64-bits kollisjoner nedenfor gjelder ikke for dem.

Skill nøkkellengde fra blokkbredde

Blowfish godtar nøkler fra 32 til 448 biter, og algoritmens forfatter dokumenterer begge tallene hver for seg. Nøkkelen er hemmeligheten; blokken er transformasjonsenheten. En lengre hemmelighet gjør gjetting vanskeligere og gjør ingenting med bredden på blokken chifferen behandler.

I CBC-modus brukes chifferen på blokker med fast bredde, kjedet sammen med forrige chiffertekstblokk og polstret til slutt. For Blowfish er den bredden 64 biter, eller åtte byte. Nøkkelskjemaet kan være så stort du vil; kjeden flytter seg fortsatt åtte byte om gangen.

Derfor er en lengre nøkkel ingen motgift. Den retter seg mot brute force mot nøkkelen, mens kollisjonsrisikoen nedenfor er en egenskap ved blokkbredden og modusen.

Regn bursdagsaritmetikken på blokkstørrelsen

En 64-bits blokk har en bursdagsskala på omtrent 2^32 blokker kryptert under én nøkkel før kollisjoner blir sannsynlige. Hver blokk bærer åtte byte, så samme skala er rundt 2^35 byte, eller 32 GiB data under én enkelt nøkkel.

Behandle det som en skala, ikke en kvote. Kollisjoner er probabilistiske, og om en lekker noe avhenger av modusen, trafikkmønsteret og av om angriperen kan gjenkjenne eller påvirke klarteksten rundt. Den første byten forbi 32 GiB er ingen dekrypteringshendelse, og de første 32 GiB er ikke sertifisert trygge.

Sweet32-forskerne demonstrerte i 2016 praktiske angrep mot 64-bits blokkchiffere, inkludert et OpenVPN-scenario, under forhold som krevde observasjon og trafikkgenerering. Deres publiserte standardverdier og programvareversjoner er historisk kontekst, ikke en beskrivelse av din utrulling.

Avgjør om gjenbruk av CBC betyr noe her

I CBC betyr en gjentatt chiffertekstblokk at de to klartekstblokkene skiller seg med et kjent forhold, fordi kjedets XOR oppheves. En angriper som kan observere chifferteksten og kjenner eller kan påvirke en av klartekstene, kan muligens få informasjon om den andre. Blowfish-nøkkelen trengs aldri for det.

De relevante spørsmålene er altså hvor lenge en nøkkel er i bruk, hvor mye trafikk som passerer under den, og om noen kan se og styre den trafikken. Nøkkelbytte senker blokkantallet per nøkkel, men et tidsintervall er ingen bytegrense: en travel tunnel kan flytte langt mer data enn en ledig i samme time. Hvis du beholder en eldre chiffer, må du utlede grensen fra konstruksjonen og det faktiske volumet, ikke fra et rundt tall.

Hvis det målte volumet per nøkkel ligger langt under bursdagsskalaen, er eksponeringen mindre. Den er fortsatt ikke null og fortsatt en grunn til å planlegge en migrering i stedet for å slutte å bekymre seg.

Bytt ut chifferen i stedet for nøkkelen

Flytt tjenesten til en støttet AEAD-chiffer, og bekreft at begge parter, versjonene deres og deres kryptografiske backender kan forhandle den. En lengre Blowfish-nøkkel endrer ingenting som betyr noe, og å gjette på et nytt direktiv på én klient er måten en fungerende tunnel blir en ødelagt. Test endringen på én klient og én server før du rører resten av flåten. Hold den gamle profilen tilgjengelig for tilbakerulling til den nye chifferen har gjennomgått en full tilkoblingssyklus.

Behold sertifikatverifisering og kontopålogging under endringen. De svarer på forskjellige spørsmål: en vellykket innlogging kan ikke gjøre en blokk bredere, og en bedre datachiffer er ingen unnskyldning for å stole på feil server.

Avslutt kontrollen ved å lese den forhandlede chifferen på nytt på en ny tilkobling, og bekreft deretter at den gamle chifferen ikke lenger godtas. Hvis en part fortsatt tilbyr den, er migreringen ikke ferdig, uansett hva profilen på den andre siden sier.