Verschil tussen stroomcijfer en blokcijfer

A blokcijfer is een deterministische en berekenbare functie van $ k $ -bit-sleutels en $ n $ -bit (platte tekst) blokken naar $ n $ -bit (cijfertekst) blokken. (Meer in het algemeen hoeven de blokken geen bitformaat te hebben, $ n $ -karakter-blokken passen hier ook). Dit betekent dat wanneer u codeert hetzelfde platte tekstblok met dezelfde sleutel, krijgt u hetzelfde resultaat. (Normaal gesproken willen we ook dat de functie omkeerbaar is, dat wil zeggen dat we gezien de sleutel en het gecodeerde tekstblok de leesbare tekst kunnen berekenen.)

Om een bericht (van elke grootte) daadwerkelijk te versleutelen of te ontsleutelen, hoeft u niet ” t gebruik het blokcijfer rechtstreeks, maar plaats het in een modus . De eenvoudigste van een dergelijke modus is elektronische codeboekmodus (ECB) , die het bericht eenvoudig in blokken snijdt, de code op elk blok toepast en voert de resulterende blokken uit. (Dit is over het algemeen echter geen veilige modus.)

Sommige vroege versleutelingsschemas zoals die gebruikt door Caesar kunnen worden gecategoriseerd als een “blokcijfer met blokken van 1 teken in ECB -mode “. Of in het algemeen alles dat een codeboek heeft.

We gebruiken meestal andere bedieningsmodi, waaronder een initialisatie vector en een soort feedback, zodat elk blok van elk bericht wordt op een andere manier versleuteld.

Een stroomcijfer is een functie die $ k $ -bit-sleutels en platte teksten met een willekeurige lengte direct toewijst aan (dezelfde willekeurige lengte) cijfertekst, in zon manier waarop voorvoegsels van de leesbare tekst worden toegewezen aan voorvoegsels van de cijfertekst, dwz we kunnen het begingedeelte van de cijfertekst berekenen voordat het achterliggende gedeelte van de platte tekst bekend is. (Vaak zijn de berichtgroottes mogelijk ook beperkt tot veelvouden van een bepaalde “blokgrootte”, maar meestal met kleinere blokken zoals hele bytes of dergelijke.)

Als een deel van de platte tekst wordt herhaald, wordt de bijbehorende cijfertekst meestal is niet hetzelfde – verschillende delen van het bericht worden op verschillende manieren versleuteld.

Vaak werken dergelijke stroomcijfers door een keystream te produceren op basis van de daadwerkelijke sleutel (en misschien een initialisatievector ) en vervolgens gewoon XOR-ingaan met het bericht – deze worden synchrone stroomcijfers . Andere stroomcijfers kunnen de codering van toekomstige delen van het bericht variëren, afhankelijk van eerdere delen.

Sommige blokcoderingsmodi creëren in feite een synchrone stroomcodering, zoals CTR en OFB -modus.

Gebruik nooit een sleutel (en IV, indien van toepassing) van een synchrone stroomcijferaar (die blokcijfers bevat in streaming-modi) voor verschillende berichten, aangezien dit tot compromissen kan leiden. (En zelfs voor hetzelfde bericht zal het aangeven dat je een bericht hebt herhaald.)

Merk op dat je bij daadwerkelijk gebruik ook een MAC wilt, bijv. integriteitsbescherming, voor uw bericht. (Sommige schemas worden bijvoorbeeld verbroken in het geval van een aanval met gekozen cijfertekst, en zon MAC zal dit voorkomen (als je het bericht alleen doorgeeft aan de decryptor na controle van de MAC).)

Opmerkingen

• Wanneer zou je kiezen tussen een stream of een blokkering? Is er een verschil in beveiliging? Of snelheid van versleuteling?
• @anoopelias Blokcijfers zijn over het algemeen traag in vergelijking met Streamcijfers. Ik weet het ook niet zeker, maar ik denk dat stroomcijfers goed zijn in het bieden van informatiebeveiliging, terwijl blokcijfers goed zijn in het bieden van computerbeveiliging.
• Met betrekking tot de laatste alinea – zou u een link willen geven voor een voorbeeld waarin het toevoegen van een MAC beschermt tegen een aanval met gekozen gecodeerde tekst?

