Mi az XTS előnye a CBC móddal szemben (diffúzorral)?
On november 30, 2020 by adminVan néhány problémám az AES-XTS “előnyének” megértésében a diffúzorral ellátott CBC-hez képest.
Olvastam valamit a FileVault , ebben a cikkben megemlítik az XTS és a CBC két műveleti módját (diffúzorral) és az XTS előnyeit.
Mindkét mód titkosítja adategységek szinte ugyanúgy. A CBC esetében a szektorszámot valamilyen módon használják az IV felépítéséhez, az XTS-hez van egy “csípési érték”, amely magában foglalja (valahogy) a blokkeltolást is, így minden egyes adatblokk függetlenül titkosítható (van értelme merevlemezek titkosításakor / partíciók). Nem igazán látom az XTS előnyeit.
Most a következőket írják az XTS-ről:
Számos előnye van az alternatívákkal szemben mint például AES a CBC-ben: nincs szükség inicializációs vektorra (a csíptetési kulcs a blokkszámból származtatható); minden blokk másképpen van titkosítva (mivel a csípés értéke más lesz); és az AES-CBC-vel ellentétben az AES-XTS megakadályozza a támadókat abban, hogy egy adategységben megváltoztassanak egy adott bitet, azáltal, hogy az egyes AES bemeneteket a titkosított csípés másik eltolt verziójával készítik el.
Talán csak összehasonlítják az XTS-t a CBC-vel (diffúzor nélkül) … ha igen, tudja-e valaki az XTS előnyeit?
És meg tudja magyarázni valaki a második előnyt: “AES- Az XTS megakadályozza a támadókat abban, hogy egy adategységben megváltoztassanak egy adott bitet, azáltal, hogy az egyes AES bemeneteket a titkosított csípés másik eltolt változatával készítik el. “?
Megjegyzések
- Mi ' s " diffúzor "? " a szektor száma valahogy " hogyan? Nem ' nem írtad le világosan a sémát. Ha az algoritmus kiszámítható, ez gyengeségekhez vezet, és egy kiszámíthatatlan algoritmus drága.
- @CodesInChaos szerintem a hivatkozás a Microsoft ' s Elephant diffúzorra vonatkozik. a BitLockerben ( download.microsoft.com/download/0/2/3/… – figyelmeztetés: PDF-fájlok letöltése ).
- Üdvözöljük a Cryptography Stack Exchange szolgáltatásban. Kérdését azért költöztettük ide, mert nem kapcsolódik közvetlenül a szoftverfejlesztéshez (a Stack Overflow témaköréhez), és itt inkább a téma. Kérjük, itt is regisztrálja fiókját, hogy kommentelhessen és elfogadhassa a választ.
Válasz
XTS és nem diffúzált CBC. A kérdés itt a alakíthatóság . Az XTS és a CBC egyaránt megakadályozza a támadókat abban, hogy információkat szerezzenek a titkosított adatokról. Egyiknek sem sikerül azonban teljesen megakadályozni, hogy a támadók manipulálják a titkosított adatokat.
Azonban vitathatatlanul könnyebb egy (nem diffúzált) CBC titkosítási szöveget manipulálni, mint manipulál egy XTS rejtjelszöveget. Mondjuk azt, hogy a támadó véletlenül tudja, hogy valami üzenet azt mondja, hogy
“bla bla Adj Alice-nek 400 dollárt … bla bla blah “.
Ha ezt az üzenetet a CBC titkosítja, a támadó úgy manipulálhatja a rejtjelszöveget, hogy mostantól visszafejteni
“bla bla! ^% @ ^^ Adj Alice-nek 800 dollárt bla bla bla”
A 400 dollárból 800 dollár lett. Erre utal az “AES-XTS megakadályozza a támadót abban, hogy egy adategységben egy adott bitet megváltoztasson” című idézete. Itt azt írom! ^% @ ^^, hogy jelezzem, hogy az előző 16 bájtos blokk visszafejtéssé válik, és ez a hamisítás meghaladja a támadó befolyását.
Másrészt, az XTS használatával megakadályozza ezt a támadást. A támadó megsérthet egy üzenetet úgy, hogy bármely 16 bájtos blokkot véletlenszerű zaklatássá változtatja, de nem lesz képes ugyanolyan mértékben irányítani, mint a CBC példában.
De A Microsoft úgy döntött, hogy nem használja az XTS-t. Ennek az az oka, hogy a 16 bájtos blokk megrongálásának képessége még mindig káros lehet. Itt van a papír dchest linkje:
Lehet például egy konfigurációs fájl (vagy nyilvántartási bejegyzés), amelynek értéke 0-ra állítva biztonsági lyukat hoz létre az operációs rendszerben. A lemezen a beállítás úgy néz ki, mint “enableSomeSecuritySetting = 1”. Ha az érték kezdete egy 16 bájtos határra esik, és a támadó véletlenszerűen randomizálja a sima szöveg értékét, akkor $ 2 ^ {16} $ esély van arra, hogy az első két bájt A sima szöveg értéke 0x30 0x00 lesz, amely egy karakterlánc, amely a „0” ASCII értéket kódolja.
(Ez az idézet az LRW módosítható titkosításra vonatkozik, de az XTS-ben használt XEX módosítható titkosításnak ugyanaz a problémája).
Diffúzor hozzáadása. Használat a diffúzor a Microsft megoldása erre a problémára.Az ötlet az, hogy a sima szöveget a titkosítás előtt “összekeverjük”, hogy a támadó ne változtathassa meg a 400 dollárt 800 dollárra – ha a titkosítási szöveg egy részébe keveredik, akkor az egész sima szöveget megváltoztatja, nem csak annak kis részeit.
Ez jól hangzik, de van egy fogás: Senki sem tudja, hogy a Microsoft diffúzora valóban biztonságos-e. Tudomásom szerint a kriptográfusoktól nem kapott hivatalos publikációt. Ez azt jelenti, hogy szkeptikusnak kell lenned arra támaszkodni. A Microsoft ezt tudomásul veszi:
A hátrányos oldalon a diffúzor egy új, be nem bizonyított algoritmus, és ez óhatatlanul kérdéseket vet fel. Egy algoritmus átfogó nyilvános vizsgálata és elemzése nélkül indokolt szkepticizmus figyelhető meg az algoritmus biztonságával kapcsolatban. Az emberek nem szívesen bíznak az új algoritmusokban. Akkor miért választottuk ezt a lehetőséget? Végső elemzésünkben úgy döntöttünk, hogy ez a jobb választás a termékünk számára. Az alternatívákkal szembeni teljesítménynövekedés elég fontos volt ahhoz, hogy ellensúlyozza az új diffúzor algoritmus hátrányait. Az idő eldönti, hogy jól döntöttünk-e.
Az alsó sor. Az XTS kevésbé alakítható, mint a nem diffúzált CBC. A CBC + Diffuser azonban valószínűleg kevésbé praktikusan alakítható, mint az XTS.
Fontos szempont. Sem a CBC-t, sem az XTS-t nem úgy alakították ki, hogy ne legyenek alakíthatók. Külön probléma, hogy a rejtjelezési szövegeket nem manipulálják, amelyet az üzenet-hitelesítési kódok (MAC), például a HMAC-SHA256 használatával kell megoldani. Az okok, amelyek miatt a MAC-okat nem szokták használni a teljes lemezes titkosítási algoritmusoknál, (1) teljesítményproblémák, és (2) egy MAC használata további információk tárolását igényli a rejtjelszöveg mellett, ami átlátható módon kissé bonyolulttá teszi.
A MAC-k és a diffúzorok közötti középutat az jelentené, ha széles blokkú titkosítási módot használnánk, például CMC, EME vagy HEH. Ezeket úgy gondolhatja, hogy “beépített” diffúzorral rendelkezik, ami miatt nem alakíthatók. A Microsoft diffúzorától eltérően ezek az algoritmusok hivatalos biztonsági definíciókkal és szakértői szakértők által felülvizsgált matematikai bizonyítékokkal rendelkeznek. Biztonságban vannak, feltéve, hogy az AES biztonságos. A Microsoft úgy döntött, hogy nem használja ezeket (1) teljesítményproblémák és (2) szabadalmak miatt.
Megjegyzések
- A lemezes titkosítás összefüggésében egyszerű A MAC-ek ' nem elég jók. ' hitelesített gyökérrel rendelkező hashtree-re lesz szüksége.
- köszönöm ezt a remek választ !!! ez mindent világossá tett … 5 *****
- Valószínűleg ez nem nyert ' t, de nyert ' t a alakíthatóság problémáját úgy lehet megoldani, hogy ugyanazokat az adatokat kétszer ecrrypteljük különböző jelszavak és / vagy különböző algoritmusok segítségével? Tehát a bizonyítatlan diffúzor algoritmus helyett miért használhatná újra a bevált AES-t?
- @Yura Ez attól függ, hogy miként használják az AES-t (például az XTS általában az AES tetejére épül). Ha kétszer használja a CTR-AES módot, akkor az eredmény nem lesz ' kevésbé alakítható (a titkosító szövegben egy kicsit elfordítva a megfelelő bitet átírja a sima szövegben). Ha kétszer használja a CBC-AES módot, akkor is megteheti ugyanazt a támadást, amelyet a válaszomban említettem, de az ellenőrizetlen véletlen " szemét hossza " szakasz megduplázódik. Végül az AES használata biztonságos " wideblock " módban egyébként nagyjából olyan gyors lenne, mint ezek a megoldások. Tehát ezt is megteheti helyettük.
- Frissítés: A Windows 10 biztosítja az XTS mód használatának lehetőségét. Még nagyobb / rosszabb frissítés: Windows 8 rendszerben a Microsoft eltávolította a diffúzort. Tehát a Windows 8 bitlocker ' még a diffúzort sem rendelkezik.
Vélemény, hozzászólás?