Forskel mellem stream cipher og block cipher

A blokciffer er en deterministisk og beregningsbar funktion af $ k $ -bit nøgler og $ n $ -bit (almindelig tekst) blokerer til $ n $ -bit (ciphertext) blokke. (Mere generelt skal blokkene ikke have bitstørrelse, $ n $ -karakterblokke passer også her). Dette betyder, når du krypterer den samme almindelige tekstblok med den samme nøgle, får du det samme resultat. (Vi vil normalt også have, at funktionen er inverterbar, dvs. at givet nøglen og ciphertext-blokken kan vi beregne almindelig tekst.)

For faktisk at kryptere eller dekryptere en besked (af enhver størrelse) donerer du ikke ” Brug ikke blokcifringen direkte, men sæt den i en driftsmåde . Den enkleste sådan tilstand ville være elektronisk kodebogstilstand (ECB) , som simpelthen klipper beskeden i blokke, anvender kryptering til hver blok og udsender de resulterende blokke. (Dette er dog generelt ikke en sikker tilstand.)

Nogle tidlige krypteringsordninger som den, der blev brugt af Caesar, kunne kategoriseres som en “blokciffer med 1-tegns blokke i ECB -mode “. Eller generelt alt, der har en kodebog .

Vi bruger normalt andre driftsformer, som inkluderer en initialiseringsvektor og en eller anden form for feedback, så hver blok af hver besked krypteres på en anden måde.

En streamcipher er en funktion, som direkte kortlægger $ k $ -bit nøgler og almindelig tekst til vilkårlig længde til (samme vilkårlige længde) ciffertekst, i en sådan på den måde, at præfikser af almindelig tekst kortlægges til præfikser for krypteringstekst, dvs. vi kan beregne startdelen af krypteringsteksten, før den bageste del af almindelig tekst er kendt. (Ofte er beskedstørrelserne muligvis også begrænset til multipla af nogle “blokstørrelser”, men normalt med mindre blokke som hele byte eller sådan.)

Hvis en del af almindelig tekst gentages, svarer den tilsvarende krypteringstekst normalt er ikke det samme – forskellige dele af meddelelsen krypteres på forskellige måder.

Ofte fungerer sådanne streamkodere ved at producere en keystream fra den aktuelle nøgle (og måske en initialiseringsvektor ) og derefter XOR-inges det med beskeden – disse kaldes synkron strømkryptering . Andre streamkodere kan variere krypteringen af fremtidige dele af meddelelsen afhængigt af tidligere dele.

Nogle blokcipher-driftsformer opretter faktisk en synkron streamcipher, som CTR og OFB -tilstand.

Du bør aldrig genbruge en nøgle (og IV, hvis relevant) til en synkron streamkryptering (som inkluderer blokcifre i streamingtilstande) til forskellige meddelelser, da dette kan føre til kompromiser. (Og selv for den samme besked vil det vise, at du gentog en besked.)

Bemærk, at du i den faktiske brug også vil have en MAC, f.eks. integritetsbeskyttelse til din besked. (Nogle ordninger er for eksempel brudt i tilfælde af et valgt ciphertext-angreb, og sådan en MAC forhindrer dette (hvis du kun sender meddelelsen til dekrypteringsprogrammet efter kontrol af MAC).)

Kommentarer

• Hvornår vil du vælge mellem en stream vs. en blok? Er der forskel i sikkerhed? Eller krypteringshastighed?
• @anoopelias Blokcifre er generelt langsomme sammenlignet med Stream-cifre. Jeg er heller ikke sikker, men jeg synes, at streamkodere er gode til at yde informationssikkerhed, mens blokcifre er gode til at levere computersikkerhed
• Med hensyn til sidste afsnit – bedes du give et link til et eksempel, hvor tilføjelse af en MAC beskytter mod et valgt ciphertext-angreb?

Matematisk er en blokciffer bare en indtastet pseudorandom permutation familie på sættet $ \ {0,1 \} ^ n $ på $ n $ -bit blokke. (I praksis kræver vi normalt også en effektiv måde at beregne den omvendte permutation på.) En blokciffer alene er ikke særlig nyttig til praktisk kryptografi, i det mindste medmindre du bare tilfældigvis har brug for at kryptere små meddelelser, der hver især passer ind i en enkelt blok.

Det viser sig imidlertid, at blokcifre er ekstremt alsidige byggesten til konstruktion af andre kryptografiske værktøjer: når du først har en god blokciffer, du kan nemt opbygge alt fra streamkodere til hashfunktioner, meddelelsesgodkendelseskoder, nøgledivationsfunktioner, pseudorandom nummergeneratorer, entropipuljer osv. baseret på kun en blokciffer.

