GCM (Galois / Counter Mode), især i kombination med AES, har været en de facto guldstandard i årevis. Krypter og godkend i et trin, at “det er bare for fantastisk, og udtryk som AEAD fungerer godt for at imponere en pige, så det ville være win-win. Men joke til side …
Jeg har spekulerede altid på, hvad der gør det så specielt, og jo længere jeg tænker på det, jo mindre forstår jeg. Hvis du ser på det, så er den overordnede magi slet ikke så fantastisk. Eller måske, måske er jeg bare for dum til at narre det (deraf mit spørgsmål).
Mine tanker:
For det første er GCM en form for tællertilstand . Hvilket betyder, at i modsætning til f.eks. cipher block chaining, afhænger output af en blok af nøjagtigt en blok af input. Værre endnu: Du kan ændre en enkelt bit, og det dekrypterede resultat vil variere i nøjagtigt den bit. For hvis du er ærlig, er en blokciffer i tællertilstand slet ikke en ” blokcipher “, men en (indtastet) PRNG efterfulgt af en XOR-operation. Dybest set er en ” blokeret ” streamcipher. Det tager ikke meget at forestille sig et scenarie, hvor nogen kan misbruge dette for at ændre beskeder på en skadelig måde (f.eks. Ændre ” transaktion: +5.000 \ $ ” til ” transaktion: -5.000 \ $ “). Blokcifre har normalt den medfødte egenskab at blive til komplet gibberish når du vender en enkelt bit (plus, med kæde, hele resten af meddelelsen). Det er faktisk en ret flot, ønskelig egenskab, som vi bare kastede overbord uden god grund.
Sikker med autentificatoren , er ovenstående angreb vanskeligt at opnå, da manipulationen vil blive opdaget. Men grundlæggende løser godkenderen kun problemet, at valget af driftsmåde indført .
GHASH er en MAC, der understøtter ekstra godkendte data. Efter hvad jeg kan fortælle, at “det er en direkte løgn. Eller kald det ” optimistisk overdrivelse ” hvis du vil. Det er bare en komprimeringsfunktion med ikke-intuitiv matematik (til ikke-matematikere) bagved, men i sidste ende gør den intet andet end en simpel multiplikation og smider halvdelen af inputbitene svarende til ” overløb “. Hvilket er netop hvad, med mere verdslig matematik, kan gøres i to linjer C-kode pr. Blok inden for et dusin cyklusser (eller hvis du er OK med at bruge 32-bit multiplikationer i stedet for 64, kan det gøres parallelt, f.eks. Med AVX2 ” s vpmulld til to komplette blokke i ~ 4 cyklusser).
De, der stadig husker IDEA, husker at de brugte additionsmodus 2 16 og multiplikationsmodus 2 16 + 1 som S-bokse, der havde den gode egenskab at være reversible (ganske nødvendigt hvis du ønsker at dekryptere). Dette kunne desværre ikke udvides til 32 bit, fordi 2 32 +1 ikke er “ta primtal, så ikke alle input er garanteret at være relativt primære for det, og dermed har du problemer med at vende operationen. Men … det er meget fint i vores tilfælde, vi vil ikke vores kompressionsfunktion skal være inverterbar! Så virkelig, ” enkel “, skulle almindelig multiplikation bare gøre tricket også?
Så den enkle, ikke-specielle, ikke-magiske kompression funktion tilfældigvis er initialiseret med nøglen og IV, hvilket i øvrigt gør den endelige outputnøgleafhængig på en eller anden måde, så at almindelig funktion effektivt bliver en MAC. Hvis du har ” ekstra data “, skal du bare føre dem ind i hashen, inden du krypterer dine data, færdige. Igen er det ikke noget super specielt.
Alt i alt er det intet, du ikke kunne opnå med stort set hver anden hash-funktion også.
Nu antager Galois / tæller, at der bruges tællertilstand. Tællertilstand (og dets derivater) såvel som GHASH har den fordel, at du kan kryptere / dekryptere blokke parallelt. GHASH er også trivielt paralleliserbar.
Ja, ydeevne ! Men lad os være ærlige, er dette virkelig en fordel, eller rettere en enorm ulempe ?
Betyder det noget, hvor lang tid det tager at dekryptere en gigabyte- eller terabyte-størrelse besked, og hvor godt du kan parallelisere det arbejde? Eller applikationer, hvor du absolut vil være i stand til at ” søge ” til tilfældige positioner? Der er applikationer, hvor det måske betyder noget. Fuld disk kryptering kommer til at tænke på. Men du vil ikke bruge GCM i så fald, da du vil have inputstørrelse og outputstørrelse til at være identisk.
For en optaget server (eller VPN) betyder det noget, eller så ser det ud til , men disse kan alligevel behandle hvad som helst parallelt, da de har mange samtidige forbindelser.Så uanset om du kan parallelisere en stream, gør det generelt ingen forskel. Hvad med applikationer, hvor der kun er få forbindelser? Nå, du sender normalt ikke terabyte data over en loginterminal, og hvis du gør det, er din internetforbindelse sandsynligvis stadig den begrænsende faktor alligevel, da single-core-ydelse nemt overgår GbE-båndbredde selv på 7-8 år gamle desktop-processorer .
Okay, du bliver muligvis nødt til at vente 2-3 sekunder længere, når du udpakker en krypteret 2TB 7z-fil på din harddisk (hvis oprettelse af tusindvis af biblioteksposter ikke virkelig er flaskehalsen, som jeg er tilbøjelig til tror vil være tilfældet). Hvor ofte har du gjort det i løbet af det sidste år? Mig: nul gange.
De eneste, som det virkelig gør en forskel for, er ” skurkene “, dvs. præcis dem, som du ikke vil have et let liv. Sikker nok, hvis du trivielt kan parallelisere, bliver angreb meget lettere. Kast et rum fyldt med dedikeret hardware (GPUer, FPGAer, hvad som helst) på problemet, og lad det male væk. Ingen kommunikation mellem noder nødvendig? Nå, perfekt, det kan ikke blive bedre.
Er dette virkelig en fordel? Jeg ved det ikke, for mig ser det ud som en enorm ulempe. Hvis der er noget, vil jeg gøre parallelisering så hård som muligt, ikke så let som muligt.
Så … nok grubling og til spørgsmålet:
Hvad er grundlæggende ting, som jeg mangler ved GCM, der gør det så fantastisk, at du absolut skal bruge det?
Kommentarer
- Men bare hvem er ” skurkene ” er umulig at definere. Og det har Kæmpe indflydelse på regeringens anbefalinger og svarene i dette forum.
Svar
TL; DR: GCM giver fremragende ydeevne med de bedste sikkerhedsegenskaber, vi forventer af cifre i dag (AEAD).
GCM bruger CTR til at oprette en streamcipher. Dette er en velstuderet metode, som kun har en ulempe: det har absolut brug for en vis godkendelse for at forhindre bitflip. Før GCM var CTR-derefter-MAC løsningen. En væsentlig fordel ved streamkodere er fraværet af polstringsangreb (fordi der ikke er behov for polstring). En anden fordel er, at AES-CTR kan drage fordel af AES-NI-instruktionerne.
GCM er CTR-derefter-MAC med bedre ydeevne . En vigtig forbedring i forhold til CRT-derefter-MAC er evnen til at overlappe udførelsen af kryptering og godkendelse. Desuden har det vist sig at være sikkert i den konkrete sikkerhedsmodel, og det er ikke behæftet med patenter, så det er ikke en god idé at bruge den.
Det har nogle ulemper: det er ikke effektivt i indlejret hardware. og det er svært at implementere effektivt. Det sidste punkt imødegås ved hjælp af biblioteker skrevet af andre. Det er dog grundene til, at xchacha20-poly1305 blev populær over GCM.
Kommentarer
- Jeg vil argumentere for en anden grund til, at ChaCha20 er blevet populær, er fordi det er ikke AES. Don ‘ t misforstå mig, AES er en god algoritme, men at lægge bogstaveligt talt alle vores æg i en kurv er måske ikke den smarteste af alle ideer. Og at have en anden velafprøvet algoritme bortset fra AES er ret værdifuldt
- @ MechMK1 Jeg er enig med dig , men jeg skrev ikke, at de er alle årsagerne til ChaCha20 ‘ s popularitet, fordi den ‘ s ikke det stillede spørgsmål her. Mit pointe var t hat GCM betragtes ikke som ” fantastisk ” som OP mener.
- Helt sandt. Det ‘ er ikke en gylden gås, men ingen blev nogensinde fyret for at bruge AES-GCM, så at sige.
- Og det ‘ er ikke behæftet med patenter.
- @StephenTouset Tak, jeg redigerede mit indlæg for at inkludere din kommentar.
Svar
Først og fremmest er GCM en form for modtilstand. Hvilket betyder, at i modsætning til f.eks. cipher block chaining, afhænger output af en blok af nøjagtigt en blok af input. Værre endnu: Du kan ændre en enkelt bit, og det dekrypterede resultat vil variere i nøjagtigt den bit. For hvis du er ærlig, er en blokciffer i modtilstand slet ikke en “blockcipher”, men en (indtastet) PRNG efterfulgt af en XOR-operation. Dybest set en “blokeret” streamcipher. Det kræver ikke meget at forestille sig et scenarie, hvor nogen kan misbruge dette for at ændre beskeder på en skadelig måde (f.eks. Ændre “transaktion: +5.000 \ $” til “transaktion: -5.000 \ $”).
Meddelelsesgodkendelse, som GCM lag oven på CTR, gør dets smidighed ubetydelig.
Blokcifre har normalt den medfødte egenskab at blive til komplet gibberish, når du vender en enkelt bit (plus, med kæde, hele resten af meddelelsen) . Det er faktisk en ret flot, ønskelig egenskab, som vi bare kastede overbord uden god grund.
Dette er meget, meget forkert. Først og fremmest , CBC-tilstand lider også af en form for svaghed i formbarhed; hvis du vender en bit af ciphertext, krypterer du kun en blok og vend den tilsvarende bit af netblokken. Og der er andre smidighedsangreb mod CBC; se for eksempel EFail-angrebet .
Mere generelt er din uformelle idé om beskeder, der “bliver til fuldstændig gibberish”, ikke god nok. Vi har absolut brug for computere til mekanisk at opdage med et bestemt “ja / nej” -svar, når en krypteret besked er blevet smedet. At stole på, at et menneske vil være i sløjfen tidligt nok til at få øje på “gibberish” er ikke nok.
GHASH er en MAC, der understøtter ekstra godkendte data. Efter hvad jeg kan fortælle, er det en direkte løgn. Eller kald det “optimistisk overdrivelse”, hvis du vil. Det er bare en komprimeringsfunktion med ikke-intuitiv matematik (til ikke-matematikere) bagved, men i sidste ende gør den intet andet end en simpel multiplikation og smider halvdelen af inputbitene svarende til “overflow”.
MAC fungerer ikke, fordi brugerne ikke forstår matematikken. Det er som at sige, at folk ikke kan se satellit-tv, fordi de ikke “kender ikke beregning. Endelige felt MACer er en standardkonstruktion, der er kendt i årtier nu.
Hvilket er netop hvad med mere verdslig matematik kan gøres i to linjer med C kode pr. blok inden for et dusin cyklusser (eller hvis du er i orden med at bruge 32-bit multiplikationer i stedet for 64, kan det gøres parallelt, f.eks. med AVX2 “s vpmulld i to komplette blokke i ~ 4 cyklusser).
Der er faktisk debat om MACer baseret på Galois-felter som GHASH eller MACer baseret på primære felter som Poly1305, er et mere praktisk valg. Meget af det afhænger af kompromiserne mellem design af MACer for at understrege software versus hardwareimplementeringer; fx er Galois-feltmultiplikationer mareridt i software, men meget enklere end aritmetiske multiplikationer i hardware. En god del af kompromiserne hænger også på sårbarhed over for sidekanalangreb, f.eks. .
Men der er ingen debat om, hvorvidt Galois-felter eller primære felter fundamentalt er usikre nd. Matematikken tjekker begge ud.
Yay, performance! Men lad os være ærlige, er dette virkelig en fordel, eller rettere en enorm ulempe?
Fortæl det til de endeløse parader af ingeniører gennem årtierne, som har modstået at tilføje kryptering til produkter på grund af ydeevne. Og tænk ikke bare på kraftige pcer; tænk på indlejrede enheder, og vær meget bange for tingenes internet.
Jeg mener, dette er slet ikke et dødt spørgsmål. I løbet af de sidste par år var der en kraftig debat og udviklingen af en ny kryptografisk konstruktion til understøttelse af fuld disk-kryptering på low-end Android-enheder, der blev bedømt ikke stærk nok til de AES-baserede algoritmer, som Android tilbød før.
De eneste, som [performance] virkelig gør en forskel for, er de “bad guys”, dvs. præcis dem, som du ikke ønsker at have en let liv. Sikkert nok, hvis du trivielt kan parallelisere, bliver angreb meget lettere. Kast et rum fyldt med dedikeret hardware (GPUer, FPGAer, hvad som helst) på problemet og lad det male væk.
Kodere løser dette ved at bruge tilstrækkeligt store nøglestørrelser, ikke ved at få koderne til at bremse. Den bekymring, du opvejer, opstår i adgangskodebaseret kryptografi, hvor du ikke “t har tilstrækkeligt entropiske hemmelige nøgler. 256 bit symmetriske nøgler vil for evigt være mere end store nok til at besejre ethvert brutalt kraftangreb i vores univers.
Hvad er den grundlæggende ting, som jeg mangler ved GCM, der gør det så fantastisk, at du absolut skal bruge det?
Du behøver ikke absolut bruge GCM Det er på samme tid:
- Grundlæggende y lyd og meget bredt understøttet i hardware;
- Besværet med en række ulemper, som du ikke bragte op, som dårlig softwareydelse og katastrofal ægthedsfejl ved ikke-genbrug, der ofte diskvalificerer det i nogle praktiske sammenhænge .
Hvis du har hardware, der har indbygget AES-GCM-support og godt revideret software, der udnytter den, ville det være uklogt ikke at have det blandt dine topkandidater.