Forskjell mellom stream cipher og block chipher

A blokkryptering er en deterministisk og beregningsbar funksjon av $ k $ -bit nøkler og $ n $ -bit (plaintext) blokkerer til $ n $ -bit (ciphertext) blokker. (Mer generelt trenger ikke blokkene å være litt store, $ n $ -karakterblokker passer også her). Dette betyr når du krypterer samme blokk med samme nøkkel, får du det samme resultatet. (Vi vil normalt også at funksjonen er inverterbar, dvs. at gitt nøkkelen og krypteringsteksten kan vi beregne ren tekst.)

For å faktisk kryptere eller dekryptere en melding (av hvilken som helst størrelse), trenger du ikke » t bruk blokkrypteringen direkte, men legg den i en driftsmodus . Den enkleste modusen vil være elektronisk kodebokmodus (ECB) , som ganske enkelt kutter meldingen i blokker, bruker krypteringen til hver blokk og sender ut de resulterende blokkene. (Dette er vanligvis ikke en sikker modus, skjønt.)

Noen tidlige krypteringsplaner som den som ble brukt av Caesar, kunne kategoriseres som en «blokkryptering med 1-tegns blokker i ECB -mode «. Eller generelt, alt som har en kodebok .

Vi bruker vanligvis andre driftsmåter, som inkluderer en initialiseringsvektor og en slags tilbakemelding, slik at hver blokk av hver melding er kryptert på en annen måte.

A stream cipher er en funksjon som direkte tilordner $ k $ -bitnøkler og vanlig tekst for vilkårlig lengde til (samme vilkårlig lengde) krypteringstekst, i en slik slik at prefikser av klartekstkart til prefikser av krypteringstekst, dvs. at vi kan beregne startdelen av krypteringstekst før den bakre delen av klartekst er kjent. (Ofte kan meldingsstørrelsene også være begrenset til multipler av noen «blokkstørrelser», men vanligvis med mindre blokker som hele byte eller lignende.) er ikke det samme – forskjellige deler av meldingen blir kryptert på forskjellige måter.

Ofte fungerer slike strømkoder ved å produsere en keystream fra den faktiske nøkkelen (og kanskje en initialiseringsvektor ) og bare XOR-ing det med meldingen – disse kalles synkron strømkryptering . Andre strømkoder kan variere krypteringen av fremtidige deler av meldingen, avhengig av tidligere deler.

Noen blokkeringskrypteringsmoduser oppretter faktisk en synkron strømkryptering, som CTR og OFB -modus.

Du bør aldri bruke en nøkkel (og IV, hvis aktuelt) til en synkron strømkryptering (som inkluderer blokkryptering i streamingmodus) for forskjellige meldinger, siden dette kan føre til kompromisser. (Og selv for den samme meldingen vil det vise at du gjentok en melding.)

Merk at i faktisk bruk vil du også ha en MAC, f.eks. integritetsbeskyttelse, for meldingen din. (Noen ordninger er ødelagt i tilfelle et valgt ciphertext-angrep, for eksempel, og en slik MAC vil forhindre dette (hvis du bare sender meldingen til dekryptereren etter å ha sjekket MAC).)

Kommentarer

• Når vil du velge mellom en stream vs. blokk? Er det en forskjell i sikkerhet? Eller krypteringshastighet?
• @anoopelias Blokkodringene er generelt treg sammenlignet med Stream-kryptering. Jeg er heller ikke sikker, men jeg tror strømkoder er gode til å gi informasjonssikkerhet mens blokkryptering er gode til å gi datamaskinsikkerhet.
• Når det gjelder siste avsnitt – kan du gi en lenke for et eksempel der å legge til en MAC beskytter mot et valgt ciphertext-angrep?

Matematisk sett er en blokkryptering bare en tastet pseudorandom permutasjon familie på settet $ \ {0,1 \} ^ n $ på $ n $ -bit blokker. (I praksis krever vi vanligvis også en effektiv måte å beregne den omvendte permutasjonen på.) En blokkryptering alene er ikke veldig nyttig for praktisk kryptografi, i det minste med mindre du bare trenger å kryptere små meldinger som hver passer inn i en enkelt blokk.

Det viser seg imidlertid at blokkryptering er ekstremt allsidige byggesteiner for å konstruere andre kryptografiske verktøy: når du har en god blokkryptering, du kan enkelt bygge alt fra strømkoder til hash-funksjoner, meldingsautentiseringskoder, nøkkelavledningsfunksjoner, pseudorandom nummergeneratorer, entropipasser osv. basert på bare en blokkryptering.

Ikke alle disse programmene nødvendigvis em> trenger en blokkryptering; for eksempel kan mange av dem være basert på hvilken som helst pseudorandom-funksjon som ikke trenger å være en permutasjon (men, praktisk, det er «sa lemma som sier at en pseudorandom-permutasjon likevel vil fungere). Mange av konstruksjonene er også indirekte; for eksempel kan du konstruere en nøkkelavledningsfunksjon fra en meldingautentiseringskode, som du kan konstruere fra en hash-funksjon, som du kan — men ikke «t har til — konstruere fra en blokk kryptering. Men fortsatt, hvis du har en blokkryptering, kan du bygge resten av den.

