Krypteringsläge

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 13 september 2016; kontroller kräver 48 redigeringar .

Krypteringsläge  - en metod för att tillämpa ett blockchiffer (algoritm) som låter dig konvertera en sekvens av öppna datablock till en sekvens av krypterade datablock . I detta fall kan data från ett annat block användas för att kryptera ett block.

Vanligtvis används krypteringslägen för att ändra krypteringsprocessen så att resultatet av krypteringen av varje block är unikt oavsett vilken data som krypteras och inte tillåter några slutsatser om deras struktur. Detta beror främst på det faktum att blockchiffer krypterar data i block av en fast storlek, och därför finns det risk för läckage av information om upprepade delar av data krypterad med samma nyckel .

Historik

1981 antogs FIPS 81- standarden . Standarden beskrev de första sätten för blockchiffer: ECB, CBC, OFB och CFB. År 2001 reviderade NIST Institute ( US National Institute of Standards and Technology ) listan över lägen och lade till en beskrivning av hur AES -blockchifferet fungerar i CTR-läge ( SP800-38A ) till den. I januari 2010 lade NIST till en beskrivning av AES -chifferets funktion i XTS-läge (SP800-38E) till standarden.

Standarden beskriver inte alla lägen, utan endast de lägen som godkänts av NIST -institutet . Till exempel beskrivs inte CTS -läget ( chiffertext-stöld )  i standarden, men är implementerat i många populära kryptografiska bibliotek .

Krypteringslägen definieras av ett antal nationellt och internationellt erkända organisationer. Den mest inflytelserika av dessa är NIST .

Huvudlägen

Nedan finns en beskrivning av flera krypteringslägen som använder blockchiffer [1] .

Elektronisk kodbok (ECB)

I GOST 28147-89 kallas detta läge för det enkla ersättningsläget .

Kryptering:

Låt ett meddelande ges ( klartext , bitsekvens, data).

Under kryptering utförs följande åtgärder:

  1. Meddelandet är uppdelat i block av samma storlek. Blockstorleken (längden) är n och mäts i bitar . Resultatet är en sekvens av block . Det sista blocket stoppas till längd [2] [3] vid behov .
  2. Varje block krypteras med en krypteringsalgoritm med nyckeln k :
var: Resultatet är krypterade block .

Dekryptering:

exekveras av funktionen med samma tangent k :

Egenheter:

Nackdelar med ECB:

Vanlig text som bild Kryptogram erhållet genom kryptering i ECB-läge. Bilden visar egenskaper från originalbilden Kryptogram erhållet genom icke-ECB-kryptering. Bilden är en pseudo-slumpmässig sekvens av pixlar

Fördelar med ECB:

Detta läge kallas det elektroniska kodboksläget, eftersom det är möjligt att skapa en bok där varje block med vanlig text kommer att associeras med ett block med chiffertext. Men att skapa en bok är inte en trivial uppgift. Om blockstorleken är x bitar kommer boken att innehålla 2 x poster, och varje bok kommer att motsvara en nyckel.

Cipher Block Chaining (CBC)

För att kryptera ett meddelande utförs följande steg [4] .

(initieringsvektor är ett slumptal) Storleken (längden) på IV är lika med blockstorleken ( n ). var:

Dekryptering utförs av funktionen med samma nyckel k och initialiseringsvektor IV :

Nackdelar med CBC:

Fördelar med CBC:

Propagating Cipher Block Chaining (PCBC)

Bristerna i CBC-läget ledde till skapandet av ett förbättrat läge för spridning av chifferblockkedjning (Propagating Cipher Block Chaining, PCBC) [4] . Naturligtvis liknar det här läget CBC, förutom att det tidigare klartextblocket och det föregående chiffertextblocket är XORed med det aktuella klartextblocket före eller efter kryptering. [1] Följaktligen, dekryptering: var  är initialiseringsvektorn RSVS-krypteringsläget används i Kerberos 4-protokollversionen och låter dig upptäcka fel. Detta krypteringsläge är inte en federal eller internationell standard. PCBC-läget är en variant av CBC-läget, som har en specifik egenskap - ett chiffertextfel leder till felaktig dekryptering av alla efterföljande block. Detta innebär följaktligen att kontroll av byggstenen i slutet av meddelandet säkerställer integriteten för hela meddelandet.




