Skillnad mellan strömkryptering och blockkryptering

A blockera chiffer är en deterministisk och beräkningsbar funktion av $ k $ -bit-tangenter och $ n $ -bit (plaintext) blockerar till $ n $ -bit (ciphertext) block. (Mer allmänt behöver blocken inte vara bitstorlek, $ n $ -karaktärblock skulle också passa här). Detta betyder när du krypterar samma klartextblock med samma nyckel, får du samma resultat. (Vi vill normalt också att funktionen är inverterbar, dvs att med tanke på nyckeln och ciphertext-blocket kan vi beräkna klartexten.)

För att faktiskt kryptera eller dekryptera ett meddelande (av vilken storlek som helst), gör du inte ” Använd inte blockkodningen direkt, men placera den i ett driftsätt . Det enklaste sättet är elektronisk kodboksläge (ECB) , som helt enkelt skär meddelandet i block, tillämpar chifferet på varje block och matar ut de resulterande blocken. (Detta är dock i allmänhet inte ett säkert läge.)

Vissa tidiga krypteringsscheman som den som används av Caesar kan kategoriseras som en ”blockcipher med 1-teckenblock i ECB -mode ”. Eller i allmänhet allt som har en kodbok .

Vi använder vanligtvis andra driftsätt, som inkluderar en initialiseringsvektor och någon form av feedback, så att varje block av varje meddelande krypteras på ett annat sätt.

En strömkryptering är en funktion som direkt mappar $ k $ -bit-tangenter och vanliga längdtexter till (samma godtyckliga längd) krypteringstext, i en sådan sätt som prefix av klartextkarta till prefix av chiffertext, dvs vi kan beräkna startdelen av chiffertexten innan den bakre delen av klartext är känd. (Ofta kan meddelandestorlekarna också vara begränsade till multiplar av någon ”blockstorlek”, men vanligtvis med mindre block som hela byte eller liknande.)

Om en del av klartext upprepas brukar motsvarande krypteringstext är inte detsamma – olika delar av meddelandet krypteras på olika sätt.

Ofta fungerar sådana strömkodningar genom att producera en nyckelström från den faktiska nyckeln (och kanske en initialiseringsvektor ) och sedan helt enkelt XOR-inga det med meddelandet – dessa kallas synkrona strömkodare . Andra strömkodningar kan variera krypteringen av framtida delar av meddelandet beroende på tidigare delar.

Vissa blockkrypteringslägen skapar faktiskt en synkron strömkryptering, som CTR och OFB -läge.

Du bör aldrig återanvända en nyckel (och IV, om tillämpligt) i en synkron strömkodning (som inkluderar blockkodare i strömningslägen) för olika meddelanden, eftersom detta kan leda till kompromisser. (Och även för samma meddelande kommer det att visa att du upprepade ett meddelande.)

Observera att vid faktisk användning vill du också ha en MAC, t.ex. integritetsskydd, för ditt meddelande. (Vissa scheman bryts till exempel vid en vald ciphertext-attack, och en sådan MAC förhindrar detta (om du bara skickar meddelandet till dekrypteraren efter att ha kontrollerat MAC).)

Kommentarer

• När skulle du välja mellan en ström jämfört med block? Är det skillnad i säkerhet? Eller krypteringshastighet?
• @anoopelias Blockkodningar är i allmänhet långsamma jämfört med Stream-krypteringar. Jag är inte säker, men jag tycker att strömkodare är bra på att tillhandahålla informationssäkerhet medan blockkodare är bra på att tillhandahålla datasäkerhet
• När det gäller sista stycket – vill du ge en länk för ett exempel där lägga till en MAC skyddar mot en valt ciphertext-attack?

Matematiskt är en blockkodning bara en nycklade pseudorandom permutation familj på uppsättningen $ \ {0,1 \} ^ n $ på $ n $ -bit block. (I praktiken kräver vi vanligtvis också ett effektivt sätt att beräkna den omvända permutationen.) En blockkodning på egen hand är inte särskilt användbar för praktisk kryptografi, åtminstone om du bara råkar behöva kryptera små meddelanden som var och en passar in i ett block.

Det visar sig dock att blockkodningar är extremt mångsidiga byggstenar för att konstruera andra kryptografiska verktyg: när du har en bra blockkryptering, du kan enkelt bygga allt från strömkoder till hashfunktioner, meddelandeautentiseringskoder, nyckelavledningsfunktioner, pseudorandomnummergeneratorer, entropipooler etc. baserat på bara en blockkodning.