Videre kommer disse konstruksjonene vanligvis med (betingede) sikkerhetsbevis som reduserer sikkerheten av de konstruerte funksjonene i forhold til den underliggende blokkeringen. Dermed trenger du ikke å utføre den møysommelige og upålitelige oppgaven med å kryptanalisere hver av disse funksjonene separat — i stedet, du er fri til å konsentrere all din innsats på blokkrypteringen, å vite at all tillit du vil ha til sikkerheten til blokkrypteringen direkte oversettes til tillit til alle funksjonene basert på den.

Selvfølgelig er alt dette veldig praktisk hvis du for eksempel jobber med en liten innebygd plattform der det kan være vanskelig og dyrt å inkludere effektiv og sikker kode for mange separate crypto primitives. Men selv om du ikke er på en så begrenset plattform, kan det være vanskelig å skrive og analysere kryptokode på lavt nivå på grunn av behovet for å ta hensyn til ting som sidekanalangrep . Det er lettere å begrense deg til et begrenset antall byggesteiner på lavt nivå og å bygge alt du trenger av dem.

Også på raske plattformer med mye minne, som stasjonære CPUer, kan implementering av kryptoperasjoner på lavt nivå direkte i maskinvare være mye raskere enn å gjøre dem i programvare —, men det er ikke praktisk å gjøre det for mer enn noen få av dem På grunn av sin allsidighet er blokkodere utmerkede kandidater for maskinvareimplementering (som i AES-instruksjonssett for moderne x86-prosessorer).

Hva med strømkoder, da?

Matematisk sett er en strømkryptering — i den mest generelle forstand av begrepet — er også en tastet, inverterbar pseudorandom-funksjonsfamilie, men på settet $ \ {0,1 \} ^ * $ av bitstrenger med vilkårlig lengde i stedet for på blokker med begrenset lengde.

(Det er noen finesser her; for eksempel krever de fleste strømkrypteringskonstruksjoner at inngangen inneholder en unik nonce -verdi, og ikke garanterer sikkerhet — i betydningen uadskillbarhet fra en virkelig tilfeldig funksjon — hvis samme nonce brukes til to forskjellige innganger. Også som det er ingen jevn fordeling på inverterbare funksjoner fra $ \ {0,1 \} ^ * $ til seg selv å velge tilfeldige funksjoner fra, vi må definere nøye akkurat hva det betyr for en strømkryptering å se «ikke å skille fra tilfeldig», og denne definisjonen har praktiske sikkerhetsmessige implikasjoner — for eksempel, de fleste streamkodere lekker lengden på meldingen. Praktisk sett krever vi vanligvis også at streamkodere, i faktisk, vær «streaming», i den forstand at vilkårlig lange inngangsbitstrømmer kan krypteres — og dekrypteres — ved å bruke o bare konstant lagring og tid lineær i meldingslengden.)

Strømmekoder er selvfølgelig mye mer umiddelbart nyttige enn blokkeringskoder: du kan bruke dem direkte til å kryptere meldinger av hvilken som helst lengde. Det viser seg imidlertid at de «også er mye mindre nyttige som byggesteiner for andre kryptografiske verktøy: Hvis du har en blokkryptering, kan du enkelt gjøre den om til en strømkryptering , mens det å gjøre en vilkårlig strømkryptering til en blokkryptering er vanskelig om ikke umulig .

Så hvorfor bryr folk seg om å designe dedikerte strømkoder i det hele tatt, hvis blokkryptering kan gjøre jobben like bra? For det meste er årsaken hastighet: noen ganger trenger du en rask kryptering for å kryptere mye data, og det er noen virkelig raske dedikerte stream cipher-design der ute. Noen av disse designene er også designet for å være veldig kompakte å implementere, enten i programvare eller maskinvare eller begge deler, slik at hvis du virkelig bare trenger en stream-chiffer, kan du lagre på kode / kretsstørrelse ved å bruke en av disse kodene i stedet for en generell blokkrypteringsbasert.

Men hva du får i hastighet og kompaktitet, mister du allsidigheten. eksempel, det ser ikke ut til å være noen enkel måte å lage en hashfunksjon ut av en streamkryptering , så hvis du trenger en av disse (og du ofte gjør, fordi hashfunksjoner, foruten å være nyttige alene, også er vanlige byggesteiner for andre kryptoverktøy), må du implementere dem separat. Og gjett hva, de fleste hashfunksjoner er basert på blokkryptering, så hvis du har en, kan du like godt bruke den samme blokkrypteringen for kryptering også (med mindre du virkelig trenger råhastigheten til den dedikerte strømkrypteringen).

Kommentarer

