A jelszó alapú titkosítás eredendően kiszolgáltatott a szótár támadásainak. Valóban, ha megvan a titkosított fájl, akkor mindig megpróbálhatja visszafejteni (vagy annak egyes részeit) egy adott jelszóval, és megnézheti, van-e értelme az eredménynek. Így egy támadó, aki kezébe kerülhet a titkosított fájl (és feltételezzük, hogy ez lehetséges, mivel különben nincs értelme a titkosításnak), "megpróbálhatja a jelszavakat" a saját gépén, amíg egyezést nem találnak. Meg kell jegyezni, hogy a támadónak nincs szüksége 100% -osan megbízható tesztre az "értelme az eredménynek" részhez: ha a támadó tesztje elegendő a rossz jelszavak 99,9999% -ának elutasításához, akkor a jelszavak listáját mégis kétszer ellenőrizte egymilliószorosával.

Az, hogy egy olyan eszköz, mint a ccrypt tesztet nyújt a rossz jelszavak elutasítására, nem változtat ezen a tényen. Persze, a támadó ezután is használhatja a tesztet, de ez nem jelent neki különösebb előnyt. A támadó már kényelmesen dolgozhatna anélkül, hogy ezt a tesztet elvégezné, mert a valós adatok sok felépítésűek (a legtöbb fájlformátum nagyon jól felismerhető fejlécekkel rendelkezik), és ha a támadó érdekelt a jelszó feltörésében, akkor az adatoknak értékeseknek kell lenniük, tehát "valósaknak" -life ".

Két módszerrel erősítheti a jelszó alapú titkosítást; kumulatívak, és mindkettőt használniuk kell. Az első módszer egy erős jelszó használata, amely sok véletlenszerűséggel rendelkező jelszót jelent (a szokásos módon lásd a témáról folytatott megbeszéléseket ebben a kérdésben). A második módszer az, hogy a jelszót titkosítási kulcsgá alakítja át egy jó, megfelelően konfigurált jelszó-kivonatoló funkcióval; a "megfelelő konfiguráció" azt jelenti, hogy egy sót használnak a párhuzamos támadások megakadályozására (amikor több, külön jelszóval ellátott titkosított fájl van, és a támadó egy vagy többet meg akarna szakítani), és hogy a jelszó kivonási funkció megtörténik szándékosan drága sok iteráción keresztül, hogy megnehezítse a szótári támadásokat.

Az utóbbi ponton a ccrypt hibásnak tűnik. Hamisítja a jelszót azzal, amit a GYIK leír:

A Ccrypt AES-en alapuló (azaz a Rijndael blokk-rejtjelen) kivonatoló algoritmust használ. Nem tartozik a szokásos hash algoritmusok közé, mint például az SHA1. Így az alkalmazásodhoz rendben kell lenned. A biztonság szempontjából nem sokat számít, hogy melyik kivonatoló algoritmust használják, amennyiben ütközésmentes.

ami nem sok jót ígér. Először is, a szerző saját szavával, egy egyedi házi készítésű funkció, amely soha nem jó jel. Ezenkívül a szerző arról beszél, hogy a funkciónak "ütközésmentesnek" kell lennie, ami teljesen lényegtelen a jelszóalapú kulcsok levezetése szempontjából, és így jelzi az ilyen dolgok követelményeinek viszonylag rossz megértését; ez sem jó jel, főleg ha házi készítésű funkcióval kombináljuk.

A forráskódot nézve (ez az a kedves dolog az opensource-nál: magad is meggyőződhetsz arról, amit a szerző nem látott megfelelőnek a dokumentáláshoz) ), úgy tűnik, hogy az egyéni kivonat a következő módon működik: 0x00.

Ehhez a következő megjegyzések szükségesek:

• A GYIK szerint" AES "van, de nem AES. Az AES egy három funkcióból álló család, amely a Rijndael néven ismert funkciócsalád részhalmaza. Az AES mindig 128 bites blokkokat használ; itt a Rijndaelt 256 bites blokkokkal használják, tehát nem AES stricto sensu .

