Waarom 'n langer Blowfish-sleutel nie 'n 64-bisblok kan regmaak nie

'n VPN-profiel bied Blowfish met 'n 448-bis-sleutel aan, en iemand stel voor om die langste sleutel te gebruik om die sjiffer te behou. Die sleutellengte is werklik, maar dit is die verkeerde getal om te optimaliseer. Blowfish verwerk 64-bisblokke ongeag hoe lank die sleutel is, en die blokbreedte is wat beperk hoeveel verkeer een sleutel veilig kan beskerm. Voer die kontroles hieronder in volgorde uit en stop by die eerste een wat die diens vrywaar, want 'n latere stap kan nie 'n vroeëre regmaak nie.

Kontroleer wat die partye werklik onderhandel

Lees die datakanaal-sjiffer van beide kante, nie uit die profiel wat jy van plan was om te ontplooi nie. 'n Kliëntkonfigurasie kan verskeie sjiffers lys, en die gekose een is die resultaat van onderhandeling tussen twee implementasies en hul weergawes. Verhoog die logdetail op 'n toetsverbinding en lees die datakanaal-lyn, wat die sjiffer en die sleutelgrootte noem wat werklik geïnisialiseer is.

As die onderhandelde sjiffer AES-GCM of ChaCha20-Poly1305 is, stop hier. Daardie konstruksies gebruik 'n 128-bisblok en verifieer die loonvrag, dus die argument oor 64-bis-botsings hieronder geld nie vir hulle nie.

Skei sleutellengte van blokbreedte

Blowfish aanvaar sleutels van 32 tot 448 bis, en die dokumentasie van die algoritme-outeur noem beide getalle afsonderlik. Die sleutel is die geheim; die blok is die eenheid van transformasie. 'n Langer geheim maak raai moeiliker en doen niks aan die breedte van die blok wat die sjiffer verwerk nie.

In CBC-modus word die sjiffer toegepas op blokke van vaste breedte, geketting met die vorige sjiferteksblok en aan die einde opgevul. Vir Blowfish is daardie breedte 64 bis, of agt grepe. Die sleutelskedule kan so groot wees as jy wil; die ketting skuif steeds agt grepe op 'n slag.

Daarom is 'n langer sleutel nie 'n teenmaatreël nie. Dit spreek brute force teen die sleutel aan, terwyl die botsingsrisiko hieronder 'n eienskap van die blokbreedte en die modus is.

Bereken die verjaardag-rekenkunde op die blokgrootte

'n 64-bisblok het 'n verjaardagskaal van ongeveer 2^32 blokke wat onder een sleutel geënkripteer word voordat botsings waarskynlik word. Elke blok dra agt grepe, dus dieselfde skaal is ongeveer 2^35 grepe, of 32 GiB data onder 'n enkele sleutel.

Beskou dit as 'n skaal, nie 'n kwota nie. Botsings is probabilisties, en of een iets lek hang af van die modus, die verkeerspatroon en of die aanvaller die omliggende gewone teks kan herken of beïnvloed. Die eerste greep verby 32 GiB is nie 'n ontsleutelingsgebeurtenis nie, en die eerste 32 GiB is nie as veilig gesertifiseer nie.

Die Sweet32-navorsers het in 2016 praktiese aanvalle op 64-bisbloksjiffers gedemonstreer, insluitend 'n OpenVPN-scenario, onder toestande wat waarneming en verkeersgenerering vereis het. Hul gepubliseerde verstekwaardes en sagtewareweergawes is historiese konteks, nie 'n beskrywing van jou ontplooiing nie.

Bepaal of hergebruik van CBC hier saak maak

In CBC beteken 'n herhaalde sjiferteksblok dat die twee gewone teksblokke met 'n bekende verhouding verskil, omdat die ketting-XOR homself kanselleer. 'n Aanvaller wat die sjiferteks kan waarneem en een van die gewone tekste ken of kan beïnvloed, kan moontlik inligting oor die ander terugkry. Die Blowfish-sleutel word nooit daarvoor nodig nie.

Die relevante vrae is dus hoe lank 'n sleutel in diens bly, hoeveel verkeer daaronder beweeg en of iemand daardie verkeer kan dophou en stuur. Sleutelvernuwing verlaag die bloktelling per sleutel, maar 'n tydsinterval is nie 'n grepe-limiet nie: 'n besige tonnel kan in dieselfde uur baie meer data beweeg as 'n ledige een. As jy 'n ouer sjiffer behou, lei die limiet dan af uit die konstruksie en die werklike volume, nie uit 'n ronde getal nie.

As die gemete volume per sleutel ver onder die verjaardagskaal bly, is die blootstelling kleiner. Dit is steeds nie nul nie en steeds 'n rede om 'n migrasie te beplan eerder as om op te hou bekommer.

Vervang die sjiffer, nie die sleutel nie

Skuif die diens na 'n ondersteunde AEAD-sjiffer en bevestig dat beide partye, hul weergawes en hul kriptografiese backend dit kan onderhandel. 'n Langer Blowfish-sleutel verander niks wat saak maak nie, en om 'n nuwe richtlijn op een kliënt te raai is hoe 'n werkende tonnel 'n gebreekte een word. Toets die verandering op een kliënt en een bediener voordat jy die res van die vloot aanraak. Hou die ou profiel beskikbaar vir terugrol totdat die nuwe sjiffer 'n volle verbindingsiklus geslaag het.

Hou sertifikaatverifikasie en rekening-verifikasie in plek tydens die verandering. Hulle beantwoord verskillende vrae: 'n suksesvolle aanmelding kan nie 'n blok breër maak nie, en 'n beter data-sjiffer is nie 'n verskoning om die verkeerde bediener te vertrou nie.

Sluit die kontrole af deur die onderhandelde sjiffer weer op 'n nuwe verbinding te lees en bevestig dan dat die ou sjiffer nie meer aanvaar word nie. As 'n party dit nog aanbied, is die migrasie nie klaar nie, wat die profiel aan die ander kant ook sê.