Naturligtvis är detta läge inte utan brister, eftersom byte av två block av chiffertext gör att de två motsvarande blocken av klartext dekrypteras felaktigt, men på grund av XOR över klartext och chiffertext kompenseras ytterligare fel. Därför, om integritetskontrollen endast kontrollerar de sista blocken av den dekrypterade texten, kan du få ett delvis skadat meddelande. Även om ingen ännu har utnyttjat denna sårbarhet i Kerberos, har version 5 redan gått över till CBC-läge.

Chifferfeedback (CFB)

Chiffertextåterkopplingsläge , chifferåterkopplingsläge , CFB [ 4 ] . _ _ _ _ Under kryptering läggs varje klartextblock till modulo 2 till blocket som krypterats i föregående steg.  

Styrkan hos CFB bestäms av styrkan på det använda chiffer. Block med klartext "blandas" ("maskerade") med block av chiffertext . Om det finns två identiska block av chiffertext i CFB-läge med full blockåterkoppling blir resultatet av till exempel DES-kryptering i nästa steg detsamma. Krypteringshastigheten för CFB-läget med full blockåterkoppling är densamma som för blockchifferet, och möjligheten att parallellisera krypteringsproceduren är begränsad [1] .

Output Feedback (OFB)

Utmatningsåterkopplingsläget (OFB) [4] förvandlar blockchifferet till ett synkront strömchiffer: det genererar nyckelblock som är resultatet av tillägg med klartextblock för att erhålla chiffertexten. Precis som med andra strömchiffer, ger spegling i chiffertexten en speglad bit i klartexten på samma plats. Den här egenskapen tillåter många felkorrigerande koder att fungera normalt även när felkorrigering tillämpas före kodning.

På grund av symmetrin i tilläggsoperationen är kryptering och dekryptering liknande:

Varje operation av utgångsåterkopplingsblockchifferet beror på alla föregående och kan därför inte utföras parallellt. Men eftersom klartext eller chiffertext endast används för den slutliga tillägget, kan blockchifferoperationerna utföras i förväg, vilket gör att den slutliga krypteringen kan utföras parallellt med klartexten.
Återkoppling på utdata till k bitar rekommenderas inte av säkerhetsskäl . OFB-moden har följande fördel jämfört med CFB-moden: fel som härrör från överföring över en brusig kanal "smetas" inte ut över hela chiffertexten under dekryptering, utan lokaliseras inom ett block. Men klartexten kan ändras genom vissa manipulationer av chiffertextblocken. Trots det faktum att OFB-kryptering inte är parallelliserbar, kan effektiviteten av proceduren förbättras genom att förgenerera en oberoende sekvens av block. [ett]

Denna metod kallas även " utgångsåterkopplingsläge ".

OFB föreslår också en viss förbättring när det gäller metoden för att generera en oberoende sekvens av block: för att erhålla nästa block, föreslås det att kryptera inte med utan med c , där är någon initialiseringsvektor.

Räknarläge (CTR)

Räknarmoden (CTR) [4] involverar att återgå till ingången för motsvarande blockchifferalgoritm av värdet på någon räknare som ackumulerats sedan starten. Läget gör en blockchifferström, det vill säga den genererar en sekvens på vilken XOR-operationen appliceras med meddelandetexten. Klartexten och chiffertextblocket har samma blockstorlek som det underliggande chifferet (som DES eller AES ). [5] CTR-läget ger följande funktioner.

Kryptering i CTR-läge

Dekryptering i CTR-läge

 — räknarvärde för det i:te blocket.

