Miért ne használnám ' t az EKB titkosítását?
On február 18, 2021 by adminA Java-t használom titkosított karakterláncok előállításához, és ezt a figyelmeztetést az elkészítéskor kapom:
Az EKB titkosítási módot nem szabad használni
Szóval kíváncsi vagyok, miért ne használhatnám az EKB-t és mit használhatnék helyette ?
Megjegyzések
- A hozzászólások nem bővebb beszélgetések; a beszélgetést csevegésbe helyezték .
- Nagyítással dolgozik?;)
Válasz
Miért ne használjam az EKB titkosítást?
A EKB mód titkosításának legfőbb oka az, hogy nem szemantikailag biztonságos — vagyis pusztán az EKB által titkosított titkosított szöveg megfigyelése szivárogtathat információkat a sima szövegről (még a hosszán is túl, amely minden önkényesen hosszú táblázatot elfogadó titkosítási séma szivárog valamilyen mértékben).
Specifikus Az EKB móddal az a probléma, hogy az egyszerű (8 vagy 16 bájtos, vagy bármekkora az alapul szolgáló rejtjel blokkmérete) sima szöveges szöveg titkosítása az EKP mód használatával mindig ugyanazt a titkosítási blokkot adja. Ez lehetővé teheti a támadók számára, hogy:
- észleljék, hogy két EKB által titkosított üzenet azonos-e;
- észleli, hogy két EKB által titkosított üzenet közös előtaggal rendelkezik-e;
- annak észlelése, hogy két EKB által titkosított üzenet osztozik-e más közös alszövegekben, mindaddig, amíg ezek az alsorok a blokkhatárokhoz vannak igazítva; vagy
- annak felismerése, hogy (és hol) tartalmaz-e egyetlen EKB-titkosított üzenet ismétlődő adatokat (például hosszú szóközök vagy null bájtok, ismétlődő fejlécmezők vagy véletlenszerűen ismétlődő kifejezések a szövegben).
Ennek a gyengeségnek a szép grafikus bemutatása a Wikipédián, ahol ugyanazt a (nyers, tömörítetlen) képet titkosítják mind az EKB mód, mind pedig az szemantikailag biztonságos titkosítási mód (például CBC, CTR, CFB vagy OFB):
Bár ez a forgatókönyv kissé mesterséges (az ilyen nyers képeket általában nem titkosítanák), szépen bemutatja az EKB mód problémáját: a bemeneti kép ismétlődő területei ismétlődő mintákat eredményeznek a titkosított kimenetben, így a kép számos nagyszabású jellemzője a titkosítás ellenére is felismerhető marad. A való világban az EKB-t támadó kriptanalitikus alapú titkosítás A rendszer nagyobb valószínűséggel keresi az ilyen mintákat a rejtjeles szöveg hexadecimálisában, de az elv ugyanaz.
Az EKB titkosításának gyengesége, amely hozzájárul a valós adatok kompromisszumához, valójában adta a 2013-as Adobe jelszó-adatbázis szivárgás , az ebben a válaszban leírtak szerint. Itt a szivárgás súlyosságának egyik eleme az volt, hogy a megfelelő hashelés helyett az Adobe az EKB módban titkosította a jelszavakat. Ez lehetővé tette a támadók számára, hogy gyorsan megtalálják a több fiók által megosztott jelszavakat, vagy közös előtagot osszanak meg más jelszavakkal (például jelszó1 és jelszó2 ), és felfedte az egyes elemek hozzávetőleges hosszát. jelszó.
Az EKB titkosítási módnak vannak más gyengeségei is, például az, hogy “nagyon alakítható : mivel mindegyik a sima szöveg blokkja külön titkosítva van, a támadó könnyedén létrehozhat új érvényes rejtjeleket, ha a korábban megfigyelt kódokból blokkokat oszt össze.
A alakíthatóság azonban csak akkor kérdés, ha az EKB titkosítást üzenet hitelesítési kód , és ebben a helyzetben (bizonyos mértékig) az összes többi nem hitelesített titkosítási mód , mint a fent említett CBC, CTR, CFB és OFB. Tehát nem igazán tekinthető az EKB módjának sajátos gyengeségének, pedig általában kiegészítő kérdés, amikor valaha az EKB módot használják.
Mit használjak helyette?
Használjon bármilyen hitelesített titkosítást mód, például GCM , EAX vagy OCB .
Rövid üzenetekhez személy szerint inkább a SIV módot szeretem ( RFC 5279 ), amely egy extra rendellenes felhasználási ellenállást biztosít. (Sok más titkosítási mód meglehetősen rosszul fog megszakadni, ha ugyanazt az IV / nonce-t véletlenül használják több üzenet titkosításához. A SIV mód ebben a helyzetben megtartja az összes biztonsági tulajdonságát, kivéve, ha kiszivárog, hogy a titkosított üzenetek megegyeznek-e.)
Használhat bármilyen hagyományos szemantikailag biztonságos titkosítási módot is (például CBC vagy CTR ), üzenet hitelesítési kóddal (például HMAC ) kombinálva a titkosítással -akkor-MAC konstrukció. (Vagyis először meg kell titkosítania az üzenetet, majd ki kell számítania a titkosított szöveg MAC-ját, és hozzá kell fűznie a titkosított szöveghez.) Amíg az üzenet visszafejtésének megkísérlése előtt ellenőriznie kell a MAC-t, addig ez a konstrukció megvédi Önt ezeknek a módoknak a különféle sebezhetőségei az aktív (selected-ciphertext) támadásokkal szemben.
lemezes titkosításhoz vagy hasonló alkalmazásokhoz, amelyekhez részek módosítása szükséges A titkosított szöveg újbóli titkosítása nélkül használjon egy erre a célra tervezett titkosítási módot, például XTS . Ne feledje, hogy az ilyen módok általában nem rendelkeznek ellenállással az aktív támadásokkal szemben, és más gyengeségeik is lehetnek, amelyeket meg kell érteni a használatuk előtt. Lehetőség szerint kombinálni kell őket az integritásvédelem valamilyen formájával, például egy hash fa MAC-jával .
Megjegyzések
- Mit javasolna azokban az esetekben, amikor egy adattár blokkjait tetszőleges sorrendben szeretné olvasni / írni, lehetőleg mindet blokktérkép készítésével blokkolják? Hajlamom az lenne, ha titkosítanék a blokkadatokat a blokkszám nagyon egyszerű hashjával xorozva, az xor művelet visszavonásával / megismétlésével, ha mindez blokkot eredményez, az eredményen az EKB-t használva, és xorozva az eredmény kiegészítésével egy all-one blokk titkosításához [ezt a kiegészítést minden kulcshoz csak egyszer kell kiszámítani]. Ez jó megközelítésnek tűnik?
- @supercat: Ez ' alapvetően lemez titkosítás , így használhatná az erre tervezett módokat. Úgy gondolom, hogy az XTS-t jó választásnak tekintik, bár, mint minden lemez titkosítási mód, ennek is megvannak a maga korlátai (amelyeket érdemes megértenie a használat előtt). Ha lehetséges, össze kell kapcsolni valamilyen MAC-mal az aktív támadások elleni védekezés érdekében.
- @IlmariKaronen: azt hiszem, mondván: " don ' az EKB használata " kissé túlzott. Megértem a kockázatokat, de sokszor (kivéve, ha a titkosított dokija – nem nagyon titkos, és az ellenfél nem ' nincs túl sok képessége stb.), akkor rendben kell lenned.
- @giorgim: Ott ' nincs igazán jó ok az EKB használata (kivéve építőelemként más módokhoz). Nagyjából minden kriptográfiai könyvtár legalább CBC vagy CTR módot biztosít, és ha nem, akkor ' elenyésző, hogy megvalósítsd magad. Pofítson rá egy HMAC-ot (vagy CMAC-ot), és ' jó lesz.
- @giorgim: Akkor is, ha nem ' nem áll rendelkezésre semmilyen MAC vagy AE mód, a CBC használata továbbra is szigorúan jobb, mint az EKB. Ha van MAC funkciója, akkor a CBC-then-MAC tökéletesen jó AE mód.
Válasz
Ne használja az EKB módot, mert azonos üzenetblokkokat (azaz a blokk-titkosítás minden meghívásakor titkosított adatmennyiséget) azonos titkosított szöveges blokkokhoz fog titkosítani. Ez azért probléma, mert kiderül, ha ugyanazokat az üzenetblokkokat többször is titkosítják. A Wikipedia nagyon szépen szemlélteti ezt a problémát .
Megjegyzések
- Megjegyzések nem folytatnak kibővített vitát; ez a beszélgetés csevegésbe került .
Válasz
Ahogy @Guut Boy megemlítette, az EKB nem szemantikailag biztonságos abban az értelemben, hogy ha egy azonos blokkokkal ellátott üzenet titkosítva van, akkor a támadó bizonyos előnyt kap, hogy a sima szöveggel kapcsolatos információval rendelkezik, csak a CipherText megfigyelésével.
Használjon előnyösen CBC módot a hosszú üzenetek titkosításához. Ez az üzemmód egy további paramétert vezet be, az úgynevezett IV (kezdeti érték) értéket, amelyet a munkamenet számával inicializál, hogy megakadályozza a támadásokat abban az esetben, ha ugyanazt az üzenetet kétszer titkosítja.
Megjegyzések
- A IV az inicializációs vektort jelenti, nem a kezdeti értéket.
- 1. Ez nem jó tanács. Titkosítás használata anélkül a hitelesítés figyelmen kívül hagyja a kriptográfusok egy évtizedes tanácsát. Jobb lenne hitelesített titkosítást használni, ahogy Ilmari Karonen javasolja. 2. Úgy tűnik, hogy ezt a választ Ilmari Karonen ' s helyettesíti válasz.
- Emellett tény, hogy a IV-nek kiszámíthatatlannak kell lennie egy támadó számára (azaz nem különböztethető meg a véletlenszerűtől), és ez a válasz azt mondja, hogy használja a munkamenet számát, amely általában egyáltalán nem véletlenszerű.
Vélemény, hozzászólás?