A GCM (Galois / Counter Mode), különösen az AES-sel kombinálva, évek óta de facto aranystandard. Titkosítás és hitelesítés egy lépésben, ez túl félelmetes, és az AEAD-hez hasonló kifejezések jól működnek a lány benyomásában, így ez mindenki számára előnyös lehet. De, viccet félretéve …
I “ve mindig azon gondolkodtam, hogy mitől olyan különleges, és minél tovább gondolkodom rajta, annál kevésbé értem. Ha megnézed, akkor az általános varázslat egyáltalán nem olyan fantasztikus. Vagy talán, talán túl hülye vagyok ahhoz, hogy megfogjam (ezért a kérdésem).
Gondolataim:
Először is, a GCM a számláló mód egyik formája. Ami azt jelenti, hogy ellentétben pl. rejtjelblokk-láncolás, egy blokk kimenete pontosan egy bemeneti blokktól függ. Még rosszabb: Egyetlen bitet módosíthat, és a visszafejtett eredmény pontosan abban a bitben fog különbözni. Mert ha őszinte vagy, akkor a számláló módban lévő blokkos titkosítás egyáltalán nem ” blokkos titkosítás “, hanem egy (kulcsos) PRNG XOR művelet követi. Alapvetően egy ” blokkolt ” stream titkosítás. Nem kell sokat elképzelni egy olyan forgatókönyvet, ahol valaki visszaélhet ezzel az üzenetek káros módon történő megváltoztatásához (pl. Változás ” tranzakció: +5 000 \ $ ” – ” tranzakció: -5,000 \ $ “). A blokkosírók általában azzal a veleszületett tulajdonsággal rendelkeznek, hogy teljes hamisítássá válnak miközben egyetlen bitet fordítasz (ráadásul láncolással, az üzenet egészének maradékát). Ez valójában egy nagyon kedves, kívánatos tulajdonság, amelyet csak ok nélkül dobtunk a hajóra.
Persze, a hitelesítővel , a fenti támadást nehéz megvalósítani, mivel a beavatkozást felfedezik. De alapvetően a hitelesítő csak azt a problémát oldja meg, hogy a működési mód megválasztása bevezetésre került .
A GHASH egy MAC, amely extra hitelesített adatokat támogat. Abból, amit meg tudok mondani, ez egyenesen hazugság. Vagy nevezd ” optimista túlzásnak “, ha akarod. Csak egy tömörítési függvény, amely mögött nem intuitív matematika áll (nem matematikusok számára), de végül nem tesz mást, mint egy egyszerű szorzást és a bemeneti bitek felének eldobását ” túlcsordulás “. Éppen ez az, amit hétköznapibb matematikával lehet elvégezni két C-sor soronként blokkonként egy tucat cikluson belül (vagy ha jól érzed magad 64-es helyett 32 bites szorzók használatával, párhuzamosan megtehető pl. Az AVX2-vel ” s vpmulld két teljes blokkra ~ 4 ciklusban).
Azok, akik még emlékeznek az IDEA-ra, emlékeztetnek arra, hogy a 2-es adds mod 16 és a multiplication mod 2 16 + 1 S-boxként, amelyeknek megvan az a tulajdonsága, hogy visszafordíthatók (szükség van rá, ha visszafejteni akarod). Szerencsére ez nem terjeszthető ki 32 bitre, mert 2 32 +1 nem “ta” prímszám, tehát nem minden bemenet garantáltan viszonylag prím, és így gondjai vannak a művelet megfordításával. De … ez esetünkben nagyon jó, nem akarjuk a tömörítési függvényünk invertálható! Tehát valóban, ” egyszerű “, a hétköznapi szorzásnak is csak trükköt kell tennie?
Tehát, ez az egyszerű, különleges, nem varázslatos tömörítés A függvény véletlenül inicializálva van a kulccsal és az IV-vel, ami a végső kimeneti kulcsot így vagy úgy függővé teszi, tehát hogy a hétköznapi funkció hatékonyan MAC-vá válik. Ha vannak ” további adatai “, akkor az adatok titkosítása előtt csak be kell töltenie azokat a kivonatba. Ismételten, ez nem valami szuper különleges.
Összességében ez semmi, amit nem lehetne elérni nagyjából minden más hash funkcióval is.
Most a Galois / counter feltételezi, hogy a számláló módot használják. A számláló mód (és annak származékai), valamint a GHASH előnye, hogy párhuzamosan titkosíthatja / visszafejtheti a blokkokat. A GHASH is triviálisan párhuzamosítható.
Igen, teljesítmény ! De legyünk őszinték, valóban előny, vagy inkább óriási hátrány ?
Nem számít, mennyi időbe telik egy gigabájtos vagy terabájtos méretű dekódolás? üzenetet, és mennyire tudja párhuzamosítani ezt a munkát? Vagy olyan alkalmazások, amelyekben feltétlenül ” véletlenszerű pozíciókba akar keresni “? Nos, vannak olyan alkalmazások, ahol ez számíthat, biztos. Eszembe jut a teljes lemezes titkosítás. De ebben az esetben nem akarja használni a GCM-et, mivel azt szeretné, hogy a bemeneti és a kimeneti méret megegyezzen. , de ezek úgyis bármit feldolgozhatnak párhuzamosan, mivel sok egyidejű kapcsolatuk van.Tehát attól függetlenül, hogy tud-e párhuzamosítani az egy folyamot, vagy sem, összességében semmi különbség nincs. Mi a helyzet azokkal az alkalmazásokkal, ahol csak kevés kapcsolat van? Nos, általában nem terabájt adatot továbbít egy bejelentkezési terminálon keresztül, és ha mégis, akkor valószínűleg mégis az internetkapcsolata a korlátozó tényező, mivel az egymagos teljesítmény könnyedén felülmúlja a GbE sávszélességét még 7-8 éves asztali processzorokon is. .
Rendben, lehet, hogy 2-3 másodperccel tovább kell várnia, amikor kibontja a titkosított 2 TB 7z-fájlt a merevlemezre (ha több ezer címjegyzék létrehozása nem igazán az a szűk keresztmetszet, amelyre hajlamos vagyok hisz ez lesz a helyzet). Milyen gyakran tetted ezt az elmúlt évben? Én: nulla alkalommal.
Az egyetlen, akinek valóban különbséget jelent, az a ” rossz fiúk “, vagyis pontosan azok, akiknek nem akarsz könnyű életet élni. Valóban, ha triviálisan tudsz párhuzamosítani, a támadások sokkal könnyebbé válnak. Dobjon egy szobát, amely tele van külön hardverrel (GPU-k, FPGA-k, bármi más) a problémával, és hagyja, hogy megőrüljön. Nincs szükség kommunikációra a csomópontok között? Nos, tökéletes, nem lehet jobb.
Ez valóban előny? Nem tudom, számomra ez hatalmas hátránynak tűnik. Ha van valami, azt szeretném, ha a párhuzamosítás a lehető legkeményebb, nem pedig a lehető legegyszerűbb lenne.
Tehát … eléggé elgondolkodni, és a kérdésre:
alapvető dolog, amit hiányolok a GCM-ből, ami annyira félelmetes, hogy feltétlenül használd?
Megjegyzések
- De csak kik a ” rosszfiúkat ” lehetetlen meghatározni. És ez HATALMAS hatással van a kormányzati ajánlásokra és a fórum válaszaira.
Válasz
TL; DR: A GCM kiváló teljesítményt nyújt a legjobb biztonsági tulajdonságokkal, amelyeket ma elvárunk a rejtjelektől (AEAD).
A GCM a CTR használatával készíti el a stream titkosítását. Ez egy jól tanulmányozott módszer, amelynek csak egyetlen hátránya van: feltétlenül szüksége van némi hitelesítésre a bitek megfordulásának megakadályozásához. A GCM előtt a CTR-majd a MAC volt a megoldás. A stream cifrák egyik fő előnye a párnázási támadások hiánya (mivel nincs szükség paddingra). További előny, hogy az AES-CTR kihasználhatja az AES-NI utasításokat.
A GCM a CTR, majd a MAC, jobb teljesítménnyel . Az egyik legfontosabb fejlesztés a CRT-majd MAC-hez képest a titkosítás és a hitelesítés végrehajtásának átfedése. Ráadásul a konkrét biztonsági modellben bizonyítottan biztonságos, és nem szabadalmak terhelik, ezért “nem gond használni”.
Van néhány hátránya: nem hatékony a beágyazott hardverekben és ezt nehéz hatékonyan megvalósítani. Az utolsó pontot mások által írt könyvtárak segítségével lehet ellensúlyozni. Mindazonáltal ezek az okok, amelyek miatt az xchacha20-poly1305 népszerűvé vált a GCM felett.
Megjegyzések
nagyszerű algoritmus, de szó szerint minden tojásunkat egy kosárba tenni talán nem a legokosabb az összes ötlet közül. És az AES-től eltekintve egy másik jól tesztelt algoritmus nagyon értékes
Válasz
Először is, a GCM a számláló mód egyik formája. Ami azt jelenti, hogy ellentétben pl. rejtjelblokk-láncolás, egy blokk kimenete pontosan egy bemeneti blokktól függ. Még rosszabb: Egyetlen bitet módosíthat, és a visszafejtett eredmény pontosan abban a bitben fog különbözni. Mert ha őszinte vagy, akkor a számláló üzemmódban lévő blokk titkosítás egyáltalán nem “blokk titkosítás”, hanem egy (kulcsos) PRNG, amelyet XOR művelet követ. Alapvetően egy “blokkos” stream-rejtjel. Nem kell sokat elképzelni egy olyan forgatókönyvet, ahol valaki visszaélhet ezzel az üzenetek káros módon történő megváltoztatásához (pl. “Tranzakció: +5,000 \ $” módosítása “tranzakció: -5,000 \ $”).
Az az üzenethitelesítés, amelyet a GCM a CTR tetejére fektet, következetlenné teszi a alakíthatóságát.
A blokkosírók általában azzal a veleszületett tulajdonsággal rendelkeznek, hogy teljes hamisítássá válnak, amikor egyetlen bitet fordítasz (plusz, láncolással, az üzenet egészének maradékát) . Ez valójában egy nagyon kedves, kívánatos tulajdonság, amelyet csak ok nélkül dobtunk a vízbe.
Ez nagyon-nagyon helytelen. Először is , A CBC mód egyfajta alakíthatósági gyengeséget is szenved; ha a titkosított szöveg egy bitjét átfordítja, csak egy blokkot téveszt meg és fordítsa meg a netblokk megfelelő bitjét. És vannak más alakíthatósági támadások a CBC ellen; lásd például: az EFail támadást .
Általánosabban fogalmazva, az ön informális elképzelése, miszerint az üzenetek “teljes szemétlá válnak”, nem elég jó. Szükségünk van számítógépekre, hogy mechanikusan, határozott “igen / nem” válasz esetén észlelhessenek titkosított üzenet hamisítását. Abban bízni, hogy egy ember elég korán lesz a hurokban, hogy észrevegye a “zabálást”, nem elég.
A GHASH egy MAC, amely extra hitelesített adatokat támogat. Abból, amit elmondhatok, ez egyenesen hazugság. Vagy nevezd “optimista túlzásnak”, ha akarod. Ez csak egy tömörítési funkció, amely mögött nem intuitív matematika áll (nem matematikusok számára), de végül nem tesz mást, mint egyszerű szorzást és a bemeneti bitek felének eldobását a “túlcsordulás” egyenértékével.
A MAC nem működik, mert a felhasználók nem értik a matematikát. Ez olyan, mintha azt mondanánk, hogy az emberek nem nézhetnek műholdas TV-t, mert nem “Nem tudom a kalkulust. A véges terepi MAC-k egy szabványos konstrukció, amely évtizedek óta ismert.
Éppen ez az, amit hétköznapibb matematikával lehet elvégezni a C két sorában. kód blokkonként egy tucat cikluson belül (vagy ha jól érted a 64 bites 32-bites szorzók használatát, párhuzamosan megtehető pl. az AVX2 vpmulld-jével két teljes blokkra ~ 4 ciklusban).
Aktuális vita folyik arról, hogy a Galois-mezőkön alapuló MAC-ok, mint például a GHASH, vagy a MAC-ok, amelyek olyan elsődleges mezőkön alapulnak, mint a Poly1305, praktikusabb választás-e. Sok ez a kompromisszumokon múlik. a MAC-ek megtervezése között a szoftveres és a hardveres megvalósítás hangsúlyozása érdekében; pl. a Galois-terepi szorzások rémálmásak a szoftverekben, de sokkal egyszerűbbek, mint a hardveres aritmetikai szorzások. A kompromisszumok jó része az oldalsó csatorna támadásokkal szembeni sebezhetőségen is alapul, pl. energiaelemzés .
De nincs vita arról, hogy a Galois-mezők vagy az elsődleges mezők alapvetően nem megfelelőek-e nd. A matematika mindkettőt ellenőrzi.
Igen, teljesítmény! De legyünk őszinték, ez valóban előny, vagy inkább óriási hátrány?
Mondja el ezt a mérnökök évtizedeken át tartó végtelen felvonulásainak, akik ellenálltak a termékek titkosításának a teljesítmény miatt. És ne csak a nagy teljesítményű számítógépekre gondoljunk; gondoljon a beágyazott eszközökre, és nagyon féljen a tárgyak internetétől.
Úgy értem, ez egyáltalán nem halott kérdés. Az elmúlt néhány évben élénk vita folyt és egy új kriptográfiai konstrukció kifejlesztése , amely támogatta a teljes lemezes titkosítást alacsony szintű Android készülékeken, amelyeket megítéltek nem elég erős az Android által korábban kínált AES-alapú algoritmusokhoz.
Az egyetlen, akinek [teljesítménye] valóban különbséget jelent, a “rossz fiúk”, vagyis pontosan azok, akiknek nem akar könnyű élet. Valóban, ha triviálisan tudsz párhuzamosítani, a támadások sokkal könnyebbé válnak. Dobj egy szobát, amely tele van dedikált hardverrel (GPU-k, FPGA-k, bármi más) a problémával, és hagyd, hogy őrlődjön.
A cifrák ezt elég nagy kulcsméretek használatával oldják meg, nem pedig a rejtjelek lelassításával. Az Ön által felvetett aggály a jelszó-alapú titkosításban merül fel, ahol nem “Nincsenek kellően entrópikus titkos kulcsok. A 256 bites szimmetrikus kulcsok örökké nagyobbak lesznek, mint elég nagyok ahhoz, hogy legyőzzék az univerzumunk bármely durva erővel járó támadását.
az az alapvető dolog, ami hiányzik a GCM-ről, ami annyira félelmetes, hogy feltétlenül használnod kell?
Nem feltétlenül kell használni a GCM-et . Ugyanakkor:
- Alapvető hangzik és nagyon széles körben támogatott a hardverben;
- számos olyan hátrány miatt, amelyeket nem hozott fel, mint például a gyenge szoftveres teljesítmény és a nem megfelelő újrafelhasználás során bekövetkezett katasztrofális hitelességi hiba, amely gyakran kizárja bizonyos gyakorlati összefüggésekben .
Ha rendelkezik olyan hardverrel, amely natív AES-GCM támogatással rendelkezik, és jól ellenőrzött szoftverrel, amely kihasználja azt, akkor nem lenne bölcs dolog, ha nem szerepelne a legjobb jelöltjei között.