Ikke alle disse applikationer nødvendigvis em> har brug for en blokciffer; for eksempel kunne mange af dem være baseret på en hvilken som helst pseudorandom-funktion , der ikke behøver at være en permutation (men bekvemt der er sa lemma , der siger, at en pseudorandom permutation ikke desto mindre vil fungere). Mange af konstruktionerne er også indirekte; for eksempel kan du konstruere en nøgledivationsfunktion ud fra en meddelelsesgodkendelseskode, som du kan konstruer ud fra en hash-funktion, som du kan — men ikke “t har til — konstruere fra en blok kryptering. Men alligevel, hvis du har en blokciffer, kan du bygge resten ud af den.

Desuden leveres disse konstruktioner typisk med (betingede) sikkerhedsbeviser, der reducerer sikkerheden af de konstruerede funktioner til den underliggende blokchiffer. Således behøver du ikke udføre den besværlige og upålidelige opgave med at kryptanalisere hver af disse funktioner separat — i stedet, du er fri til at koncentrere al din indsats på blokciffreringen, at vide, at enhver tillid, du vil have til sikkerheden ved blokciffrering, direkte oversættes til tillid til alle de funktioner, der er baseret på den.

Dette er åbenlyst meget praktisk, hvis du f.eks. arbejder på en lille indlejret platform, hvor inkludering af effektiv og sikker kode til mange separate krypto-primitiver kan være vanskelig og dyr. Men selvom du ikke er på en sådan begrænset platform, kan det være besværligt at skrive og analysere kryptokode på lavt niveau på grund af behovet for at være opmærksom på ting som sidekanalangreb . Det er nemmere at begrænse dig til et begrænset antal byggepladser på lavt niveau og at bygge alt hvad du har brug for ud af dem.

Også selv på hurtige platforme med masser af hukommelse, ligesom desktop-CPUer kan implementering af kryptooperationer på lavt niveau direkte i hardware være meget hurtigere end at gøre dem i software — men det er ikke praktisk at gøre det for mere end et par af dem På grund af deres alsidighed er blokcifre fremragende kandidater til hardwareimplementering (som i AES instruktions sæt til moderne x86 CPUer).

Hvad så med streamciphers?

Matematisk set er en streamcipher — i den mest generelle betydning af udtrykket — er også en tastet, inverterbar pseudorandomfunktionsfamilie, men på sættet $ \ {0,1 \} ^ * $ af bitstrings med vilkårlig længde snarere end på blokke med begrænset længde.

(Der er nogle finesser her; for eksempel kræver de fleste streamkrypteringskonstruktioner, at inputet inkluderer en unik nonce -værdi og ikke garanterer sikkerhed — i betydningen uadskillelighed fra en virkelig tilfældig funktion — hvis den samme nonce bruges til to forskellige indgange. Også som der er ingen ensartet fordeling på inverterbare funktioner fra $ \ {0,1 \} ^ * $ til sig selv at vælge tilfældige funktioner fra, vi er nødt til nøje at definere, hvad det betyder for en streamcipher at se “skelnes fra tilfældig”, og denne definition har praktiske sikkerhedsimplikationer — for eksempel lækker de fleste streamkodere længden af meddelelsen. Praktisk set kræver vi normalt også, at streamkoderne, i være “streaming”, i den forstand at vilkårligt lange input bitstrømme kan krypteres — og dekrypteres — ved hjælp af o kun konstant opbevaring og tid lineær i meddelelseslængden.)

Strømkodere er selvfølgelig meget mere straks nyttige end blokkoder: Du kan bruge dem direkte til at kryptere meddelelser af enhver længde. Det viser sig imidlertid, at de “også er meget mindre nyttige som byggesten til andre kryptografiske værktøjer: Hvis du har en blokciffer, kan du nemt gør det til en streamciffer , mens det at gøre en arbitrær streamcipher til en blockcipher er vanskeligt, hvis ikke umuligt .

Så hvorfor gider folk overhovedet at designe dedikerede strømkodere, så hvis blokkodere kan gøre jobbet lige så godt? Årsagen er hovedsagelig hastighed: nogle gange har du brug for en hurtig kryptering for at kryptere masser af data, og der er nogle virkelig hurtige dedikerede stream cipher designs derude. Nogle af disse designs er også designet til at være meget kompakte at implementere, enten i software eller hardware eller begge dele, så hvis du virkelig kun har brug for en stream cipher, kan du spar på kode / kredsløbsstørrelse ved at bruge en af disse chifre i stedet for en generel blokcifferbaseret.

Men hvad du vinder i hastighed og kompaktitet, mister du i alsidighed. eksempel, der synes ikke at være nogen enkel måde at oprette en hash-funktion ud af en streamkryptering , så hvis du har brug for en af dem (og du ofte gør, fordi hash-funktioner, udover at være nyttige alene, også er almindelige byggesten til andre kryptoværktøjer), bliver du nødt til at implementere dem separat. Og gæt hvad, de fleste hashfunktioner er baseret på blokcifre, så hvis du har en, kan du lige så godt genbruge den samme blokcipher til kryptering (medmindre du virkelig har brug for den rå hastighed for den dedikerede streamcipher).

Kommentarer

