GCM (režim Galois / Counter), zejména v kombinaci s AES, je již léta de facto zlatým standardem. Šifrujte a ověřujte v jednom kroku, to je prostě příliš úžasné a termíny jako AEAD fungují dobře, aby zapůsobily na dívku, takže by to bylo výhodné pro obě strany. Ale žert stranou …
Já vždycky přemýšlel, v čem je tak výjimečný, a čím déle o tom přemýšlím, tím méně tomu rozumím. Když se na to podíváte, pak celková magie vůbec není tak úžasná. Nebo možná, možná jsem jen tak hloupá, abych to pochopila (proto moje otázka).
Moje myšlenky:
Nejprve je GCM formou režimu počítadla . Což znamená, že na rozdíl od např. řetězení šifrovacích bloků, výstup jednoho bloku závisí na přesně jednom bloku vstupu. Ještě horší: Můžete upravit jeden bit a dešifrovaný výsledek se bude lišit přesně v tomto bitu. Protože pokud jste upřímní, bloková šifra v režimu čítače vůbec není “ blokovou šifrou „, ale (klíčovanou) PRNG následuje operace XOR. V zásadě “ blocky “ proudová šifra. Nestačí si představit scénář, kdy by to někdo mohl zneužít ke změně zpráv škodlivým způsobem (např. Změna “ transakce: +5 000 \ $ “ až “ transakce: -5 000 \ $ „). Blokové šifry mají obvykle vrozenou vlastnost proměnit se v úplný blábol při převrácení jediného bitu (navíc s řetězením celý zbytek zprávy). To je vlastně docela pěkná a žádoucí vlastnost, kterou jsme bez dobrého důvodu prostě hodili přes palubu.
Jistě, s autentizátorem , výše uvedeného útoku je obtížné dosáhnout, protože bude odhalena neoprávněná manipulace. Ale v zásadě autentizátor pouze opravuje problém, že volba provozního režimu byla zavedena .
GHASH je MAC, který podporuje extra autentizovaná data. Podle toho, co mohu říci, je to naprostá lež. Nebo tomu můžete říkat “ optimistické přehánění “ pokud chcete. Je to jen kompresní funkce s neintuitivní matematikou (pro nematematiky) vzadu, ale nakonec nedělá nic jiného než jednoduché násobení a zahodení poloviny vstupních bitů s ekvivalentem “ přetečení „. Což je právě to, co lze s běžnější matematikou udělat ve dvou řádcích kódu C na blok v rámci tuctu cyklů (nebo pokud jste v pořádku s použitím 32bitových multiplikací namísto 64, lze provést paralelně, např. S AVX2 “ s vpmulld pro dva kompletní bloky za ~ 4 cykly).
Ti, kteří si IDEA stále pamatují, si vzpomínají, že použili doplněk mod 2 16 a multiplication mod 2 16 + 1 jako S-boxy, které měly pěknou vlastnost, že jsou reverzibilní (trochu nutné, pokud chcete dešifrovat). Bohužel to nemohlo být rozšířeno na 32 bitů, protože 2 32 +1 není prvočíslo, takže není zaručeno, že všechny vstupy budou relativně prvočíselné, a proto máte potíže s invertováním operace. Ale … to je v našem případě moc dobrá pokuta, nechceme naše funkce komprese je invertovatelná! Takže opravdu “ jednoduché „, obyčejné násobení by mělo stačit také?
Takže ta jednoduchá, ne-speciální, ne-magická komprese funkce se stane inicializována pomocí klíče a IV, což mimochodem způsobí, že konečný výstupní klíč bude tak či onak závislý, takže tato běžná funkce se efektivně stane MAC. Pokud máte “ data navíc „, stačí je před zašifrováním dat vložit do hash. Opět platí, že to není něco mimořádného.
Celkově to není nic, čeho byste nemohli dosáhnout ani díky každé další hashovací funkci .
Nyní Galois / counter předpokládá, že bude použit režim čítače. Režim čítače (a jeho deriváty) stejně jako GHASH mají tu výhodu, že můžete šifrovat / dešifrovat bloky paralelně. GHASH je také triviálně paralelizovatelný.
Ano, výkon ! Ale buďme upřímní, je to opravdu výhoda, nebo spíše obrovská nevýhoda ?
Záleží na tom, jak dlouho trvá dešifrování velikosti gigabajtů nebo terabajtů a jak dobře můžete tuto práci paralelizovat? Nebo aplikace, kde absolutně chcete mít možnost “ hledat “ na náhodné pozice? Jistě, existují aplikace, kde na tom může záležet. Připadá mi v úvahu šifrování celého disku. Ale v tom případě byste nechtěli použít GCM, protože chcete, aby vstupní velikost a výstupní velikost byly identické.
Na zaneprázdněném serveru (nebo VPN) to bude vadit, nebo tak to vypadá , ale tito mohou stejně zpracovávat cokoli paralelně, protože mají mnoho souběžných připojení.To, zda můžete paralelizovat jeden stream, tedy celkově nemá žádný rozdíl. A co aplikace, kde je jen málo spojení? Normálně nepřenášíte terabajty dat přes přihlašovací terminál, a pokud tak učiníte, vaše internetové připojení je i tak pravděpodobně limitujícím faktorem, protože jednojádrový výkon snadno předčí šířku pásma GbE i na stolních procesorech starých 7 až 8 let .
Dobře, možná budete muset počkat o 2–3 sekundy déle, když na svém pevném disku extrahujete zašifrovaný soubor 2TB 7z (pokud vytváření tisíců položek adresáře opravdu není překážkou, k čemuž mám sklon věříte, že tomu tak bude.) Jak často jste to za poslední rok dělali? Já: nula krát.
Jediní, na kterých to opravdu dělá rozdíl, je “ padouchy „, tj. přesně ti, kterým nechcete mít snadný život. Jistě, pokud můžete triviálně paralelizovat, jsou útoky mnohem jednodušší. Vrhněte na místnost místnost plnou vyhrazeného hardwaru (GPU, FPGA, cokoli) a nechte to rozdrtit. Není nutná komunikace mezi uzly? No, perfektní, už to nemůže být lepší.
Je to opravdu výhoda? Nevím, pro mě to vypadá jako obrovská nevýhoda. Pokud vůbec, chci paralelizaci co nejtěžší, ne tak snadnou, jak je to možné.
Takže … dost přemýšlení, a na otázku:
Co je to základní věc, která mi na GCM chybí, díky níž je tak úžasná, že byste ji měli absolutně používat?
Komentáře
- Ale kdo jsou “ padouchy “ nelze definovat. A to má OBROVSKÝ dopad na vládní doporučení a odpovědi na tomto fóru.
Odpověď
TL; DR: GCM poskytuje vynikající výkon s nejlepšími bezpečnostními vlastnostmi, jaké od dnešních šifer očekáváme (AEAD).
GCM používá CTR k vytvoření proudové šifry. Jedná se o dobře studovanou metodu, která má pouze jednu nevýhodu: absolutně potřebuje určité ověřování, aby se zabránilo převrácení bitů. Před GCM bylo řešením CTR-then-MAC. Jednou z hlavních výhod proudových šifer je absence útoků polstrováním (protože polstrování není potřeba). Další výhodou je, že AES-CTR může těžit z pokynů AES-NI.
GCM je CTR-then-MAC s lepším výkonem . Jedním z klíčových vylepšení oproti CRT-then-MAC je schopnost překrývat provádění šifrování a ověřování. Kromě toho se v konkrétním bezpečnostním modelu prokázalo, že je bezpečný, a že není zatížen patenty, takže jeho používání není vůbec jednoduché.
Má několik nevýhod: ve vestavěném hardwaru není efektivní. a je těžké jej efektivně implementovat. Proti poslednímu bodu se staví pomocí knihoven napsaných jinými. To jsou však důvody, proč se xchacha20-poly1305 stal populárním u GCM.
Komentáře
- Tvrdil bych, že dalším důvodem, proč si ChaCha20 získal popularitu, je to, že není AES. Nechápejte mě špatně, AES je skvělý algoritmus, ale dát doslova všechna naše vejce do jednoho koše možná není nejchytřejší ze všech nápadů. A mít kromě AES ještě jeden dobře odzkoušený algoritmus je docela cenné
- @ MechMK1 Souhlasím s vámi , ale nenapsal jsem, že to jsou všechny důvody popularity ChaCha20 ‚, protože to ‚ Nejedná se o tu položenou otázku klobouk GCM není považován za “ úžasný „, jak si OP myslí.
- Absolutně pravda. Není to ‚ zlatá husa, ale nikdo za použití AES-GCM, abych tak řekl, nikdy nebyl vyhozen.
- A ‚ není zatížen patenty.
- @StephenTouset Díky, upravil jsem svůj příspěvek tak, aby obsahoval váš komentář.
Odpověď
GCM je především formou režimu počítadla. Což znamená, že na rozdíl od např. řetězení šifrovacích bloků, výstup jednoho bloku závisí na přesně jednom bloku vstupu. Ještě horší: Můžete upravit jeden bit a dešifrovaný výsledek se bude lišit přesně v tomto bitu. Protože pokud jste upřímní, bloková šifra v režimu čítače není vůbec „blokovou šifrou“, ale (klíčovanou) PRNG následovanou operací XOR. V zásadě „bloková“ proudová šifra. Nestačí si představit scénář, kdy by to někdo mohl zneužít ke změně zpráv škodlivým způsobem (např. Změnit „transakce: +5 000 \ $“ na „transakce: -5 000 \ $“).
Díky ověřování zpráv, které vrstvy GCM navrchu CTR činí, je jeho tvárnost bezvýznamná.
Blokové šifry mají obvykle vrozenou vlastnost proměnit se v úplný blábol, když otočíte jeden bit (plus, s řetězením, celý zbytek zprávy) . To je ve skutečnosti docela pěkná a žádoucí vlastnost, kterou jsme bezdůvodně hodili přes palubu.
To je velmi, velmi špatné. , Režim CBC také trpí určitou slabostí tvárnosti; pokud otočíte jeden bit ciphertextu, vyškrábete pouze jeden blok a převrátit odpovídající bit síťového bloku. A proti CBC existují i další útoky tvárnosti; podívejte se například na útok EFail .
Obecněji řečeno, vaše neformální představa o zprávách, které se „stávají úplnými blázny“, není dost dobrá. Bezpodmínečně potřebujeme počítače, aby mechanicky detekovaly definitivní odpověď „ano / ne“, když byla šifrována zpráva. Důvěřovat, že člověk bude ve smyčce dostatečně brzy na to, aby zjistil „gibberish“, není dost.
GHASH je MAC, který podporuje další ověřená data. Podle toho, co poznám, je to vyložená lež. Nebo tomu můžete říkat „optimistické přehánění“. Je to jen funkce komprese s neintuitivní matematikou (pro nematematiky) vzadu, ale nakonec nedělá nic jiného než jednoduché násobení a vyhodení poloviny vstupních bitů s ekvivalentem „overflow“.
MAC nefunguje, protože uživatelé nerozumí matematice. To je jako říkat, že lidé nemohou sledovat satelitní TV, protože ne „Neznám počet. MAC s konečným polem jsou standardní konstrukcí známou již desítky let.
Což je právě to, co lze s pozemskou matematikou udělat ve dvou řádcích C kód na blok během desítek cyklů (nebo pokud jste v pořádku s použitím 32bitových multiplikací namísto 64, lze provést paralelně, např. pomocí programu AVX2 „s vpmulld pro dva kompletní bloky za ~ 4 cykly).
Existuje skutečná debata o tom, zda jsou MAC založené na polích Galois, jako je GHASH, nebo MAC založené na hlavních polích, jako je Poly1305, praktičtější volbou. Mnoho z nich závisí na kompromisech mezi návrhem MAC pro zdůraznění implementace softwaru vs. hardwaru; např. multiplikace pole Galois jsou v softwaru noční můrou, ale mnohem jednodušší než aritmetické multiplikace v hardwaru. Velká část kompromisů závisí také na zranitelnosti vůči útokům bočních kanálů, např. analýza výkonu .
Ale není tu debata o tom, zda jsou Galoisova pole nebo prvočísla v zásadě nepřijatelná nd. Matematika se započítává do obou.
Ano, výkon! Ale buďme upřímní, je to opravdu výhoda, nebo spíše obrovská nevýhoda?
Řekněte to nekonečným průvodům inženýrů v průběhu desetiletí, kteří se bránili přidávání šifrování do produktů z důvodu výkonu. A nemyslete jen na výkonné počítače; přemýšlejte o vestavěných zařízeních a velmi se bojte internetu věcí.
Myslím, že to není vůbec mrtvý problém. Během posledních několika let proběhla intenzivní debata a vývoj nové kryptografické konstrukce , která by podporovala šifrování celého disku na zařízeních Android nižší třídy, která byla posouzena není dostatečně výkonný pro dříve nabízené algoritmy založené na AES.
Jediní, u nichž [performance] skutečně dělá rozdíl, jsou „padouchy“, tj. přesně ti, které nechcete mít snadný život. Jistě, pokud dokážete triviálně paralelizovat, jsou útoky mnohem jednodušší. Vyhoďte místnost plnou vyhrazeného hardwaru (GPU, FPGA, cokoli) s problémem a nechte ho rozdrtit.
Šifry to řeší použitím dostatečně velkých velikostí klíčů, nikoli zpomalením šifer. Obavy, které vyvoláváte, vznikají v heslem kryptografii, kde nemáte „Nemám dostatečně entropické tajné klíče. 256bitové symetrické klíče budou navždy dostatečně velké, aby porazily jakýkoli útok hrubou silou v našem vesmíru.
Co je základní věc, která mi na GCM chybí, díky níž je tak úžasná, že byste ji měli absolutně používat?
GCM absolutně nemusíte používat . Je to zároveň:
- Fundamentall y zvuk a velmi široce podporován v hardwaru;
- Zatíženo řadou nevýhod, které jste nevyvolali, jako je špatný výkon softwaru a katastrofické selhání autenticity při opakovaném použití, které jej v některých praktických kontextech často diskvalifikují .
Pokud máte hardware, který má nativní podporu AES-GCM, a dobře auditovaný software, který jej využívá, nebylo by nemoudré jej mezi svými nejlepšími kandidáty mít.