Inte alla dessa applikationer nödvändigtvis behöver en blockkodning; till exempel kan många av dem baseras på vilken pseudorandom-funktion som inte behöver vara en permutation (men, bekvämt, där ”sa lemma som säger att en pseudorandom permutation ändå kommer att fungera). Många av konstruktionerna är också indirekta; till exempel kan du konstruera en nyckelavledningsfunktion från en meddelandeautentiseringskod, som du kan konstruera från en hash-funktion, som du kan — men inte ”t har till — konstruera från ett block chiffer. Men ändå, om du har en blockkodning kan du bygga resten av den.

Dessutom kommer dessa konstruktioner vanligtvis med (villkorade) säkerhetsbevis som minskar säkerheten av de konstruerade funktionerna till den underliggande blocksiffran. Således behöver du inte utföra den mödosamma och opålitliga uppgiften att kryptanalysera var och en av dessa funktioner separat — istället är du fri att koncentrera alla dina ansträngningar på blockkodningen, att veta att allt förtroende du har för blockciffreringens säkerhet direkt översätts till förtroende för alla funktioner baserat på den.

Allt detta är uppenbarligen väldigt bekvämt om du t.ex. en liten inbäddad plattform där det kan vara svårt och dyrt att inkludera effektiv och säker kod för massor av separata kryptoprimitiv. Men även om du inte är på en sådan begränsad plattform kan det vara svårt att skriva och analysera kryptokod på låg nivå på grund av behovet av att uppmärksamma saker som sidokanalattacker . Det är lättare att begränsa dig till ett begränsat antal byggstenar på låg nivå och att bygga allt du behöver av dem.

Även på snabba plattformar med mycket minne, som stationära CPU: er kan implementering av kryptoperationer på låg nivå direkt i hårdvara vara mycket snabbare än att göra dem i programvara — men det är inte praktiskt att göra det för mer än några få av dem På grund av sin mångsidighet är blockkodare utmärkta kandidater för hårdvaruimplementering (som i AES-instruktionsuppsättningen för moderna x86-processorer).

Hur är det då med strömkodare?

Matematiskt, en strömkryptering — i den mest allmänna betydelsen av termen — är också en nyckelbar inverterbar pseudorandom-funktionsfamilj, men på uppsättningen $ \ {0,1 \} ^ * $ av bitsträngar med godtycklig längd snarare än på block med begränsad längd.

(Det finns några finesser här; till exempel kräver de flesta strömkrypteringskonstruktioner att ingången innehåller ett unikt nonce -värde och inte garantera säkerhet — i betydelsen av oskiljbarhet från en verkligt slumpmässig funktion — om samma nonce används för två olika ingångar. Också, som det finns ingen enhetlig fördelning på inverterbara funktioner från $ \ {0,1 \} ^ * $ till sig själv att välja slumpmässiga funktioner från, vi måste definiera noggrant precis vad det betyder för en strömkodning att se ”oskiljbar från slumpmässig”, och denna definition har praktiska säkerhetsimplikationer — till exempel läcker de flesta strömkodare längden på meddelandet. I praktiken kräver vi vanligtvis också att strömkodningar, i vara ”streaming”, i den meningen att godtyckligt långa inmatade bitströmmar kan krypteras — och dekrypteras — med o bara konstant lagring och linjär tid i meddelandets längd.)

Strömkodare är naturligtvis mycket mer användbara än blockkodare: du kan använda dem direkt för att kryptera meddelanden av vilken längd som helst. Det visar sig dock att de ”också är mycket mindre användbara som byggstenar för andra kryptografiska verktyg: om du har en blockchiffer kan du enkelt förvandla den till en strömkodning , medan det är svårt om inte omöjligt att göra en godtycklig strömkodning till en blockkodning.

Så varför bryr sig människor om att utforma dedikerade strömkodare alls, om blockkodare kan göra jobbet lika bra? Orsaken är oftast hastighet: ibland behöver du en snabb kryptering för att kryptera massor av data, och det finns några verkligen snabba dedikerade strömkrypteringsdesigner där ute. Några av dessa mönster är också utformade för att vara mycket kompakta att implementera, antingen i mjukvara eller hårdvara eller båda, så att om du verkligen bara behöver en strömkryptering kan du spara på kod- / kretsstorlek genom att använda en av dessa chiffer istället för en allmän blockchifferbaserad.

Men vad du får i hastighet och kompaktitet tappar du i mångsidighet. exempel, det verkar inte finnas något enkelt sätt att göra en hashfunktion från en strömkodning , så om du behöver en av dem (och du ofta gör, eftersom hashfunktioner, förutom att de är användbara på egen hand, också är vanliga byggstenar för andra kryptoverktyg), måste du implementera dem separat. Och gissa vad, de flesta hashfunktioner är baserade på blockkodningar, så om du har en, kan du lika gärna återanvända samma blockkodning för kryptering också (om du inte verkligen behöver den råa hastigheten för den dedikerade strömkrypteringen).

