AEAD block chifferlä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 27 maj 2020; kontroller kräver 2 redigeringar .

AEAD-blockchifferlägen ( eng.  Authenticated Encryption with Associated Data , "autenticated encryption with bifoged data") är en klass av blockchifferlägen där en del av meddelandet är krypterat, en del förblir öppen och hela meddelandet autentiseras . Idén med en sådan krypteringsklass föreslogs först av Charanjit Jutla 2000 [1] . Flera AEAD-krypteringslägen föreslås för närvarande: OCB-läge (sedan OCB2), CCM-läge , EAX-läge , CWC-läge och GCM-läge . Den senare har varit en NIST- standard sedan 2007 [2] .

Felsökning

Det finns algoritmer som tillåter autentisering och kryptering - autentiserad kryptering (nedan kallad AE), men de ger inte möjlighet att bifoga vanlig text (associerad data), vilket särskilt inträffar om det är nödvändigt att bifoga en IP-adress till ett meddelande . I allmänhet krävs vanlig textdata för att förmedla rubriker, adresser, portar, protokollversioner och annan data som behövs för att bestämma hur chiffertexten ska bearbetas eller skickas. Ofta måste dessa data autentiseras medan de förblir offentliga för att bearbetningsenheter ska kunna hantera dessa meddelanden korrekt. Det finns en önskan att modifiera AE-schemat genom att lägga till en imitationsinlägg (MAC) till det för autentisering av öppna data, och för att få ett AEAD-schema "billigt". Men de uppenbara "naiva" lösningarna, exempel på vilka vi kommer att överväga nedan, visar sig vara ineffektiva.

Låt, till exempel, du behöver skicka ett meddelande M , en öppen rubrik H , något AE-krypteringsläge E är valt och en MAC-funktion. Sedan, om E(M) och H sänds , kommer H att vara oautentiserad. Om vi ​​sänder E(M||H) och H , kommer längden på det överförda meddelandet att vara längre än det ursprungliga (eftersom krypteringsoperationen H , som är onödig i denna uppgift, kommer att utföras ), detsamma kan sägas för sändningen H , E(M) , MAC( H||E(M)) (eftersom E(M) redan är autentiserad och att använda MAC är resurskrävande).

Viktigt är att både AE-scheman och AEAD-scheman kräver användning av en nonce . Detta är nödvändigt för att säkerställa semantisk säkerhet (omöjligheten för en angripare, när en angripare upprepade gånger använder ett schema under samma nyckel, för att få relationer mellan segment av krypterade meddelanden), samt för att skydda mot en replay-attack , där en angripare, förklädd som en legitim användare, skickar ett meddelande igen. Det är avsändarens ansvar att generera en nonce och endast använda den en gång. För att göra detta kan du använda till exempel en räknare.

Implementeringsmetoder

Det finns två fundamentalt olika sätt att implementera AEAD-krypteringsläget. Den första involverar användningen av blockkryptering och personifiering. I det här fallet kan designern av AEAD-schemat välja vilket blockchiffer som helst och funktionen för att få den imiterade infogningen, samtidigt som en nonce används. Det andra sättet är någon form av transformation av AE-schemat. Kraven för den sista metoden förblir desamma: kretsen får inte sakta ner avsevärt och den får inte introducera nya sårbarheter . Säkerheten och tillförlitligheten för dessa tillvägagångssätt bevisades i Charanjit S. Jutlas artikel "Encryption Modes with Almost Free Message Integrity", förutsatt att nonce inte återanvänds och hashfunktionen H är kryptografiskt säker.

Metoder för att implementera AEAD-läge med hjälp av ett blockchiffer och imitation av personifiering

Det finns två sätt att få AEAD-läge med hjälp av ett blockchiffer och imitera infogning: först genom att kryptera meddelandet, sedan genom att autentisera (kryptera-sedan-mac), eller i omvänd ordning (mac-sedan-kryptera).

Kryptera-sedan-mac

I denna variant krypteras meddelandet M först med användning av nonce N, sedan autentiseras rubriken H och det krypterade meddelandet av MAC:n med samma nonce.

Mac-sedan-kryptera

