Miért nem javítja meg egy hosszabb Blowfish-kulcs a 64 bites blokkot

Egy VPN-profil 448 bites kulcsú Blowfish-t kínál, és valaki azt javasolja, hogy a leghosszabb kulcsot használják a titkosítás megtartásához. A kulcshossz valós, de rossz szám az optimalizáláshoz. A Blowfish 64 bites blokkokat alakít át, függetlenül a kulcs hosszától, és a blokk szélessége az, ami korlátozza, mennyi forgalmat tud egy kulcs biztonságosan védeni. Hajtsa végre az alábbi ellenőrzéseket sorrendben, és álljon meg az elsőnél, amely mentesíti a szolgáltatást, mert egy későbbi lépés nem tud helyrehozni egy korábbit.

Ellenőrizze, mit egyeztetnek valójában a felek

Olvassa le az adatcsatorna titkosítását mindkét oldalon, ne abból a profilból, amelyet telepíteni akart. Egy ügyfélkonfiguráció több titkosítást is felsorolhat, és a kiválasztott kettő implementáció és verzióik egyeztetésének eredménye. Növelje a napló részletességét egy tesztkapcsolaton, és olvassa el az adatcsatorna sorát, amely megnevezi a ténylegesen inicializált titkosítást és kulcsméretet.

Ha az egyeztetett titkosítás AES-GCM vagy ChaCha20-Poly1305, álljon meg itt. Ezek a konstrukciók 128 bites blokkot használnak és hitelesítik a hasznos terhelést, ezért az alábbi 64 bites ütközési érv nem vonatkozik rájuk.

Válassza szét a kulcshosszt és a blokk szélességét

A Blowfish 32 és 448 bit közötti kulcsokat fogad el, és az algoritmus szerzőjének dokumentációja a két számot külön tárgyalja. A kulcs a titok; a blokk az átalakítás egysége. A hosszabb titok nehezebbé teszi a kitalálást, és semmit nem tesz a titkosítás által feldolgozott blokk szélességével.

CBC módban a titkosítás rögzített szélességű blokkokra vonatkozik, az előző rejtjelszöveg-blokkal láncolva és a végén kitöltve. A Blowfish esetében ez a szélesség 64 bit, azaz nyolc bájt. A kulcsütemezés akármilyen nagy lehet; a lánc mégis nyolc bájttal halad tovább egyszerre.

Ezért a hosszabb kulcs nem enyhítés. A kulcs elleni nyers erőt célozza, míg az alábbi ütközési kockázat a blokk szélességének és a módnak a tulajdonsága.

Alkalmazza a születésnapi aritmetikát a blokkméretre

Egy 64 bites blokk születésnapi skálája körülbelül 2^32 blokk, amelyet egy kulcs alatt titkosítanak, mielőtt az ütközések valószínűvé válnak. Minden blokk nyolc bájtot hordoz, így ugyanez a skála körülbelül 2^35 bájt, azaz 32 GiB adat egyetlen kulcs alatt.

Tekintse ezt skálának, nem kvótának. Az ütközések valószínűségiek, és hogy egy kiszivárogtat-e valamit, a módtól, a forgalmi mintától és attól függ, hogy a támadó felismeri-e vagy befolyásolhatja-e a környező nyílt szöveget. A 32 GiB utáni első bájt nem visszafejtési esemény, és az első 32 GiB nincs biztonságosként tanúsítva.

A Sweet32 kutatói 2016-ban gyakorlati támadásokat mutattak be 64 bites blokk-titkosítások ellen, köztük egy OpenVPN-forgatókönyvet, olyan körülmények között, amelyek megfigyelést és forgalomgenerálást igényeltek. Közzétett alapértékeik és szoftververzióik történelmi kontextus, nem a telepítésük leírása.

Döntse el, számít-e itt a CBC újrafelhasználása

CBC-ben egy ismétlődő rejtjelszöveg-blokk azt jelenti, hogy a két nyílt szövegű blokk ismert összefüggésben tér el, mert a láncolási XOR kioltja egymást. Egy támadó, aki meg tudja figyelni a rejtjelszöveget, és ismeri vagy befolyásolni tudja az egyik nyílt szöveget, információt szerezhet a másikról. A Blowfish-kulcs ehhez soha nem kell.

A releváns kérdések tehát azok, hogy meddig marad egy kulcs használatban, mennyi forgalom halad át alatta, és hogy bárki meg tudja-e figyelni és irányítani ezt a forgalmat. A kulcscsere csökkenti a kulcsonkénti blokkszámot, de egy időintervallum nem bájtlimit: egy forgalmas alagút ugyanabban az órában sokkal több adatot mozgathat, mint egy tétlen. Ha megtart egy örökölt titkosítást, a korlátot a konstrukcióból és a tényleges mennyiségből vezesse le, ne egy kerek számból.

Ha a kulcsonként mért mennyiség messze a születésnapi skála alatt marad, a kitettség kisebb. Még mindig nem nulla, és még mindig ok arra, hogy migrációt tervezzen ahelyett, hogy abbahagyja az aggodalmat.

A titkosítást cserélje, ne a kulcsot

Vigye a szolgáltatást támogatott AEAD-titkosításra, és erősítse meg, hogy mindkét fél, verzióik és kriptográfiai háttereik képesek egyeztetni. A hosszabb Blowfish-kulcs semmit nem változtat, ami számít, és egy új direktíva kitalálása egy ügyfélen az, ahogy egy működő alagút elromlottá válik. Tesztelje a változtatást egy ügyfélen és egy szerveren, mielőtt a flotta többi részéhez nyúl. Tartsa elérhetően a régi profilt a visszaállításhoz, amíg az új titkosítás át nem esik egy teljes kapcsolódási cikluson.

A változtatás alatt tartsa meg a tanúsítvány-ellenőrzést és a fiók-hitelesítést. Különböző kérdésekre válaszolnak: egy sikeres bejelentkezés nem szélesíthet blokkot, és egy jobb adattitkosítás nem menti fel a rossz szerverben való bizalmat.

Zárja le az ellenőrzést úgy, hogy új kapcsolaton ismét leolvassa az egyeztetett titkosítást, majd megerősíti, hogy a régi titkosítást már nem fogadják el. Ha egy fél még kínálja, a migráció nem fejeződött be, bármit is mond a profil a másik oldalon.