GCM (Galois / Counter Mode), spesielt i kombinasjon med AES, har vært en de facto gullstandard i mange år. Krypter og autentiser i ett trinn, det er bare for kjempebra, og begreper som AEAD fungerer bra for å imponere en jente, så det ville være vinn-vinn. Men, vits til side …
Jeg har alltid lurt på hva som gjør det så spesielt, og jo lenger jeg tenker på det, jo mindre forstår jeg. Hvis du ser på det, så er den overordnede magien ikke så fantastisk i det hele tatt. Eller kanskje, kanskje jeg bare er for dum til å grok den (derav spørsmålet mitt).
Mine tanker:
For det første er GCM en form for motmodus . Noe som betyr at i motsetning til f.eks. cipher block chaining, avhenger utgangen fra en blokk nøyaktig en blokk av input. Verre, ennå: Du kan endre en enkelt bit, og det dekrypterte resultatet vil variere i akkurat den biten. For hvis du er ærlig, er en blokkryptering i motmodus ikke en » blokkryptering » i det hele tatt, men en (tastet) PRNG etterfulgt av en XOR-operasjon. I utgangspunktet er en » blokkerende » strømkryptering. Det tar ikke mye å forestille seg et scenario der noen kan misbruke dette for å endre meldinger på en skadelig måte (f.eks. Endre » transaksjon: +5 000 \ $ » til » transaksjon: -5,000 \ $ «). Blokkiffer har normalt den medfødte egenskapen til å bli fullstendig gibberish når du snur en enkelt bit (pluss, med lenking, hele resten av meldingen). Det er faktisk en ganske fin, ønskelig egenskap, som vi bare kastet over bord uten god grunn.
Jada, med autentiseringsapparatet , er angrepet ovenfor vanskelig å oppnå siden manipuleringen vil bli oppdaget. Men i utgangspunktet løser autentisatoren bare problemet med at valg av driftsmåte introdusert .
GHASH er en MAC som støtter ekstra autentiserte data. Etter det jeg kan fortelle, er det «en direkte løgn. Eller kall det » optimistisk overdrivelse » hvis du vil. Det er bare en kompresjonsfunksjon med ikke-intuitiv matematikk (til ikke-matematikere) bak, men til slutt gjør den ingenting annet enn en enkel multiplikasjon og kaste halvparten av inngangsbitene med ekvivalenten » overløp «. Som er akkurat det, med mer verdslig matematikk, kan gjøres i to linjer med C-kode per blokk innen et dusin sykluser (eller hvis du er OK med å bruke 32-bits multiplikasjoner i stedet for 64, kan gjøres parallelt, for eksempel med AVX2 » s vpmulld for to komplette blokker i ~ 4 sykluser.
De som fremdeles husker IDEA vil huske at de brukte tilleggsmodus 2 16 og multiplikasjonsmodus 2 16 + 1 som S-bokser som hadde den fine egenskapen å være reversible (ganske nødvendig hvis du ønsker å dekryptere). Dessverre kunne dette ikke utvides til 32-bits fordi 2 32 +1 ikke er «ta primtall, så ikke alle innganger er garantert relativt primære, og dermed har du problemer med å invertere operasjonen. Men … det er veldig bra i vårt tilfelle, vi vil ikke ha komprimeringsfunksjonen vår er inverterbar! Så egentlig, » enkel «, bør vanlig multiplikasjon bare gjøre susen også?
Så, den enkle, ikke-spesielle, ikke-magiske komprimeringen funksjon tilfeldigvis er initialisert med nøkkelen og IV, som forøvrig gjør den endelige utgangsnøkkelavhengige på en eller annen måte, så at ordinær funksjon blir effektivt en MAC. Hvis du har » ekstra data «, mater du dem bare inn i hasjen før du krypterer dataene dine, ferdig. Igjen, det er ikke noe veldig spesielt.
Samlet sett er det ingenting du ikke kunne oppnå med ganske mye annenhver hashfunksjon også.
Nå antar Galois / teller at tellermodus brukes. Tellermodus (og dets derivater) så vel som GHASH har fordelen at du kan kryptere / dekryptere blokker parallelt. Dessuten er GHASH trivielt parallelliserbar.
Ja, ytelse ! Men la oss være ærlige, er dette virkelig en fordel, eller rettere en stor ulempe ?
Betyder det hvor lang tid det tar å dekryptere en gigabyte- eller terabyte-størrelse melding, og hvor godt du kan parallellisere det arbeidet? Eller applikasjoner der du absolutt vil kunne » søke » til tilfeldige posisjoner? Det er applikasjoner der det kan ha betydning, sikkert. Full kryptering av disken kommer til å tenke på deg. Men du vil ikke bruke GCM i så fall siden du vil at inngangsstørrelse og utgangsstørrelse skal være identiske.
For en opptatt server (eller VPN) vil det ha betydning, eller så , men disse kan uansett behandle hva som helst parallelt, siden de har mange samtidige forbindelser.Så om du ikke kan parallellisere en strøm, gjør det egentlig ingen forskjell generelt. Hva med applikasjoner der det bare er få forbindelser? Vel, du overfører normalt ikke terabyte data over en påloggingsterminal, og hvis du gjør det, er internettforbindelsen din fremdeles sannsynligvis den begrensende faktoren uansett, da ytelse med én kjerne lett overgår GbE-båndbredde selv på 7-8 år gamle prosessorer. .
Greit, det kan hende du må vente 2-3 sekunder lenger når du trekker ut en kryptert 2TB 7z-fil på harddisken din (hvis du oppretter tusenvis av katalogoppføringer ikke egentlig er flaskehalsen, som jeg har en tendens til å tror vil være tilfelle). Hvor ofte har du gjort det i løpet av det siste året? Meg: null ganger.
De eneste det virkelig gjør en forskjell for er » skurkene «, dvs. akkurat de du ikke vil ha et lett liv. Sikkert nok, hvis du kan trivielt parallellisere, blir angrep mye lettere. Kast et rom fullt av dedikert maskinvare (GPUer, FPGAer, hva som helst) på problemet og la det male seg bort. Ingen kommunikasjon mellom noder nødvendig? Vel, perfekt, det kan ikke bli bedre.
Er dette virkelig en fordel? Jeg vet ikke. For meg ser det ut som en stor ulempe. Hvis noe, vil jeg gjøre parallellisering så vanskelig som mulig, ikke så lett som mulig.
Så … nok grubling, og til spørsmålet:
Hva er grunnleggende ting som jeg savner med GCM som gjør det så fantastisk at du absolutt burde bruke det?
Kommentarer
- Men bare hvem er » skurkene » er umulig å definere. Og det har STOR innvirkning på myndighetsanbefalinger og svarene i dette forumet.
Svar
TL; DR: GCM gir utmerket ytelse med de beste sikkerhetsegenskapene vi forventer av kodere i dag (AEAD).
GCM bruker CTR for å bygge en stream-kryptering. Dette er en godt studert metode, som bare har en ulempe: den trenger absolutt noen autentisering for å forhindre bitvending. Før GCM var CTR-then-MAC løsningen. En hovedfordel med strømkoder er fraværet av polstringsangrep (fordi det ikke er behov for polstring). En annen fordel er at AES-CTR kan dra nytte av AES-NI-instruksjonene.
GCM er CTR-then-MAC med bedre ytelse . En viktig forbedring i forhold til CRT-then-MAC er muligheten til å overlappe utførelsen av kryptering og autentisering. Videre har det vist seg å være sikkert i den konkrete sikkerhetsmodellen, og det er ikke belastet med patenter, så det er ikke noe brainer å bruke den.
Den har noen ulemper: den er ikke effektiv i innebygd maskinvare. og det er vanskelig å implementere effektivt. Det siste punktet motvirkes ved å bruke biblioteker skrevet av andre. Dette er imidlertid grunnene til at xchacha20-poly1305 ble populær over GCM.
Kommentarer
- Jeg vil argumentere for en annen grunn til at ChaCha20 har fått popularitet, er fordi det er ikke AES. Ikke ‘ t misforstå meg, AES er en flott algoritme, men å sette bokstavelig talt alle eggene våre i en kurv er kanskje ikke den smarteste av alle ideer. Og å ha en annen velprøvd algoritme bortsett fra AES er ganske verdifull
- @ MechMK1 Jeg er enig med deg , men jeg skrev ikke at de er alle årsakene til ChaCha20 ‘ s popularitet, fordi den ‘ s ikke spørsmålet som ble stilt her. Poenget mitt var t hat GCM blir ikke ansett som » fantastisk » som OP mener.
- Helt sant. Det ‘ er ikke en gylden gås, men ingen fikk noen gang sparken for å bruke AES-GCM, for å si det sånn.
- Og det ‘ er ikke belastet med patenter.
- @StephenTouset Takk, jeg redigerte innlegget mitt for å inkludere kommentaren din.
Svar
Først og fremst er GCM en form for motmodus. Noe som betyr at i motsetning til f.eks. cipher block chaining, avhenger utgangen fra en blokk nøyaktig en blokk av input. Verre, ennå: Du kan endre en enkelt bit, og det dekrypterte resultatet vil variere i akkurat den biten. For hvis du er ærlig, er en blokkryptering i motmodus ikke en «blokkryptering» i det hele tatt, men en (tastet) PRNG etterfulgt av en XOR-operasjon. I utgangspunktet en «blocky» stream cipher. Det skal ikke mye til for å forestille seg et scenario der noen kan misbruke dette for å endre meldinger på en skadelig måte (f.eks. Endre «transaksjon: +5.000 \ $» til «transaksjon: -5.000 \ $»).
Meldingsautentisering som GCM lag på toppen av CTR gjør at smidigheten er uvesentlig.
Blokkiffer har normalt den medfødte egenskapen til å bli fullstendig gibberish når du snur en enkeltbit (pluss, med lenking, hele resten av meldingen) . Det er faktisk en ganske fin, ønskelig egenskap som vi bare kastet over bord uten god grunn.
Dette er veldig, veldig galt. Først av alt , CBC-modus lider også av en slags svakhet i smidbarhet; hvis du snur en bit av krypteringsteksten, krypterer du bare en blokk og vend den tilsvarende biten av nettblokken. Og det er andre smidighetsangrep mot CBC; se for eksempel EFail-angrepet .
Mer generelt er den uformelle ideen om meldinger som «blir til fullstendig gibberish» ikke god nok. Vi trenger absolutt datamaskiner for å oppdage mekanisk, med et bestemt «ja / nei» -svar, når en kryptert melding er blitt smidd. Å stole på at et menneske vil være i løkken tidlig nok til å oppdage «gibberish» er ikke nok.
GHASH er en MAC som støtter ekstra autentiserte data. Etter det jeg kan fortelle, er det en direkte løgn. Eller kall det «optimistisk overdrivelse» hvis du vil. Det er bare en komprimeringsfunksjon med ikke-intuitiv matematikk (til ikke-matematikere) bak, men til slutt gjør den ingenting annet enn en enkel multiplikasjon og kaster halvparten av inngangsbitene med ekvivalent med «overflow».
MAC fungerer ikke fordi brukerne ikke forstår matematikken. Det er som å si at folk ikke kan se satellitt-TV fordi de ikke «vet ikke kalkulator. Endelige felt-MAC er en standardkonstruksjon, kjent i flere tiår nå.
Hvilket er akkurat det, med mer verdslig matematikk, kan gjøres i to linjer med C kode per blokk innen et dusin sykluser (eller hvis du er OK med å bruke 32-bits multiplikasjoner i stedet for 64, kan gjøres parallelt, for eksempel med AVX2 «s vpmulld i to komplette blokker i ~ 4 sykluser).
Det er faktisk debatt om MAC-er basert på Galois-felt som GHASH, eller MAC-er basert på primærfelt som Poly1305, er et mer praktisk valg. Mye av det henger på kompromissene mellom å designe MAC-er for å understreke programvare kontra maskinvareimplementeringer; F.eks. er Galois-feltmultiplikasjoner marerittaktig i programvare, men mye enklere enn aritmetiske multiplikasjoner i maskinvare. En god del av kompromissene henger også på sårbarhet for sidekanalangrep, f.eks. .
Men det er ingen debatt om enten Galois-felt eller primærfelt er fundamentalt usikre nd. Matematikken sjekker ut på begge deler.
Yay, performance! Men la oss være ærlige, er dette virkelig en fordel, eller rettere en stor ulempe?
Fortell det til de endeløse parader av ingeniører gjennom flere tiår som har motstått å legge til kryptering til produkter på grunn av ytelse. Og ikke bare tenk på kraftige PC-er; tenk på innebygde enheter, og vær veldig redd for tingenes internett.
Jeg mener, dette er ikke et dødt problem i det hele tatt. I løpet av de siste par årene var det en kraftig debatt og utviklingen av en ny kryptografisk konstruksjon for å støtte full-disk-kryptering på low-end Android-enheter som ble bedømt ikke kraftig nok for de AES-baserte algoritmene som Android tilbød før.
De eneste som [performance] virkelig gjør en forskjell for, er «bad guys», dvs. akkurat de du ikke vil ha en Enkelt liv. Sikkert nok, hvis du kan trivielt parallellisere, blir angrep mye lettere. Kast et rom fullt av dedikert maskinvare (GPUer, FPGAer, hva som helst) på problemet og la det slipe bort.
Kodere løser dette ved å bruke tilstrekkelig store nøkkelstørrelser, ikke ved å gjøre kodene sakte. Bekymringen du tar opp, oppstår i passordbasert kryptografi der du ikke bruker «t har tilstrekkelig entropiske hemmelige nøkler. 256-biters symmetriske nøkler vil alltid være mer enn store nok til å beseire ethvert brute force-angrep i vårt univers.
Hva er den grunnleggende tingen jeg mangler ved GCM som gjør den så fantastisk at du absolutt burde bruke den?
Du trenger ikke absolutt å bruke GCM . Det er samtidig:
- Fundamentall y lyd og veldig bredt støttet i maskinvare;
- Bekymret av en rekke ulemper du ikke førte til, som dårlig programvareytelse og katastrofal autentisitetsfeil ved ikke-gjenbruk, som ofte diskvalifiserer det i noen praktiske sammenhenger .
Hvis du har maskinvare som har innfødt AES-GCM-støtte og godt revidert programvare som utnytter den, ville det være uklokt å ikke ha den blant dine beste kandidater.