Som ovan, men i omvänd ordning: först skapas en MAC-spoof från H-huvudet, nonce N, och klartext M, och sedan krypteras meddelandet M med den mottagna spoofen med samma nonce N.

Metoder för att implementera AEAD-läge med AE-schema

Som visas ovan är det inte möjligt att effektivt bifoga autentiserad klartext till ett AE-schemabyggt meddelande med primitiva metoder. Följande två metoder har dock föreslagits [1] .

Icke-stöld

Låt det finnas ett AE-schema som använder en nonce av n bitar, och en applikation som använder detta schema behöver bara använda n2 bitar (n2 < n). Då kan de fria h = n − n2 bitarna användas för att lagra öppna data. Detta schema har en gräns för storleken på öppna data, men ofta räcker detta. Låt algoritmen ha en nonce på 128 bitar, och applikationen använder bara 16, sedan återstår 112 bitar för öppna data, vilket ofta räcker (till exempel kräver en adress i IPv4- protokollet 32 ​​bitar).

Chiffertextöversättning

Denna metod för att konvertera ett AE-schema till ett AEAD-schema är baserad på den logiska additionsoperationen (XOR) , medan om en operation utförs på strängar av olika längd, så är den kortare utfylld med icke-signifikanta nollor, till exempel : .

Denna metod inkluderar följande operationer: ett AE-schema används för att kryptera meddelandet med nyckeln K och erhålla en mellanliggande chiffertext CT, sedan appliceras en hashfunktion för att erhålla skiftet Δ, och slutligen erhålls den slutliga chiffertexten genom att tillämpa logisk additionsoperation Δ till de sista bitarna CT. Observera att om rubriken är en tom sträng, överförs det resulterande AEAD-schemat till det ursprungliga AE-krypteringsschemat. Om rubriken förblir oförändrad under sessionen kan skiftet Δ beräknas i förväg, vilket har en positiv effekt på krypteringstiden - den återstående logiska additionsoperationen implementeras enkelt (inklusive i hårdvara).

Låt oss definiera det resulterande AEAD-schemat mer strikt enligt följande:

Det vill säga, om vi antar att vi beräknar Δ med en längd av τ bitar, krypterar M och utför operationen med logisk addition av de sista τ bitarna med Δ.

Denna metod har följande fördelar:

Nackdelen med metoden är emellertid behovet av att använda två nycklar K och K'.

AEAD-algoritmer

Till exempel beskriver vi några AEAD-algoritmer. Två av dem är baserade på AES GCM, två av dem är baserade på AES CCM. En av algoritmerna i varje par använder en 128-bitars nyckel, den andra använder en 256-bitars.

AEAD AES 128 GCM

Denna algoritm använder AES-128 som blockchiffer, med nyckel, nonce, meddelande och rubrik som indata. Rubrikens längd är 16 byte. Chiffertexten genereras genom att lägga till en autentiseringstagg till den mellanliggande chiffertexten som tas emot som utdata från GCM-krypteringen. Ingångs- och utmatningsstorlekskraven är följande:

Således är chiffertexten 16 byte längre än det ursprungliga öppna meddelandet.

AEAD AES 256 GCM

Algoritmen är helt lik den föregående, förutom att använda en 32-byte nyckel och AES-256 GCM.

AEAD AES 128 CCM

Liknar den föregående, förutom att använda CCM-läge istället för GCM, medan:

Precis som med GCM är chiffertexten 16 byte längre än det ursprungliga meddelandet.

AEAD AES 256 CCM

Algoritmen är helt lik den föregående, förutom att använda en 32-byte nyckel och AES-256 GCM.

Anteckningar

  1. ↑ 1 2 Jutla, Charanjit S. (2000-08-01) "Krypteringslägen med nästan gratis meddelandeintegritet" Arkiverad 19 augusti 2012 på Wayback Machine . Kryptologi ePrint Arkiv: Rapport 2000/039. IACR . Hämtad 2013-03-16
  2. ↑ NIST Special Publication 800-38D Arkiverad 5 augusti 2011 på Wayback Machine , november 2007, Rekommendation för BlockCipher-funktionslägen: Galois/Counter Mode (GCM) och GMAC.

Länkar