Vilka är fördelarna med Galois / Counter Mode?

TL; DR: GCM ger utmärkt prestanda med de bästa säkerhetsegenskaperna vi förväntar oss av chiffer idag (AEAD).

GCM använder CTR för att bygga en streamcipher. Detta är en väl studerad metod, som bara har en nackdel: den behöver absolut en del autentisering för att förhindra att bitar vänder. Innan GCM var CTR-då-MAC lösningen. En viktig fördel med strömkodare är frånvaron av utfyllnadsattacker (eftersom det inte finns något behov av utfyllnad). En annan fördel är att AES-CTR kan dra nytta av AES-NI-instruktionerna.

GCM är CTR-då-MAC med bättre prestanda . En viktig förbättring jämfört med CRT-då-MAC är möjligheten att överlappa exekveringen av kryptering och autentisering. Dessutom har det visat sig vara säkert i den konkreta säkerhetsmodellen och det belastas inte av patent, så det är ingen idé att använda den.

Det har vissa nackdelar: det är inte effektivt i inbäddad hårdvara. och det är svårt att implementera effektivt. Den sista punkten motverkas genom att använda bibliotek skrivna av andra. Det är dock skäl till varför xchacha20-poly1305 blev populär över GCM.

Kommentarer

• Jag skulle argumentera för en annan anledning till att ChaCha20 har vunnit popularitet är att det inte är AES. Inte ’ får inte fel på mig, AES är en bra algoritm, men att lägga bokstavligen alla våra ägg i en korg är kanske inte den smartaste av alla idéer. Och att ha en annan väl testad algoritm förutom AES är ganska värdefullt
• @ MechMK1 Jag håller med dig , men jag skrev inte att de är alla orsakerna till ChaCha20 ’ s popularitet, för att ’ s inte frågan här. Min poäng var t hat GCM anses inte vara ” fantastisk ” som OP menar.
• Helt sant. Det ’ är inte en gyllene gås, men ingen fick någonsin sparken för att använda AES-GCM, så att säga.
• Och det ’ är inte patenterade.
• @StephenTouset Tack, jag redigerade mitt inlägg för att inkludera din kommentar.

Först och främst är GCM en form av räknarläge. Vilket innebär att till skillnad från t.ex. cipher block chaining, beror utsignalen från ett block på exakt ett block av input. Ännu värre: Du kan ändra en enda bit och det dekrypterade resultatet kommer att skilja sig åt exakt den biten. För om du är ärlig är en blockkodning i räknarläge inte alls en ”blockcipher” utan en (nycklad) PRNG följt av en XOR-operation. I grund och botten en ”blocky” strömkryptering. Det krävs inte mycket för att föreställa sig ett scenario där någon kan missbruka detta för att ändra meddelanden på ett skadligt sätt (t.ex. ändra ”transaktion: +5 000 \ $” till ”transaktion: -5 000 \ $”).

Meddelandeautentisering som GCM-lager ovanpå CTR gör dess smidighet obetydlig.

Blockkodningar har normalt den medfödda egenskapen att förvandlas till fullständig gibberish när du vänder en enda bit (plus, med kedjning, hela resten av meddelandet) . Det är faktiskt en ganska trevlig, önskvärd egenskap som vi bara kastade överbord utan goda skäl.

Detta är väldigt, väldigt fel. Först och främst , CBC-läge lider också av en slags svaghet i formbarhet; om du vänder en bit av chiffertexten, krypterar du bara ett block och vänd motsvarande bit i nätblocket. Och det finns andra smidighetsattacker mot CBC; se till exempel EFail-attacken .

Mer allmänt är din informella uppfattning om att meddelanden ”förvandlas till ett fullständigt plåster” inte tillräckligt bra. Vi behöver absolut datorer för att mekaniskt upptäcka, med ett bestämt ”ja / nej” -svar, när ett krypterat meddelande har förfalskats. Att lita på att en människa kommer att vara tillräckligt tidigt för att upptäcka ”gibberish” är inte tillräckligt.

GHASH är en MAC som stöder extra autentiserad data. Enligt vad jag kan säga är det en lögn. Eller kalla det ”optimistisk överdrift” om du vill. Det är bara en kompressionsfunktion med icke-intuitiv matematik (till icke-matematiker) bakom, men i slutändan gör det ingenting annat än en enkel multiplikation och slänga bort hälften av inmatningsbitarna med motsvarande ”överflöd”.

MAC fungerar inte för att användarna inte förstår matematiken. Det är som att folk inte kan titta på satellit-TV för att de inte vet inte kalkyl. Finite field MACs är en standardkonstruktion, känd i årtionden nu.

Vilket är precis vad, med mer vardaglig matematik, kan göras i två rader av C kod per block inom ett dussin cykler (eller om du är OK med att använda 32-bitars multiplikationer istället för 64, kan göras parallellt, t.ex. med AVX2 ”s vpmulld för två kompletta block i ~ 4 cykler).

Det diskuteras faktiskt om MAC-baserade på Galois-fält som GHASH, eller MAC-baserade på primära fält som Poly1305, är ett mer praktiskt val. Mycket av det beror på avvägningarna mellan att designa MAC: er för att betona programvara kontra hårdvaruimplementeringar, t.ex. Galois-fältmultiplikationer är mardrömmande i programvara, men mycket enklare än aritmetiska multiplikationer i hårdvara. .

Men det finns ingen debatt om antingen Galois-fält eller primära fält i grunden är osäkra nd. Matematiken kolla in båda.

Yay, performance! Men låt oss vara ärliga, är detta verkligen en fördel, eller snarare en enorm nackdel?

Berätta för de oändliga paraderna av ingenjörer genom decennierna som har motstått att lägga till kryptering till produkter på grund av prestanda. Och tänk inte bara på kraftfulla datorer; tänk på inbäddade enheter och var väldigt rädd för sakernas internet.

Jag menar, det här är inte en död fråga alls. Under de senaste åren har det skett en kraftig debatt och utvecklingen av en ny kryptografisk konstruktion för att stödja fullskivkryptering på low-end Android-enheter som bedömdes inte tillräckligt kraftfullt för de AES-baserade algoritmerna som Android erbjuds tidigare.

De enda som [performance] verkligen gör skillnad är ”bad guys”, dvs. exakt de som du inte vill ha en enkelt liv. Visst nog, om du kan trivialt parallellisera, blir attacker mycket enklare. Kasta ett rum fullt av dedikerad hårdvara (GPU: er, FPGA: er, vad som helst) på problemet och låt det slipa bort.

Kodare löser detta genom att använda tillräckligt stora nyckelstorlekar, inte genom att låta koderna sakta ner. Det bekymmer du tar upp uppstår i lösenordsbaserad kryptografi där du inte ”t har tillräckligt entropiska hemliga nycklar. 256-bitars symmetriska nycklar kommer för alltid att vara mer än stora nog för att besegra alla brutala kraftattacker i vårt universum.

Vad är det grundläggande som jag saknar om GCM som gör det så fantastiskt att du absolut borde använda det?

Du behöver inte absolut använda GCM Det är samtidigt:

• Fundamentall y-ljud och mycket stött i hårdvara;
• Besvärade av ett antal nackdelar som du inte tog upp, som dålig programvaruprestanda och katastrofalt äkthetsfel vid icke-återanvändning, som ofta diskvalificerar det i vissa praktiska sammanhang .

Om du har hårdvara som har inbyggt AES-GCM-stöd och väl granskad programvara som utnyttjar den, skulle det vara klokt att inte ha den bland dina bästa kandidater.