Wiskundig gezien is een blokcijfer slechts een ingetoetst pseudowillekeurige permutatie familie op de set $ \ {0,1 \} ^ n $ van $ n $ -bit blokken. (In de praktijk hebben we meestal ook een efficiënte manier nodig om de inverse permutatie te berekenen.) Een blokcijfer op zichzelf is niet erg handig voor praktische cryptografie, tenminste tenzij je toevallig kleine berichten die elk in een enkel blok passen.

Het blijkt echter dat blokcijfers extreem veelzijdige bouwstenen zijn voor het construeren van andere cryptografische tools: als je eenmaal een goed blokcijfer hebt, je kunt eenvoudig alles bouwen, van stroomcijfers tot hashfuncties, berichtauthenticatiecodes, sleutelafleidingsfuncties, pseudo-willekeurige nummergeneratoren, entropiepools, enz. op basis van slechts één blokcijfer.

Niet al deze applicaties noodzakelijk hebben een blokcijfer nodig; Velen van hen zouden bijvoorbeeld gebaseerd kunnen zijn op elke pseudowillekeurige functie die geen permutatie hoeft te zijn (maar handig is er “sa lemma die zegt dat een pseudo-willekeurige permutatie desalniettemin zal werken). Ook zijn veel van de constructies indirect. U kunt bijvoorbeeld een sleutelafleidingsfunctie construeren op basis van een berichtauthenticatiecode, die u kunt construeer vanuit een hash-functie, die je — kunt maken maar niet “t hebben tot — construeer vanuit een blok cijfer. Maar toch, als je een blokcijfer hebt, kan de rest eruit bouwen.

Bovendien worden deze constructies meestal geleverd met (voorwaardelijke) beveiligingsbewijzen die de beveiliging verminderen van de geconstrueerde functies naar die van het onderliggende blokcijfer. U hoeft dus niet de moeizame en onbetrouwbare taak uit te voeren om elk van deze functies afzonderlijk te analyseren —, maar u kunt al uw inspanningen concentreren op het blokcijfer, wetende dat elk vertrouwen dat u zult hebben in de veiligheid van het blokcijfer zich direct vertaalt in vertrouwen in alle functies die erop zijn gebaseerd.

Het is duidelijk dat dit allemaal erg handig is als u bijvoorbeeld werkt aan een klein ingebed platform waar het opnemen van efficiënte en veilige code voor veel afzonderlijke cryptoprimitieven moeilijk en duur kan zijn. Maar zelfs als je “niet op zon beperkt platform zit, kan het schrijven en analyseren van low-level cryptocode omslachtig zijn omdat je aandacht moet schenken aan zaken als side-channel aanvallen . Het is gemakkelijker om jezelf te beperken tot een beperkt aantal low-level bouwstenen en daar alles uit te bouwen wat je nodig hebt.

Ook, zelfs op snelle platforms met veel geheugen, zoals desktop-CPUs, kan het implementeren van low-level crypto-bewerkingen rechtstreeks in hardware veel sneller zijn dan in software —, maar het is niet praktisch om dat voor meer dan een paar van hen te doen . Vanwege hun veelzijdigheid zijn blokcijfers uitstekende kandidaten voor hardware-implementatie (zoals in de AES-instructieset voor moderne x86-CPUs).

Hoe zit het dan met stroomcijfers?

Wiskundig gezien is een stroomcijfer — in de meest algemene zin van de term — is ook een omkeerbare pseudowillekeurige functiefamilie met sleutels, maar op de set $ \ {0,1 \} ^ * $ van bitstrings met een willekeurige lengte in plaats van op blokken met een beperkte lengte.