Uppenbarligen måste räknarvärdena vara unika för varje block av klartext kodat av ett givet chiffer med en given nyckel (annars är block av chiffertext krypterade med identiska räknarvärden i riskzonen). Detta krav uppfylls i två steg.

Först erhålls räknarvärdena för kryptering av block i ett enda meddelande från det initiala räknarvärdet med hjälp av inkrementfunktionen. För att säkerställa slumpmässighet kan mängden ökning bero på blocknumret. Standardinkrementfunktionen kan appliceras på hela räknarblocket eller på en del av det. Låt räknarvärdet representera ett block av b bitar och låt inkrementfunktionen appliceras på de minst signifikanta bitarna.

 är sammanlänkningsfunktionen ;  - lägre bitar;  — senior bitar. Räknarvärdenas unika är säkerställd för alla block i meddelandet, förutsatt att . Var  är antalet block som meddelandet är uppdelat i.

För det andra väljs de initiala räknarvärdena för varje meddelande för att säkerställa att alla använda räknarvärden är unika. Detta kan uppnås på många sätt. Till exempel, om meddelanden krypteras sekventiellt, kan resultatet av applicering av inkrementfunktionen på det sista värdet av den föregående meddelanderäknaren användas som det initiala värdet för räknaren för detta meddelande. Dessutom, om inkrementfunktionen använder m bitar, bör det totala antalet klartextblock inte överstiga . Ett annat tillvägagångssätt föreslår att dela den binära representationen av räknaren i två delar. De mest signifikanta siffrorna tilldelas meddelandets nonce, och inkrementfunktionen [6] kommer att tillämpas på de återstående siffrorna .

I frånvaro av feedback kan krypterings- och dekrypteringsalgoritmerna i CTR-läge exekveras parallellt. Dessutom kan den stora mängden beräkning som är involverad i kryptering av räknarvärden göras i förväg, innan klartext eller chiffertext är tillgänglig. Detta ger CTR-läget en fördel jämfört med CFB- och OFB-lägena.

Random Delta (RD)

Random Delta-läget används för att eliminera förutsägbarheten av räknarändringar i CTR-läge. Till exempel är detta AES, och blockstorleken är 16 byte. En slumpmässig initialiseringsvektor tas (till exempel genom att använda RdRand ). Dess lägre 8 byte anses vara slumpmässigt delta - slumpmässigt delta (RD):

Initial (initieringsvektor) krypteras och skickas i början av meddelandet. Block 0 XORed med Initial före kryptering. För varje efterföljande block ökar värdet på Initial med Delta (i heltalsrepresentation utan tecken - uint128 += uint64):

Detta eliminerar förutsägbarheten av att ändra räknaren i CTR-läge. Om delta alltid är ett, är delta här ett slumptal, ett av 2^64. Den är, liksom Initial, okänd för angriparen.

Dessutom är CTR alarmerande på grund av den direkta närheten av klartext till chiffertexten via XOR. I Random Delta ligger AES mellan klartext och chiffertext.

Öppenheten i den inledande överföringen väcker också frågor. Ju mindre angriparen ser, desto bättre. Ju längre klartexten är från chiffertexten, desto bättre. Alla kända lägen - ECB, CBC, OFB, CTR - har några av dessa brister. I Random Delta ligger allt bakom AES, och Initial och Delta är slumpvariabler som är okända för angriparen.

En av nackdelarna med CTR i RD finns dock. Att känna till formatet på de överförda data gör att slumpmässiga förvrängningar kan kastas in på vissa platser av denna data, som kan användas för en attack. En hash kan läggas till blocksekvensen för att kontrollera integriteten:

Det verkar som om Random Delta + Hash inte har dessa nackdelar. Överförd till allmän egendom.

En viktig punkt: det måste finnas många AES-permutationer mellan den stängda texten och den öppna texten, annars försvagar det krypteringsdjupet. Den stängda texten som en funktion av den öppna texten, enbart genom XOR , upphäver krypteringsdjupet som AES ger (det här är nämligen metoden som används av OFB, CFB, CTR-lägen).