Kommentarer

• Jag ifrågasatte om det är nödvändigt att ha två olika termer. Enligt vad du förklarade är en strömkodning helt enkelt ett speciellt fall av en blockkodning, dvs. en för det begränsande fallet där n i uppsättningen {0,1} ^ n är 1. Så jag skulle argumentera för att inte behålla strömmen åtskillnad mellan terminologier.
• @ Mok-KongShen I själva verket är en streamcipher inte bara en blockcipher med blockstorlek 1 (annat än klassiska mono-alfabetiska chifferer, vilket kan antas vara båda). En strömkryptering översätter vanligtvis bitarna / byten / … av strömmen på olika sätt, beroende på det aktuella interna tillståndet för krypteringen, medan en blockkodning för samma ingång har samma utgång (och används därför vanligtvis i en ” driftläge ” för att skapa en strömkodning).
• @PauloEbermann. IMHO du svarade åt mig en fråga om CodesinChaos beträffande ” dynamik och variabilitet ”.
• @ Mok-KongShen Nej han ’ t. Den enda fördelen som en dedikerad strömkodning har jämfört med en blockkodning i ett lämpligt läge är prestanda. Du kan ’ inte bortse från kedjelägen, eftersom ingen förnuftig använder blockkoder utan lämplig kedjning.
• @CodesInChaos. Olika applikationer har olika prestandakrav. För att kryptera t.ex. ett e-postmeddelande behöver man inte ’ den prestanda som skulle vara önskvärd för kryptering av till exempel en videofil.

En blockkodning i sig själv mappar n bitar till n bitar med en nyckel. det vill säga det är en pseudoslumpmässig permutation. Det kan inte acceptera längre eller kortare texter.

För att faktiskt kryptera ett meddelande behöver du alltid ett kedjeläge. ECB är ett sådant kedjeläge (och en riktigt dålig), och det är inte den rena blockkodningen. Även ECB består av ”tilläggsprocesser”. Dessa kedjelägen kan ha helt olika egenskaper.

Ett av de mest populära kedjelägena, Counter-läge (CTR) konstruerar en synkron strömkodning från en blockkodning.Ett annat läge, CFB konstruerar en självsynkroniserande strömkodning, med egenskaper någonstans mellan de för CBC och en synkron strömkryptering.

Så ditt antagande att det inte finns några kodningar mellan ström och blockkodare är inte riktigt sant. Kryptografer föredrar bara att bygga dem från den väl förstådda blockkrypteringen primitiva, istället för att skapa ett helt nytt system. Den använder en 26-symbolskodning istället för en 2-symbolskodning, men det betyder inte att det inte är en strömkodning. Titta på Solitaire / Pontifex för en modern konstruktion av en strömkryptering med 26 symboler.

Kommentarer

• Om jag inte ’ t ärr, ” kedja ” i blockkryptering används normalt i sammanhanget med ” blockkedjning ”, dvs gör de på varandra följande blocken beroende av varandra för att göra analys svårare. Så IMHO ECB skulle per definition inte ha någon kedjande effekt som sådan.
• Du gör fel. Ett bra kedjeläge har dessa egenskaper, men det finns fortfarande dåliga lägen!

Det finns två grundläggande typer av kryptering

1. Symmetrisk. Den använder samma nyckel för kryptering och dekryptering.
2. Asymmetrisk. Den använder två olika nycklar (offentliga och privata) för att kryptera och dekryptera.

Block Cipher and Stream Cipher utgör en del av Symmetric Encryption. Stream Cipher genererar en utökad nyckelström från användarnas nyckel och XoR den sedan med klartext (för kryptering) / ciphertext (för dekryptering).

Medan Block Cipher tar ett block av data som input, kör flera omgångar på det tillsammans med tangentblandning och producera krypteringstext. Blockciprarna har olika driftslägen varav Counter (CTR) -läget fungerar som strömkryptering. Ett sekventiellt nummer matas in till blockchiffran, och dess utdata är Xored med Plaintext för att göra Ciphertext. I detta driftsätt krävs endast krypteringskod för blockkodningen. Det finns inget behov av dekrypteringskod, för dekryptering anger vi helt enkelt samma löpnummer för att blockera kryptering och Xored dess utdata med krypteringstext för att få vanlig text. Någon gång används en nounce tillsammans med räknaren, så inmatningen är blockkodningen uppdelad i två, dvs en fast nounce och inkrementell räknare.

Annat driftsätt är: –

1. ECB (tillhandahåller konfidentialitet)
2. CBC och CTR (tillhandahåller konfidentialitet och är delvis säker mot utvald vanlig textattack)
3. EAX, CCM och GCM (tillhandahåller autentiserad kryptering)

Mer information kan hittas HÄR