(Er zijn enkele subtiliteiten hier; de meeste stroomversleutelingsconstructies vereisen bijvoorbeeld dat de invoer een unieke nonce -waarde bevat, en niet de veiligheid garanderen — in de zin van niet te onderscheiden zijn van een werkelijk willekeurige functie — als dezelfde nonce wordt gebruikt voor twee verschillende ingangen. er is geen uniforme verdeling over omkeerbare functies van $ \ {0,1 \} ^ * $ naar zichzelf om willekeurige functies uit te kiezen, we moeten zorgvuldig definiëren wat het betekent voor een stroomcijfer om er “niet van willekeurig te onderscheiden” uit te zien, en deze definitie heeft doet praktische veiligheidsimplicaties — bijvoorbeeld, de meeste stroomcijfers lekken de lengte van het bericht. Praktisch gezien eisen we meestal ook dat stroomcijfers, in in feite “streaming” zijn, in de zin dat willekeurig lange invoerbitstromen kunnen worden versleuteld — en — kunnen worden ontsleuteld met o nly constante opslag en tijd lineair in de berichtlengte.)

Natuurlijk zijn stroomcijfers veel directer bruikbaar dan blokcijfers: je kunt ze rechtstreeks gebruiken om berichten van elke lengte te coderen. Het blijkt echter dat ze “ook veel minder nuttig zijn als bouwstenen voor andere cryptografische tools: als je een blokcijfer hebt, kun je gemakkelijk verander het in een stroomcijfer , terwijl het omzetten van een willekeurig stroomcijfer in een blokcijfer moeilijk, zo niet onmogelijk is .

Dus waarom zouden mensen überhaupt de moeite nemen om speciale stroomcijfers te ontwerpen, als blokcijfers het werk net zo goed kunnen doen? Meestal is de reden de snelheid: soms heb je een snel cijfer nodig om veel gegevens te coderen, en er zijn er enkele echt snelle speciale streamcijferontwerpen die er zijn. Sommige van deze ontwerpen zijn ook ontworpen om zeer compact te implementeren, hetzij in software of hardware, of beide, zodat als je echt alleen een streamcijfer nodig hebt, je bespaar op code / circuitgrootte door een van die cijfers te gebruiken in plaats van een algemeen blokcijfer gebaseerd.

Wat je echter wint aan snelheid en compactheid, verlies je aan veelzijdigheid. Bijvoorbeeld, er lijkt geen “simpele manier te zijn om een hash-functie te maken uit een stroomcijfer , dus als je er een nodig hebt (en je vaak doen, omdat hash-functies, behalve dat ze op zichzelf nuttig zijn, ook gebruikelijke bouwstenen zijn voor andere crypto-tools), zul je ze apart moeten implementeren. En raad eens, de meeste hash-functies zijn gebaseerd op blokcijfers, dus als je er een hebt, kun je net zo goed hetzelfde blokcijfer hergebruiken voor codering (tenzij je echt de onbewerkte snelheid van het speciale stroomcijfer nodig hebt).

Opmerkingen

• Ik vroeg me af of het nodig is om twee verschillende termen te gebruiken. Volgens wat je hebt uitgelegd, is een stroomcijfer gewoon een speciaal geval van een blokcijfer, dat wil zeggen een voor het beperkende geval waarin de n in de reeks {0,1} ^ n 1 is. Dus ik zou pleiten voor het niet handhaven van de huidige onderscheid van terminologieën.
• @ Mok-KongShen Eigenlijk is een stroomcijfer niet simpelweg een blokcijfer met blokgrootte 1 (behalve klassieke monoalfabetische cijfers, waarvan kan worden aangenomen dat ze beide zijn). Een stroomcijfer vertaalt gewoonlijk de bits / bytes / … van de stroom anders, afhankelijk van de huidige interne toestand van het cijfer, terwijl een blokcijfer voor dezelfde invoer dezelfde uitvoer heeft (en dus meestal wordt gebruikt in een ” werkingsmodus ” om een stroomcijfer te maken).
• @PauloEbermann. IMHO je beantwoordde voor mij een vraag van CodesinChaos betreffende ” dynamiek en variabiliteit “.
• @ Mok-KongShen Nee hij deed het niet ‘ t. Het enige voordeel dat een speciaal stroomcijfer heeft ten opzichte van een blokcijfer in een geschikte modus, zijn prestaties. Je kunt ‘ de chaining-modi niet negeren, aangezien niemand normaal blokcijfers gebruikt zonder de juiste chaining.
• @CodesInChaos. Verschillende applicaties hebben verschillende prestatie-eisen. Om b.v. een e-mail heeft ‘ niet de prestatie nodig die wenselijk zou zijn voor het versleutelen van bijvoorbeeld een videobestand.