Säkerheten för Random Delta är inte mycket lägre än för AES själv.

Om en högre grad av deltaslumpmässighet krävs (till exempel 128-bitars), kan den genereras separat och skickas i början av meddelandet tillsammans med Initial.

Liksom CTR låter Random Delta dig kryptera / dekryptera block parallellt, med högre prestanda, utan att vänta på kryptering / dekryptering av föregående block (vilket är en nödvändighet i CBC, PCBC, CFB, OFB).

Läget "Random Delta 128" särskiljs genom användningen av separata 128-bitars Initial och Delta. Ger mer slumpmässighet till skuggan.

Galois/Counter Mode (GCM) och AEAD

Galois/Counter Mode (räknare med Galois- autentisering ) är en säkrare modifiering av CTR som tillhandahåller autentiserad kryptering med bifogade data ( AEAD block cipher mode ).

Initialiseringsvektor (IV)

I kryptografi representerar initieringsvektorn ( ) något tal, som regel bör det vara slumpmässigt eller pseudoslumpmässigt . Slumpmässighet är avgörande för att uppnå semantisk säkerhet, vilket, när ett schema återanvänds under samma nyckel, kommer att förhindra en angripare från att sluta sig till relationer mellan krypterade meddelandesegment. För blockchiffer beskrivs användningen av arbetssätt. Randomisering krävs också för andra primitiver som universella hashfunktioner och meddelandeautentiseringskoder baserade på dem.

I sådana krypteringslägen som CBC, CFB och OFB matas initialiseringsvektorn ( ) som indata. Dessutom måste både avsändaren och mottagaren i början av kommunikationssessionen ha samma . Värdet behöver inte alls vara hemligt och kan mycket väl sändas tillsammans med det första blocket i chiffertexten. Vad som verkligen är viktigt är att i CBC- och CFB-lägen måste detta värde vara oförutsägbart, och i OFB-läge måste det vara unikt [2] .

Oförutsägbarhet i CBC- och CFB-lägen kan uppnås på flera sätt. Det är till exempel möjligt att transformera värdet på någon räknare (säg meddelanderäknaren) med samma funktion. Eller använd GPC för att generera en pseudo-slumpmässig sekvens av önskad längd.

I OFB-läge behöver initialiseringsvektorn inte vara oförutsägbar, utan den måste vara unik för alla kommunikationssessioner där samma hemliga krypteringsnyckel används i OFB . Detta kan uppnås, återigen med hjälp av en meddelanderäknare. Om detta krav inte följs, kan sekretessen för meddelandet i OFB-läge lätt äventyras. En konsekvens av detta krav är att nästa initialiseringsvektor för OFB-läge inte kan genereras genom att tillämpa en funktion med samma nyckel .

Vaddering (fyllning)

ECB-, CBC- och PCBC-lägena fungerar med klartextmeddelanden som måste vara en multipel av längden på ett block. Om den här egenskapen inte uppfylls måste det erforderliga antalet bitar, kallat utfyllnad, läggas till i meddelandet .  Till exempel, "utfyllnadsmetod 2" ISO/IEC 9797-1 föreslår att man lägger till en enda bit i slutet av meddelandet och fyller resten med nollor [7] .

Med denna metod måste mottagaren av chiffertexten veta säkert att meddelandet innehåller en utfyllnad. Detta kan uppnås genom att bifoga utfyllnad till varje meddelande, även om det inte krävs (i vilket fall det skickas som ett separat block). Detta är inte den enda lösningen - du kan till exempel skicka information om dess längd med varje meddelande [6] .

Spridning av fel

