GCM (Galois / Counter Mode), in het bijzonder in combinatie met AES, is al jaren een de-facto gouden standaard. Versleutel en authenticeer in één stap, dat is gewoon te geweldig, en termen als AEAD werken goed om indruk te maken op een meisje, dus dat zou een win-win zijn. Maar, grapje terzijde …
Ik heb heb me altijd afgevraagd wat het zo speciaal maakt, en hoe langer ik erover nadenk, hoe minder ik het begrijp. Als je ernaar kijkt, dan is de algehele magie helemaal niet zo geweldig. Of misschien ben ik gewoon te dom om het te groken (vandaar mijn vraag).
Mijn gedachten:
Allereerst is GCM een vorm van tellermodus . Wat betekent dat in tegenstelling tot bijv. cipher block chaining, de output van één blok hangt af van precies één inputblok. Erger nog: je kunt een enkele bit wijzigen en het gedecodeerde resultaat zal precies in dat bit verschillen. Omdat als je eerlijk bent, een blokcijfer in tellermodus helemaal geen ” blokcijfer ” is, maar een (gecodeerde) PRNG gevolgd door een XOR-bewerking. In feite een ” blokkerig ” stroomcijfer. Er is niet veel voor nodig om een scenario voor te stellen waarin iemand dit zou kunnen misbruiken om berichten op een schadelijke manier te wijzigen (bijv. Verander ” transactie: +5.000 \ $ ” naar ” transactie: -5.000 \ $ “). Blokcijfers hebben normaal gesproken de aangeboren eigenschap dat ze in volledig gebrabbel veranderen terwijl je een enkel bit omdraait (plus, met chaining, de hele rest van het bericht). Dat is eigenlijk een heel mooie, wenselijke eigenschap, die we zonder goede reden overboord hebben gegooid.
Zeker, met de authenticator is de bovenstaande aanval moeilijk te bereiken, aangezien het geknoei zal worden ontdekt. Maar in feite lost de authenticator alleen het probleem op dat de keuze van de werkingsmodus geïntroduceerd .
GHASH is een MAC die extra geauthenticeerde gegevens ondersteunt. Voor zover ik kan zien, is dat “een regelrechte leugen. Of noem het ” optimistische overdrijving ” als je wilt. Het is gewoon een compressiefunctie met niet-intuïtieve wiskunde (voor niet-wiskundigen) erachter, maar uiteindelijk doet het niets anders dan een eenvoudige vermenigvuldiging en het weggooien van de helft van de invoerbits met het equivalent van ” overloop “. Dat is precies wat, met meer alledaagse wiskunde, kan worden gedaan in twee regels C-code per blok binnen een dozijn cycli (of als je het goed vindt met 32-bits vermenigvuldigingen in plaats van 64, kan parallel worden gedaan, bijvoorbeeld met AVX2 ” s vpmulld voor twee complete blokken in ~ 4 cycli).
Degenen die IDEA nog herinneren, zullen zich herinneren dat ze optelmod 2 16 en vermenigvuldiging mod 2 16 + gebruikten 1 als S-boxen die de aardige eigenschap hadden omkeerbaar te zijn (wat noodzakelijk is als je wilt ontsleutelen). Helaas kon dit niet worden uitgebreid tot 32-bits omdat 2 32 +1 isn ta priemgetal, dus niet alle invoer is gegarandeerd relatief priem, en daarom heb je moeite om de bewerking om te keren. Maar … dat is prima in ons geval, we willen niet onze compressiefunctie is omkeerbaar! Dus echt, ” simple “, zou gewone vermenigvuldiging ook moeten werken?
Dus die simpele, niet-speciale, niet-magische compressie functie is geïnitialiseerd met de sleutel en IV, waardoor de uiteindelijke output op de een of andere manier sleutelafhankelijk is, dus die gewone functie wordt in feite een MAC. Als je ” extra gegevens ” hebt, voer je die gewoon in de hash in voordat je je gegevens versleutelt, klaar. Nogmaals, dat is niet iets bijzonders.
Over het algemeen is het ook niets dat je niet zou kunnen bereiken met vrijwel elke andere hashfunctie .
Galois / counter gaat er nu van uit dat de tellermodus wordt gebruikt. De tellermodus (en zijn afgeleiden) en GHASH hebben het voordeel dat je blokken parallel kunt versleutelen / ontsleutelen. GHASH is ook triviaal parallel te maken.
Ja, prestaties ! Maar laten we eerlijk zijn, is dit echt een voordeel, of eerder een enorm nadeel ?
Maakt het uit hoe lang het duurt om een gigabyte of terabyte groot te decoderen bericht, en hoe goed kunt u dat werk parallelliseren? Of applicaties waarbij u absoluut in staat wilt zijn ” ” naar willekeurige posities te zoeken? Welnu, er zijn toepassingen waar dat van belang kan zijn, natuurlijk. Denk aan versleuteling van de volledige schijf. Maar u zou GCM in dat geval niet willen gebruiken, omdat u wilt dat de invoergrootte en de uitvoergrootte identiek zijn.
Voor een drukke server (of VPN) maakt het uit, of zo lijkt het , maar deze kunnen toch alles parallel verwerken aangezien ze veel gelijktijdige verbindingen hebben.Dus of je één stream parallel kunt schakelen of niet, maakt in het algemeen eigenlijk geen verschil. Hoe zit het met applicaties waar er maar weinig verbindingen zijn? Nou, normaal verzend je geen terabytes aan gegevens over een login-terminal, en als je dat doet, is je internetverbinding waarschijnlijk toch de beperkende factor, aangezien single-core prestaties gemakkelijk de GbE-bandbreedte overtreffen, zelfs op 7-8 jaar oude desktopprocessors .
Oké, het kan zijn dat je 2-3 seconden langer moet wachten bij het uitpakken van een versleuteld 2TB 7z-bestand op je harde schijf (als het maken van duizenden directory-items niet echt de bottleneck is, wat ik geneigd ben geloof dat dit het geval zal zijn). Hoe vaak heb je dat het afgelopen jaar gedaan? Ik: nul keer.
De enigen voor wie het echt een verschil maakt, zijn de ” slechteriken “, dat wil zeggen precies degenen voor wie u geen gemakkelijk leven wilt hebben. Zeker, als je triviaal kunt parallelliseren, worden aanvallen veel gemakkelijker. Gooi een kamer vol met speciale hardware (GPUs, FPGAs, wat dan ook) naar het probleem en laat het wegslijpen. Geen communicatie tussen knooppunten nodig? Nou, perfect, het kan niet beter worden.
Is dit echt een voordeel? Ik weet het niet, voor mij lijkt het een enorm nadeel. Ik zou eigenlijk het parallelliseren zo moeilijk mogelijk willen maken, niet zo gemakkelijk mogelijk.
Dus … genoeg nadenken, en op de vraag:
Wat is de fundamenteel ding dat ik mis aan GCM dat het zo geweldig maakt dat je het absoluut zou moeten gebruiken?
Reacties
- Maar wie zijn de ” slechteriken ” is onmogelijk te definiëren. En dat heeft een ENORME impact op de aanbevelingen van de overheid en de antwoorden op dit forum.
Antwoord
TL; DR: GCM levert uitstekende prestaties met de beste beveiligingseigenschappen die we tegenwoordig van cijfers verwachten (AEAD).
GCM gebruikt CTR om een stroomcijfer te bouwen. Dit is een goed bestudeerde methode, die maar één nadeel heeft: het heeft absoluut enige authenticatie nodig om bit flipping te voorkomen. Vóór GCM was CTR-then-MAC de oplossing. Een belangrijk voordeel van stroomcijfers is de afwezigheid van padding-aanvallen (omdat padding niet nodig is). Een ander voordeel is dat AES-CTR kan profiteren van de AES-NI-instructies.
GCM is CTR-then-MAC met betere prestaties . Een belangrijke verbetering ten opzichte van CRT-dan-MAC is de mogelijkheid om de uitvoering van codering en authenticatie te overlappen. Bovendien is bewezen dat het veilig is in het concrete beveiligingsmodel en het wordt niet gehinderd door patenten, dus het is een no-brainer om het te gebruiken.
Het heeft enkele nadelen: het is niet efficiënt in embedded hardware en het is moeilijk om efficiënt te implementeren. Het laatste punt wordt tegengegaan door bibliotheken te gebruiken die door anderen zijn geschreven. Dat zijn echter redenen waarom xchacha20-poly1305 populair werd boven GCM.
Reacties
- Ik zou een andere reden willen aanvoeren waarom ChaCha20 aan populariteit heeft gewonnen, is dat het niet AES is. Begrijp ‘ niet verkeerd, AES is een geweldig algoritme, maar letterlijk al onze eieren in één mandje stoppen, is misschien niet de slimste van alle ideeën. En het hebben van een ander goed getest algoritme naast AES is behoorlijk waardevol
- @ MechMK1 Ik ben het met je eens , maar ik heb niet geschreven dat dit allemaal de redenen zijn van ChaCha20 ‘ s populariteit, omdat die ‘ s niet de vraag die hier wordt gesteld, mijn punt was t hat GCM wordt niet beschouwd als ” geweldig ” zoals het OP denkt.
- Absoluut waar. Het is ‘ geen gouden gans, maar niemand werd ooit ontslagen omdat hij AES-GCM gebruikte, om zo te zeggen.
- En het is ‘ s niet bezwaard door patenten.
- @StephenTouset Bedankt, ik heb mijn bericht aangepast om jouw opmerking op te nemen.
Antwoord
Allereerst is GCM een vorm van tellermodus. Wat betekent dat in tegenstelling tot bijv. cipher block chaining, de output van één blok hangt af van precies één inputblok. Erger nog: je kunt een enkele bit wijzigen en het gedecodeerde resultaat zal precies in dat bit verschillen. Want als je eerlijk bent, is een blokcijfer in tellermodus helemaal geen “blokcijfer”, maar een (gecodeerde) PRNG gevolgd door een XOR-bewerking. In wezen een “blokkerig” stroomcijfer. Er is niet veel voor nodig om een scenario voor te stellen waarin iemand dit zou kunnen misbruiken om berichten op een schadelijke manier te veranderen (bijv. Verander “transactie: +5.000 \ $” in “transactie: -5.000 \ $”).
De berichtverificatie die GCM bovenop de CTR legt, maakt de maakbaarheid ervan onbeduidend.
Blokcijfers hebben normaal gesproken de aangeboren eigenschap dat ze in volledig onzin veranderen als je een enkel bit omdraait (plus, met een ketting, de hele rest van het bericht) . Dat is eigenlijk een heel mooie, wenselijke eigenschap, die we zomaar zonder goede reden overboord hebben gegooid.
Dit is heel, heel erg fout. Allereerst , De CBC-modus lijdt ook aan een soort zwakte van maakbaarheid; als je een bit van de cijfertekst omdraait, scramble je slechts één blok en draai het corresponderende bit van het netblok om. En er zijn andere kneedbaarheidsaanvallen tegen CBC; zie bijvoorbeeld de EFail-aanval .
Meer in het algemeen is uw informele idee dat berichten ‘volledig onzin worden’ niet goed genoeg. We hebben absoluut computers nodig om mechanisch te detecteren, met een duidelijk “ja / nee” antwoord, wanneer een versleuteld bericht is vervalst. Vertrouwen dat een mens vroeg genoeg op de hoogte zal zijn om “brabbeltaal” te herkennen, is niet genoeg.
GHASH is een MAC die extra geverifieerde gegevens ondersteunt. Voor zover ik kan zien, is dat een regelrechte leugen. Of noem het “optimistische overdrijving” als je wilt. Het is gewoon een compressiefunctie met niet-intuïtieve wiskunde (voor niet-wiskundigen) erachter, maar uiteindelijk doet het niets anders dan een eenvoudige vermenigvuldiging en het weggooien van de helft van de invoerbits met het equivalent van “overflow”.
De MAC werkt niet omdat de gebruikers de wiskunde niet begrijpen. Dat is hetzelfde als zeggen dat mensen geen satelliet-tv kunnen kijken omdat ze Ik weet geen calculus. Eindige-veld-MACs zijn een standaardconstructie die al tientallen jaren bekend is.
Dat is precies wat, met meer alledaagse wiskunde, kan worden gedaan in twee regels C code per blok binnen een dozijn cycli (of als je OK bent met 32-bits vermenigvuldigingen in plaats van 64, kan parallel worden gedaan, bijvoorbeeld met AVX2 “s vpmulld voor twee volledige blokken in ~ 4 cycli).
Er is echt discussie over of MACs die zijn gebaseerd op Galois-velden zoals GHASH, of MACs die zijn gebaseerd op prime-velden zoals Poly1305, een meer praktische keuze zijn. Veel ervan hangt af van de afwegingen tussen het ontwerpen van MACs om software- versus hardware-implementaties te benadrukken; Galois-veldvermenigvuldigingen zijn bijvoorbeeld nachtmerrieachtig in software, maar veel eenvoudiger dan rekenkundige vermenigvuldigingen in hardware. Een groot deel van de afwegingen hangt ook af van de kwetsbaarheid voor side-channel-aanvallen, bijvoorbeeld vermogensanalyse .
Maar er is geen discussie of Galois-velden of prime-velden fundamenteel niet van jou zijn nd. De wiskunde klopt op beide.
Ja, prestatie! Maar laten we eerlijk zijn, is dit echt een voordeel, of eerder een enorm nadeel?
Vertel dat aan de eindeloze optochten van ingenieurs door de decennia heen die hebben zich verzet tegen het toevoegen van encryptie aan producten vanwege de prestaties. En denk niet alleen aan krachtige pcs; denk aan embedded apparaten en wees erg bang voor het internet der dingen.
Ik bedoel, dit is helemaal geen dood probleem. De afgelopen jaren was er een heftig debat en de ontwikkeling van een nieuwe cryptografische constructie ter ondersteuning van volledige-schijfversleuteling op low-end Android-apparaten die werden beoordeeld niet krachtig genoeg voor de AES-gebaseerde algoritmen die Android eerder aanbood.
De enigen voor wie [prestatie] echt een verschil maakt, zijn de “slechteriken”, dat wil zeggen precies degenen voor wie u geen Natuurlijk, als je triviaal kunt parallelliseren, worden aanvallen veel gemakkelijker. Gooi een kamer vol met speciale hardware (GPUs, FPGAs, wat dan ook) bij het probleem en laat het wegslijpen.
Cijfers lossen dit op door voldoende grote sleutelgroottes te gebruiken, niet door de cijfers langzamer te maken. De bezorgdheid die u naar voren brengt, doet zich voor in wachtwoordgebaseerde cryptografie waar u geen “t hebben voldoende entropische geheime sleutels. 256-bits symmetrische sleutels zullen voor altijd meer dan groot genoeg zijn om elke brute force-aanval in ons universum te verslaan.
Wat is het fundamentele ding dat ik mis aan GCM dat het zo geweldig maakt dat je het absoluut moet gebruiken?
Je hoeft GCM niet absoluut te gebruiken Het is tegelijkertijd:
- Fundamentall y geluid en zeer breed ondersteund in hardware;
- bezwaard door een aantal nadelen die u niet naar voren bracht, zoals slechte softwareprestaties en catastrofale authenticiteitsfouten bij niet-herhaald hergebruik, die het in sommige praktische contexten vaak diskwalificeren .
Als u hardware heeft met native AES-GCM-ondersteuning en goed gecontroleerde software die hiervan gebruikmaakt, “zou het onverstandig zijn om deze niet onder uw beste kandidaten te plaatsen.