Varför en längre Blowfish-nyckel inte kan rätta till ett 64-bitarsblock

En VPN-profil erbjuder Blowfish med en 448-bitars nyckel, och någon föreslår att man använder den längsta nyckeln för att behålla chifferet. Nyckellängden är verklig, men det är fel tal att optimera. Blowfish bearbetar 64-bitarsblock oavsett hur lång nyckeln är, och det är blockbredden som begränsar hur mycket trafik en nyckel säkert kan skydda. Kör kontrollerna nedan i ordning och stanna vid den första som friar tjänsten, för ett senare steg kan inte reparera ett tidigare.

Kontrollera vad parterna faktiskt förhandlar fram

Läs datakanalens chiffer från båda ändar, inte från profilen du tänkte distribuera. En klientkonfiguration kan lista flera chiffer, och det valda är resultatet av förhandling mellan två implementationer och deras versioner. Höj loggdetaljeringen på en testanslutning och läs datakanalraden, som anger det chiffer och den nyckelstorlek som faktiskt initierades.

Om det förhandlade chifferet är AES-GCM eller ChaCha20-Poly1305, stanna här. De konstruktionerna använder ett 128-bitarsblock och autentiserar nyttolasten, så argumentet om 64-bitarskollisioner nedan gäller inte för dem.

Skilj nyckellängd från blockbredd

Blowfish accepterar nycklar från 32 till 448 bitar, och algoritmens författare dokumenterar båda talen var för sig. Nyckeln är hemligheten; blocket är transformationsenheten. En längre hemlighet gör gissandet svårare och gör ingenting åt bredden på det block som chifferet bearbetar.

I CBC-läge tillämpas chifferet på block med fast bredd, kedjade med föregående chiffertextblock och utfyllda i slutet. För Blowfish är den bredden 64 bitar, eller åtta byte. Nyckelschemat kan vara hur stort som helst; kedjan rör sig fortfarande åtta byte i taget.

Därför är en längre nyckel ingen åtgärd. Den adresserar brute force mot nyckeln, medan kollisionsrisken nedan är en egenskap hos blockbredden och läget.

Räkna födelsedagsaritmetiken på blockstorleken

Ett 64-bitarsblock har en födelsedagsskala på ungefär 2^32 block krypterade under en nyckel innan kollisioner blir sannolika. Varje block bär åtta byte, så samma skala är cirka 2^35 byte, eller 32 GiB data under en enda nyckel.

Betrakta det som en skala, inte en kvot. Kollisioner är probabilistiska, och om en läcker något beror på läget, trafikmönstret och på om angriparen kan känna igen eller påverka den omgivande klartexten. Den första byten efter 32 GiB är ingen dekrypteringshändelse, och de första 32 GiB är inte certifierat säkra.

Sweet32-forskarna demonstrerade 2016 praktiska attacker mot 64-bitarsblockchiffer, inklusive ett OpenVPN-scenario, under förhållanden som krävde observation och trafikgenerering. Deras publicerade standardvärden och programvaruversioner är historisk kontext, inte en beskrivning av din driftsättning.

Avgör om återanvändning av CBC spelar roll här

I CBC betyder ett upprepat chiffertextblock att de två klartextblocken skiljer sig med ett känt förhållande, eftersom kedje-XOR:en tar ut sig. En angripare som kan observera chiffertexten och känner till eller kan påverka en av klartexterna kan möjligen få information om den andra. Blowfish-nyckeln behövs aldrig för det.

De relevanta frågorna är alltså hur länge en nyckel är i bruk, hur mycket trafik som passerar under den och om någon kan se och styra den trafiken. Nyckelbyte sänker antalet block per nyckel, men ett tidsintervall är ingen bytegräns: en upptagen tunnel kan flytta mycket mer data än en ledig under samma timme. Om du behåller ett äldre chiffer ska du härleda gränsen från konstruktionen och den faktiska volymen, inte från ett runt tal.

Om den uppmätta volymen per nyckel ligger långt under födelsedagsskalan är exponeringen mindre. Den är fortfarande inte noll och fortfarande ett skäl att planera en migrering i stället för att sluta oroa sig.

Byt ut chifferet i stället för nyckeln

Flytta tjänsten till ett chiffer med stöd för AEAD och bekräfta att båda parterna, deras versioner och deras kryptografiska backends kan förhandla fram det. En längre Blowfish-nyckel ändrar inget som spelar roll, och att gissa på ett nytt direktiv på en klient är hur en fungerande tunnel blir en trasig. Testa ändringen på en klient och en server innan du rör resten av flottan. Håll den gamla profilen tillgänglig för återställning tills det nya chifferet har klarat en full anslutningscykel.

Behåll certifikatverifiering och autentisering av konton under ändringen. De svarar på olika frågor: en lyckad inloggning kan inte göra ett block bredare, och ett bättre datachiffer ursäktar inte att man litar på fel server.

Avsluta kontrollen genom att läsa det förhandlade chifferet igen på en ny anslutning och sedan bekräfta att det gamla chifferet inte längre accepteras. Om en part fortfarande erbjuder det är migreringen inte klar, vad profilen på andra sidan säger.