För vilket läge som helst, orsakar en felbit i ett chiffertextblock att resultatet av dess dekryptering blir korrupt. I CFB-, OFB- och CTR-lägen kommer den korrupta biten att ha samma position i det dekrypterade blocket som felbiten i chiffertextblocket, och felet kommer inte att spridas till de återstående bitarna i blocket. I ECB- och CBC-lägen kan vilken bit av blocket som helst skadas, med en sannolikhet på cirka 50 % (beroende på själva chifferns styrka). Samtidigt, i lägena ECB, OFB och CTR, är endast blocket som är ett resultat av dekrypteringen av det korrupta blocket skadat. I CBC-läge är nästa block också föremål för felaktig dekryptering, och de korrupta bitarna kommer att motsvara felbitarna i det föregående blockets chiffertext. I CFB-läge påverkar en felbit i ett chiffertextsegment nästa b/s (avrundat till närmaste heltal, b är blocklängden, s är segmentlängden) av segmenten, och vilken som helst av bitarna i den dekrypterade texten kan vara felaktig [6] .

Närvaron av felbitar i initialiseringsvektorn är också skadlig för dekrypteringsprocessen. I OFB-läge träffar felbiten i IV varje chiffertextblock i motsvarande meddelande. I CFB-läge kommer fel i initialiseringsvektorn att förstöra åtminstone det första segmentet av chiffertexten. Huruvida resten av segmenten är skadade beror på positionen för biten längst till höger i IV (i värsta fall kommer b/s i chiffertextsegmenten att påverkas). När du använder OFB- och CFB-lägena kan vilken bit som helst av den korrupta chiffertexten skadas som ett resultat av en felbit i IV. I CBC-mod kommer endast bitarna i det första chiffertextblocket som är i positioner som motsvarar felbitarna i initialiseringsvektorn att skadas.

För CTR-läge, orsakar en felbit i räknarvärdet vilken bit som helst i dekrypteringen av motsvarande chiffertext att skadas med en sannolikhet på cirka 50 %.

Förutom förekomsten av en felbit i ett chiffertextblock kan radering eller bitinfogning också ske. Detta leder till överträdelse av gränserna för alla efterföljande block av chiffertexten, och resultaten av dekrypteringen kommer att vara helt fel tills gränserna är synkroniserade. När du använder 1-bitars CFB-läge, återställs synkroniseringen automatiskt b+1-positioner efter att en bit dyker upp eller försvinner. I andra lägen sker ingen automatisk synkroniseringsåterställning [6] .

Val av krypteringsläge

Valet av krypteringsläge beror på ditt mål.

För klartext kan du använda CBC, CFB eller OFB. För att kryptera filer är det bättre att använda CBC: säkerheten ökar kraftigt, när fel uppstår i lagrad data misslyckas synkroniseringen nästan aldrig. Det specifika läget beror på dina krav. I allmänhet är valet av krypteringsmetod ett sökande efter en kompromiss mellan effektivitet och prestanda [8] .

Anteckningar

  1. 1 2 3 4 5 6 Vorobyeva Elena, Lukyanova Alexandra "Kryptografi" (otillgänglig länk) . Hämtad 11 december 2012. Arkiverad från originalet 5 december 2012. 
  2. 1 2 3 Zenin O. " Krypteringslägen arkiverad 20 augusti 2011 på Wayback Machine ".
  3. Andrey Vinokurov "Krypteringslägen" . Hämtad 16 februari 2008. Arkiverad från originalet 19 februari 2008.
  4. 1 2 3 4 5 Bruce Schneier "Applied Cryptography"
  5. B. A. Forouzan "Mathematics of Cryptography and Encryption Theory"
  6. 1 2 3 4 NIST: Rekommendation för blockchifferfunktioner . Datum för åtkomst: 25 december 2013. Arkiverad från originalet 22 juli 2017.
  7. ISO/IEC 9797-1: Informationsteknologi - Säkerhetstekniker - Message Authentication Codes (MACs) - Del 1: Mechanisms using a block cipher , ISO/IEC, 2011 , < http://www.iso.org/iso/iso_catalogue /catalogue_ics/catalogue_detail_ics.htm?csnumber=50375 > Arkiverad 27 december 2013 på Wayback Machine 
  8. Full diskkryptering (nedlänk) . Hämtad 11 december 2012. Arkiverad från originalet 13 oktober 2012. 

Se även

Litteratur