• Hash függvényként szívás. A folyamat lényegében egyetlen blokk ismételt titkosítását jelenti, minden egyes alkalommal 256 lehetséges kulcs felhasználásával (az egyes titkosítási kulcsok 32 bájtja mindig megegyezik egymással). Mivel ez szimmetrikus titkosítás, a szimmetrikus visszafejtés is működik, ami lehetővé teszi a találkozást a középen történő támadást. Alapvetően a kimeneti méret 256 bit, de a preimage ellenállás legfeljebb 2 ¹²⁸ , nem pedig 2 ²⁵⁶ ; bár ez nem jelenti a jelszó-kivonás közvetlen problémáját, mégis megmutatja az egyéni sémák alapvető hibáját.

• Jelszó-elosztó funkcióként büdös . Nem csak sótlan, de rendkívül gyors is. Az alap PC-vel rendelkező támadó az AES-NI utasítások alapján kiszámítja a Rijndael titkosítást néhány tucat óraciklus alatt (az AES-NI utasítások kifejezetten az AES-t támogatják, de ezek továbbra is felhasználható a 256 bites blokkok hatékony támogatásához; lásd ennek a cikknek a 2.1. szakaszát). Sőt, mivel a jelszó byte-ok egyenként vannak feldolgozva, a számítási költségek nagy része megosztható az egymást követő jelszó-próbák között: a "foo" hash jelszóból, a "fooA", "fooB", "fooC" hash-okból. .. kiszámítható egy-egy Rijndael-256 meghívással.

  Becslések szerint egy olcsó, polcos PC legalább 100 millió millió hash-ra képes em> potenciális jelszavak másodpercenként. Nagyon kevés, az ember által választott jelszó ellenáll egy ilyen támadásnak, legfeljebb pár percnél tovább. Ami a jelszó kivonását illeti, ez szörnyű.

Összefoglaló: a ccrypt indokolatlanul gyenge a szótárak támadásai ellen, de nem azért, mert teszteli a jelszó helyességét. Gyenge, mert a jelszó-elosztási eljárás egy házi készítésű konstrukció, amely hibákat halmoz fel, ami rendkívül hatékonyabbá teszi a szótári támadásokat. Megfelelően konfigurált jelszó-kivonó funkcióval (pl. bcrypt) szó szerint milliószor erősebbé tehetné (az iterációs számot úgy állítanák be, hogy egy számítógép 100 helyett csak 100 jelszót hasíthasson el 100 helyett) millió; ez még mindig nagyon használatos lenne, mert a másodperc 1/100 része nem nagy késleltetés emberi értelemben).

Eredeti válasz, amely elmagyarázza, hogy a ccrypt nem használ sót, nem használ valódi AES-t és nem használ szabványos KDF-et: https://www.mathstat.dal.ca/~selinger/downloads/ccrypt- answer.txt

A ccrypt szerzője vagyok. Sajnálom, hogy ilyen későn válaszoltam erre a témára, de csak a közelmúltban értesültem róla. Mint mindig, a titkosítással kapcsolatos kérdések is rám irányíthatók (és valószínűleg gyorsabb választ fognak kapni) a SourceForge-on található ccrypt fórumokon.

Az eredeti kérdés megválaszolásához: hadd mondjam meg egyértelműen, hogy a titkosítás, minden más mellett jelszó alapú titkosító program, durva erőszakos támadásoknak van alávetve, beleértve a szótári támadásokat is. Ahogy ThomasPornin találóan megfogalmazta: "A jelszó alapú titkosítás eredendően sebezhető a szótári támadások számára". Semmi sem akadályozza meg a támadót abban, hogy minden lehetséges jelszót megadjon. Ez nem hiba, hanem az élet alapvető ténye, és amelyet a kriptográfia minden felhasználójának meg kell értenie. Ha gyenge jelszót használ, például "uszkár", akkor a támadó képes lesz kitalálni a jelszavát és visszafejteni az adatait. Ha olyan erős jelszót használ, mint a "hVztmdz28fNemDZnxj5YLjXz", akkor az adatai a belátható jövőben a jelenlegi ismeretek legjobbak szerint biztonságban maradnak. a válaszok és megjegyzések.