Een blokcijfer op zichzelf wijst n bits toe aan n bits met behulp van een sleutel. dwz het is een gecodeerde pseudo-willekeurige permutatie. Het kan geen langere of kortere teksten accepteren.

Om een bericht daadwerkelijk te versleutelen heeft u altijd een kettingmodus nodig. ECB is zon kettingmodus (en een hele slechte), en het is niet het pure blokcijfer. Zelfs ECB bestaat uit “add-on-verwerkingen”. Deze kettingmodi kunnen behoorlijk verschillende eigenschappen hebben.

Een van de meest populaire kettingmodi, de tellermodus (CTR), construeert een synchrone stroomcijfer van een blokcijfer.Een andere modus, CFB construeert een zichzelf synchroniserende stroomcijfer, met eigenschappen ergens tussen die van CBC en een synchrone stroomcijfer.

Dus uw aanname dat er geen cijfers zijn tussen stroom- en blokcijfers is niet echt waar. Cryptografen geef er gewoon de voorkeur aan ze te bouwen vanuit de goed begrepen primitieve blokcodering, in plaats van een volledig nieuw systeem te creëren.

Ik zou Vigenère een stroomcijfer noemen, zij het een met een veel te korte periode. Het gebruikt een codering van 26 symbolen in plaats van een codering van 2 symbolen, maar dat betekent niet dat het geen stroomcijfer is. Kijk naar Solitaire / Pontifex voor een moderne constructie van een stroomcijfer met 26 symbolen.

Opmerkingen

• Als ik ‘ t err niet, ” chaining ” in blokversleuteling wordt normaal gesproken gebruikt in de context van ” block chaining “, dwz de opeenvolgende blokken afhankelijk van elkaar maken om de analyse moeilijker. Dus IMHO ECB zou per definitie geen kettingeffect hebben.
• Je vergist je. Een goede koppelingsmodus heeft deze eigenschappen, maar er bestaan nog steeds slechte modi!

Er zijn twee basistypen versleuteling

1. Symmetrisch. Het gebruikt dezelfde sleutel voor codering en decodering.
2. Asymmetrisch. Het gebruikt twee verschillende sleutels (openbaar en privé) om te coderen en te decoderen.

Block Cipher en Stream Cipher maken deel uit van symmetrische codering. Stream Cipher genereert een uitgebreide sleutelstroom van de door de gebruiker gegeven sleutel en XoR deze vervolgens met platte tekst (voor codering) / cijfertekst (voor decodering).

Terwijl Block Cipher een gegevensblok als invoer neemt, voer je er meerdere rondes op uit samen met key mixen en Cipher Text produceren. De Block Ciphers hebben verschillende werkingsmodi waarvan de Counter (CTR) -modus op dezelfde manier werkt als een streamcijfer. Een volgnummer wordt ingevoerd in het blokcijfer en de uitvoer wordt Xored met platte tekst om cijfertekst te maken. In deze modus is alleen coderingscode van het blokcijfer vereist. Er is geen decoderingscode nodig, voor decodering voeren we gewoon hetzelfde volgnummer in om de codering te blokkeren, en Xored de uitvoer met Ciphertext om platte tekst te krijgen. Soms wordt een naamwoord samen met de teller gebruikt, dus de invoer van het blokcijfer wordt in tweeën gesplitst, d.w.z. een vaste naam en een incrementele teller.

Andere bewerkingsmodi zijn: –

1. ECB (biedt vertrouwelijkheid)
2. CBC en CTR (biedt vertrouwelijkheid en sementisch beveiligd tegen Chosen Plaintext Attack)
3. EAX, CCM en GCM (biedt geverifieerde versleuteling)

Meer details zijn te vinden HIER