• Jeg spurte om det er nødvendig å ha to forskjellige begreper. I følge det du forklarte, er en strømkryptering ganske enkelt et spesielt tilfelle av en blokkryptering, dvs. en for det begrensende tilfellet der n i settet {0,1} ^ n er 1. Så jeg vil argumentere for ikke å opprettholde strømmen skill mellom terminologier.
• @ Mok-KongShen Egentlig er en strømkryptering ikke bare en blokkryptering med blokkstørrelse 1 (annet enn klassiske mono-alfabetiske krypter, som kan antas å være begge). En strømkryptering oversetter vanligvis bitene / byte / … av strømmen forskjellig, avhengig av den nåværende interne tilstanden til krypteringen, mens en blokkryptering for samme inngang har samme utgang (og blir derfor vanligvis brukt i en » driftsmodus » for å opprette en strømkryptering).
• @PauloEbermann. IMHO du svarte for meg et spørsmål om CodesinChaos angående » dynamikk og variabilitet «.
• @ Mok-KongShen Nei han gjorde ikke ‘ t. Den eneste fordelen en dedikert strømkryptering har over en blokkryptering i en passende modus er ytelse. Du kan ‘ ikke se bort fra kjedemodus, siden ingen tilregnelig bruker blokkryptering uten passende kjetting.
• @CodesInChaos. Ulike applikasjoner har forskjellige ytelseskrav. Å kryptere f.eks. en e-post, trenger man ikke ‘ den ytelsen som er ønskelig for kryptering av for eksempel en videofil.

En blokkryptering av seg selv kartlegger n biter til n biter ved hjelp av en nøkkel. dvs. det er en tastet pseudo-tilfeldig permutasjon. Den kan ikke akseptere lengre eller kortere tekster.

For å faktisk kryptere en melding trenger du alltid en kjedemodus. ECB er en slik kjedemodus (og en veldig dårlig), og det er ikke den rene blokkrypteringen. Selv ECB består av «tilleggsprosesseringsoperasjoner». Disse kjedemodusene kan ha ganske forskjellige egenskaper.

En av de mest populære kjedemodusene, Counter-modus (CTR) konstruerer en synkron strømkryptering fra en blokkryptering.En annen modus, CFB konstruerer en selvsynkroniserende strømkryptering, med egenskaper et sted mellom de til CBC og en synkron strømkryptering.

Så antagelsen din om at det ikke er noen krypteringer mellom stream og blockciphers, er ikke sant. Kryptografer bare foretrekk å bygge dem fra den velforståtte blokk-krypteringen primitive, i stedet for å skape et helt nytt system.

Jeg vil kalle Vigenère en strømkryptering, om enn en med en altfor kort periode. Den bruker koding med 26 symboler i stedet for koding med 2 symboler, men det betyr ikke at det ikke er en strømkryptering. Se på Solitaire / Pontifex for en moderne konstruksjon av en strømkryptering med 26 symboler.

Kommentarer

• Hvis jeg ikke ‘ t err, » lenking » i blokkryptering brukes normalt i sammenheng med » block chaining «, dvs. å gjøre de suksessive blokkene avhengige av hverandre for å gjøre analyse vanskeligere. Så IMHO ECB ville per definisjon ikke ha noen kjedeeffekt som sådan.
• Du tar feil. En god kjedemodus vil ha disse egenskapene, men dårlige moduser eksisterer fremdeles!

Det er to grunnleggende typer kryptering

1. Symmetrisk. Den bruker samme nøkkel for kryptering og dekryptering.
2. Asymmetrisk. Den bruker to forskjellige nøkler (offentlig og privat) for å kryptere og dekryptere.

Block Cipher and Stream Cipher er en del av Symmetric Encryption. Stream Cipher genererer en utvidet nøkkelstrøm fra bruker gitt nøkkel og deretter XoR den med ren tekst (for kryptering) / ciphertext (for dekryptering).

Mens Block Cipher tar en blokk med data som input, kjør flere runder på den sammen med nøkkelblanding og produsere krypteringstekst. Block Ciphers har forskjellige driftsmåter der Counter (CTR) -modus fungerer som strømkryptering. Et sekvensielt nummer blir lagt inn i blokkrypteringen, og utgangen er Xored med vanlig tekst for å lage krypteringstekst. I denne driftsmåten er bare krypteringskode for blokkrypteringen nødvendig. Det er ikke behov for dekrypteringskode, for dekryptering skriver vi ganske enkelt inn det samme serienummeret for å blokkere kryptering, og Xored utgangen med krypteringstekst for å få vanlig tekst. En gang brukes et spekter sammen med telleren, så inngang blokkeringssifret er delt i to, dvs. et fast spekter og inkrementell teller.

Annen modus er: –

1. ECB (gir konfidensialitet)
2. CBC og CTR (gir konfidensialitet og er sementisk sikker mot valgt vanlig tekstangrep)
3. EAX, CCM og GCM (gir autentisert kryptering)

Flere detaljer finner du HER