Az eredeti bejegyzésben látszik, hogy félreértés van a whatccrypt helyettesítője kapcsán. Ez valószínűleg annak tudható be, hogy a dokumentáció ezen részét sokáig nem frissítettem. Amikor Iwrote (2001-ben), hogy a ccrypt a régi unixcrypt program helyettesítője, a crypt (1) programra utaltam, nem pedig a crypt (3) library funkcióra. A Crypt (1) egy jelszó alapú fájlkódoló program volt, amely legalább 1979 óta létezik a Unixban (a 7. verzióban volt: http://man.cat-v.org/unix_7th/1/crypt ), és jól ismert volt az 1980-as és 1990-es években. Egy közismerten weakalgorithmust használt az Enigma rejtjel alapján, amelyet már megtörtek Második világháború. Másrészt a crypt (3) egy olyan könyvtárfunkció, amely a jelszavakat az / etc / password formátumban használja. Tudomásom szerint a (3) kriptával nincs különösebben baj, és ma is használatos. A Ccrypt (1) a crypt (1) helyettesítője, nem a forcrypt (3). Nincs értelme megkérdezni, hogy a ccrypt "jobb", mint a crypt (3), mivel teljesen más dolgokat csinálnak. Valószínűleg frissítenie kell a dokumentáció ezen részét, tekintettel arra, hogy szerencsére senki sem emlékszik ma a crypt (1) programra.

Az eredeti bejegyzés kérdést vet fel azzal kapcsolatban is, hogy a ccryptwill tájékoztatja a felhasználót, ha rossz jelszót írtak be , és hogy ez gyorsabbá teszi-e a szótár támadásokat. A válasz az, hogy ez nem teszi gyorsabbá a szótár támadásokat, kivéve talán egy kis állandó tényezőt. Thomas ezt már válaszában jól elmagyarázta, de csak a lényeg hangsúlyozása érdekében vegye fontolóra ezt: tegyük fel, hogy a titkosított fájl JPEG fájl. Minden JPEG fájl ugyanazon 3 bájttal kezdődik, nevezetesen ff d8 ff. Tehát már létezik egy nagyon egyszerű teszt a kulcs valószínű helyességének ellenőrzésére: csak dekódolja az első blokkot, és ellenőrizze, hogy a fájl ff d8 ff kezdetű-e. A legtöbb más fájlformátum is tartalmazza ezt a típusú ismert sima szöveget, például minden PDF fájl "% PDF" -vel kezdődik. Azt is könnyű ellenőrizni, hogy a fájl egyszerű szöveges fájl-e. Tehát az a tény, hogy a ccrypt biztosítja a jelszóillesztési funkciót, nem teszi könnyebbé a támadásokat, mint általában. Ami azt illeti, a ccrypt "megfelelő" kulcs ellenőrzése szintén nem 100% -os pontos. 1/4 milliárd esély van arra, hogy bármelyik véletlenszerű kulcs átmegy a teszten, még akkor is, ha ez nem a megfelelő kulcs. A funkció azért van, hogy megakadályozza az embereket abban, hogy véletlenül megfejtik a fájlokat egy rossz kulccsal (és ezzel felülírják a benne lévő összes adatot szeméttel).

Összefoglaló: Mint minden jelszó alapú titkosító szoftver, a ccrypt szótár támadások tárgya. A felhasználóknak tisztában kell lenniük ezzel és választaniuk kell erős jelszavak. Viszont kontraproduktív lenne, ha a jelszavak bizonytalanságát csak kissé kevésbé bizonytalanná tennénk, ha a támadások költségeit állandó tényezővel növelnénk, amint az javasolt. Ehelyett az egyetlen helyes válasz arra, hogy először biztonságos jelszavakat használjon. A Thomas Pornin válaszában bemutatott további elemzések nagy része hibás, és a ccrypt tényleges gyengeségeit nem fedezték fel.