• Jeg stillede spørgsmålstegn ved, om det er nødvendigt at have to forskellige udtryk. Ifølge hvad du forklarede, er en streamcipher simpelthen et specielt tilfælde af en blockcipher, dvs. en for det begrænsende tilfælde, hvor n i sættet {0,1} ^ n er 1. Så jeg vil argumentere for ikke at opretholde den nuværende skelnen mellem terminologier.
• @ Mok-KongShen Faktisk er en streamcipher ikke blot en blockcipher med blokstørrelse 1 (bortset fra klassiske mono-alfabetiske chifre, som kan antages at være begge). En streamcipher oversætter normalt bit / bytes / … af strømmen forskelligt afhængigt af den nuværende interne tilstand for chifferet, mens en blokchiffer for samme input har samme output (og bruges derfor normalt i en ” driftstilstand ” for at oprette en streamcipher).
• @PauloEbermann. IMHO du svarede for mig et spørgsmål om CodesinChaos vedrørende ” dynamik og variabilitet “.
• @ Mok-KongShen Nej han ‘ t. Den eneste fordel, som en dedikeret streamciffer har over en blokcipher i en passende tilstand, er ydeevne. Du kan ‘ ikke se bort fra sammenkædningstilstande, da ingen tilregnelig bruger blokcifre uden passende sammenkædning.
• @CodesInChaos. Forskellige applikationer har forskellige ydelseskrav. At kryptere f.eks. en e-mail, behøver man ikke ‘ den ydeevne, der ville være ønskelig til kryptering af f.eks. en videofil.

En blokciffer af sig selv kortlægger n bits til n bits ved hjælp af en nøgle. dvs. det er en tastet pseudo-tilfældig permutation. Den kan ikke acceptere længere eller kortere tekster.

For faktisk at kryptere en meddelelse skal du altid have en sammenkædningstilstand. ECB er en sådan sammenkædningstilstand (og en rigtig dårlig), og det er ikke den rene blokciffer. Selv ECB består af “processer til tilføjelsesbehandling”. Disse sammenkædningstilstande kan have ganske forskellige egenskaber.

En af de mest populære sammenkædningstilstande, Tællertilstand (CTR) konstruerer en synkron strømkryptering fra en blokciffer.En anden tilstand, CFB konstruerer en selvsynkroniserende stream-chiffer med egenskaber et sted mellem CBCs og en synkron stream-chiffer.

Så din antagelse om, at der ikke er chiffer mellem stream og blockciphers, er ikke rigtig sand. Cryptographers foretrækker bare at bygge dem fra den velforståede blokciffer-primitive, i stedet for at skabe et helt nyt system.

Jeg kalder Vigenère en streamcipher, omend en med en alt for kort periode. Den bruger en 26-symbolskodning i stedet for en 2-symbolskodning, men det betyder ikke, at det ikke er en stream-chiffer. Se på Solitaire / Pontifex for en moderne konstruktion af en streamcipher med 26 symboler.

Kommentarer

• Hvis jeg ikke ‘ t err, ” kæde ” i blokkryptering bruges normalt i sammenhæng med ” block chaining “, dvs. at gøre de successive blokke afhængige af hinanden for at gøre analyse sværere. IMHO ECB ville således pr. Definition ikke have nogen sammenkædningseffekt som sådan.
• Du tager fejl. En god kædetilstand har disse egenskaber, men der findes stadig dårlige tilstande!

Der er to grundlæggende typer af kryptering

1. Symmetrisk. Det bruger samme nøgle til kryptering og dekryptering.
2. Asymmetrisk. Det bruger to forskellige nøgler (offentlige og private) til at kryptere og dekryptere.

Bloker kryptering og streamkryptering er en del af symmetrisk kryptering. Stream Cipher genererer en udvidet keystream fra bruger givet nøgle og XoR den derefter med almindelig tekst (til kryptering) / ciphertext (til dekryptering).

Mens Block Cipher tager en blok af data som input, kør flere runder på den sammen med nøgleblanding og producere krypteringstekst. Block Ciphers har forskellige driftsformer, hvoraf Counter (CTR) mode fungerer svarende til stream cipher. Et sekventielt tal indlæses til blokcifringen, og dets output er Xored med Plaintext for at gøre Ciphertext. I denne driftsmåde kræves kun krypteringskode for blokcipher. Der er ikke behov for dekrypteringskode, for dekryptering indtaster vi simpelthen det samme løbenummer for at blokere kryptering og Xored dets output med krypteringstekst for at få almindelig tekst. Engang bruges en nounce sammen med tælleren, så input blokchifferen er delt i to, dvs. en fast nounce og inkremental tæller.

Anden driftsform er: –

1. ECB (leverer fortrolighed)
2. CBC og CTR (giver fortrolighed og er delvis sikker mod udvalgt almindeligt tekstangreb)
3. EAX, CCM og GCM (giver godkendt kryptering)

Flere detaljer kan findes HER