Vilken är fördelen med XTS jämfört med CBC-läge (med diffusor)?
On november 30, 2020 by adminJag har några problem med att förstå ”fördelen” med AES-XTS jämfört med CBC med diffusor.
Jag läste något om FileVault , i denna uppsats nämner de de två driftsätten XTS och CBC (med diffusor) och fördelarna med XTS.
Båda lägena krypterar dataenheter nästan på samma sätt. För CBC används sektornumret på något sätt för att bygga IV, för XTS finns ett ”tweak-värde”, vilket också inkluderar (på något sätt) blockoffset, så att varje datablock kan krypteras oberoende (meningsfullt vid kryptering av hårddiskar / partitioner). Jag kan inte riktigt se fördelen med XTS.
Nu skriver de följande om XTS:
Det finns flera fördelar jämfört med alternativ såsom AES i CBC: det finns inget krav på en initialiseringsvektor (tweak-tangenten kan härledas från blocknumret); varje block krypteras annorlunda (eftersom tweak-värdet kommer att vara annorlunda); och till skillnad från AES-CBC förhindrar AES-XTS att en angripare ändrar en specifik bit i en dataenhet genom att xorera varje AES-ingång med en annan förskjuten version av den krypterade tweak.
Kanske jämför de bara XTS mot CBC (utan diffusor) … om så, vet någon någon fördel med XTS?
Och kan någon förklara den andra fördelen: ”AES- XTS hindrar en angripare från att ändra en specifik bit i en dataenhet genom att xorera varje AES-ingång med en annan förskjuten version av den krypterade tweak. ”?
Kommentarer
- Vad ' s " diffusor "? " sektornumret är på något sätt " hur? Du ' beskrev inte schemat tydligt. Om algoritmen är förutsägbar leder detta till svagheter och en oförutsägbar algoritm är dyr.
- @CodesInChaos Jag tror att referensen är till Microsoft ' s Elefantdiffusor som används i BitLocker ( download.microsoft.com/download/0/2/3/… – varning: nedladdningar PDF ).
- Välkommen till Cryptography Stack Exchange. Din fråga migrerades hit på grund av att den inte var direkt relaterad till mjukvaruutveckling (ämnet Stack Overflow) och var mer on-topic här. Vänligen registrera ditt konto också här för att kunna kommentera och acceptera ett svar.
Svar
XTS vs. Undiffused CBC. Problemet här är smidbarhet . Både XTS och CBC hindrar en angripare från att lära sig information om krypterad data. Ingen av dem lyckas emellertid helt hindra en angripare från att manipulera med krypterad data.
Det är dock utan tvekan lättare att manipulera med en (odiffuserad) CBC-chiffertext än vad den är att manipulera med en XTS-ciphertext. Låt oss säga att en angripare råkar veta att något meddelande säger
”bla bla Ge Alice \ $ 400 … bla bla blah ”.
Om detta meddelande krypteras med CBC kan angriparen manipulera chiffertexten på ett sådant sätt att det nu kommer att dekrypteras till
”bla bla! ^% @ ^^ Ge Alice \ $ 800 bla bla bla”
$ 400 har blivit $ 800. Detta är vad ditt citat om ”AES-XTS hindrar en angripare från att ändra en specifik bit i en dataenhet” hänvisar till. Här skriver jag! ^% @ ^^ för att indikera att det tidigare 16-byte-blocket kommer att bli gibberish en gång dekrypterat, och detta gibberish kommer att ligga utanför angriparens kontroll.
Å andra sidan använder XTS förhindrar denna attack. Angriparen kan skada ett meddelande genom att förvandla alla 16-byte-block till slumpmässiga gibberish, men han kommer inte att kunna ha samma grad av kontroll som han gjorde i CBC-exemplet.
Men Microsoft bestämde sig för att inte använda XTS ändå. Anledningen är att förmågan att korrumpera ett 16-byte block fortfarande kan vara skadligt. Här är citatet från papperet dchest länkat:
Det kan till exempel finnas en konfigurationsfil (eller registerpost) med ett värde som, när den är inställd på 0, skapar ett säkerhetshål i operativsystemet. På disk ser inställningen ungefär ut som ”enableSomeSecuritySetting = 1”. Om början på värdet faller på en 16-byte-gräns och angriparen slumpmässigt släta textvärdet, finns det en $ 2 ^ {16} $ chans att de två första byten av klartext kommer att vara 0x30 0x00 vilket är en sträng som kodar ASCII-värdet 0.
(Detta citat hänvisar till den LRW-tweakable chiffer, men XEX-justerbar chiffer som används i XTS har samma problem).
Lägga till en diffusor. Använda en diffusor är Microsft lösning på detta problem.Tanken här är att ”blanda” klartext innan det krypteras så att en angripare inte kan ändra \ $ 400 till $ 800 — att blanda sig i en del av krypteringstexten kommer att ändra nästan hela klartext, inte bara små delar av den.
Detta låter bra, men det är en fångst: Ingen vet faktiskt om Microsofts diffusor faktiskt är säker. Enligt min kunskap har den inte fått någon publicerad formell analys från kryptografer. Det betyder att du bör vara skeptisk till att lita på det. Microsoft erkänner detta:
På nackdelen är diffusorn en ny oproven algoritm, och detta leder oundvikligen till frågor. Utan omfattande offentlig granskning och analys av en algoritm finns det en berättigad skepsis om dess säkerhet. Människor är ovilliga att lita på nya algoritmer. Så varför valde vi det här alternativet ändå? I vår slutanalys bestämde vi oss för att detta var det bättre valet för vår produkt. Prestationsvinsten jämfört med alternativen var tillräckligt viktig för att uppväga nackdelarna med en ny diffusoralgoritm. Tiden kommer att avgöra om vi valde rätt.
Slutsatsen. XTS är mindre smidigt än odiffuserad CBC. CBC + Diffuser är emellertid troligtvis mindre smidbar än XTS, åtminstone för praktiska ändamål.
En viktig sida. Varken CBC eller XTS var utformade för att vara icke formbara. Att säkerställa att ciphertexts inte manipuleras är ett separat problem, ett problem som ska lösas med hjälp av Message Authentication Codes (MACs), till exempel HMAC-SHA256. Anledningarna till att MAC inte vanligtvis används för krypteringsalgoritmer med full disk är (1) prestandaproblem och (2) att använda en MAC kräver att extra information lagras i krypteringstexten, vilket gör att det är lite svårt att lägga till det transparent.
En mellanväg mellan MAC och diffusorer skulle vara att använda ett krypteringsläge med stort block, som CMC, EME eller HEH. Du kan tänka dig att de har en ”inbyggd” diffusor, som gör dem icke formbara. Till skillnad från Microsofts diffusor har dessa algoritmer formella säkerhetsdefinitioner och peer-reviewed matematiska bevis. De är säkra under antagandet att AES är säkert. Microsoft valde att inte använda dessa på grund av (1) prestandaproblem och (2) patent.
Kommentarer
- I samband med skivkryptering enkel MAC: er är ' inte tillräckligt bra. Du ' behöver hashtree med en autentiserad root.
- tack för det här fantastiska svaret !!! detta gjorde allt klart … 5 *****
- Förmodligen vann detta ' t, men vann ' t problemet med smidbarhet löses genom att kryptera samma data två gånger med olika lösenord och / eller olika algoritmer? Så istället för att använda oproven diffusoralgoritm, varför inte använda beprövad AES igen?
- @Yura Det beror på hur AES används (till exempel XTS är vanligtvis byggt ovanpå AES). Om du använder CTR-AES-läget två gånger blir resultatet inte ' t mindre smidigt (att vända lite i ciffertexten vänder fortfarande motsvarande bit i klartext). Om du använder CBC-AES-läget två gånger kan du fortfarande göra samma attack som jag nämnde i mitt svar, men längden på det okontrollerade slumpmässiga " soporna " avsnittet kommer att fördubblas. Slutligen skulle det vara ungefär lika snabbt att använda AES i ett säkert " wideblock " -läge. Så kan lika gärna göra det istället.
- Uppdatering: Windows 10 ger möjlighet att använda XTS-läge. Ännu större / sämre uppdatering: I Windows 8 TA BORT Microsoft diffusorn. Så windows 8 bitlocker har inte ' t ens diffusorn.
Lämna ett svar