Mennyire nem biztonságos az AES-128-CTR bármilyen adat titkosítása az Ethereum kulcstár fájlformátumának használatával?
On november 18, 2020 by adminAz Ethereum kulcstárfájl-formátumát használom más adatok, például sima szöveg vagy JSON, titkosításához.
Íme egy példa a megvalósítás álkódja:
MY_PASSWORD = "VeryDifficultPasword432131!@!#%" MY_TEXT = "This is my secret text" iv = randomBytes(16) kdfparams = { dklen: 32, n: 262144, r: 1, p: 8, salt: randomBytes(32) } key = scrypt(MY_PASSWORD, kdfparams) ciphertext = encryptCipheriv("aes-128-ctr", MY_TEXT, key, iv) mac = sha3(key[16:32], ciphertext)
Ezzel a kóddal létrehozhatom a következő kulcstároló fájlt:
{ "crypto" : { "cipher" : "aes-128-ctr", "cipherparams" : { "iv" : "83dbcc02d8ccb40e466191a123791e0e" }, "ciphertext" : "d172bf743a674da9cdad04534d56926ef8358534d458fffccd4e6ad2fbde479c", "kdf" : "scrypt", "kdfparams" : { "dklen" : 32, "n" : 262144, "r" : 1, "p" : 8, "salt" : "ab0c7876052600dd703518d6fc3fe8984592145b591fc8fb5c6d43190334ba19" }, "mac": "102aedfe8c308c735a76295f9908d9b7de40fb1c07f2f71e05de7a0b2f323a12" } }
Ez az a standard fájl, amely dollármillió embert tárol Ethersben.
Kérdések:
- Ez biztonságos?
- Ha nem, akkor miért?
- Ha igen, akkor a sima szöveg vagy a JSON biztonságos titkosítása is (nincs hexadecimális formátum)?
- Biztonságos kisebb
kdfparams.n
?
Szerkesztés: Annak tisztázása, hogy miért kérdezem, mert egy másik személy ezt mondta:
Ez egyáltalán nem biztonságos. Ez a megvalósítás sok alapvető hibát tartalmaz. Az egyik példa egy nem biztonságos véletlenszám-generátor használata, amely teljesen megsemmisíti a titkosítás biztonságát. Egy másik az AES- 128-CTR hitelesítés nélkül.
Megjegyzések
- Először határozza meg a ” biztonságos ” . De ennek bármilyen ésszerű meghatározása szerint, egy jelszóval ugyanabban a ligában, mint a ‘ 1234 ‘, és az ilyen nagy és felesleges szöveg, semmi használható nem biztonságos.
- Biztonságos nagyon nehéz megtörni akkor is, ha van jó kriptográfus Az et me szerkesztéssel tisztázzuk, hogy ez nagyon erős jelszó lenne.
- Most adjon meg ” break ” . Megtalálja az eredeti jelszót? Kitalálni a sima szöveget egy rejtjelből? Kitalálod a sima szöveg megosztását a sok rejtjeles szöveg megosztásából, hogy néhányat? Kitalálod az egyik sima szöveget a sok rejtjeles szövegből és az összes más sima szöveget? Kaphatunk-e segítséget egy ugyanazon a gépen futó futtatható programtól (és ha igen, pontosan milyen CPU-t és milyen mikrokódos javítást használunk? Használjuk az AES-NI-t?). Használhatjuk az EMI-t mellékcsatornaként? Keylogger, hardver vagy sotfare? Valóban, mi ‘ s a randomBytes megvalósítása, amelynek van befolyása?
- Erre a kérdésre nem válaszolhat a psuedocode áttekintésével. A tényleges megvalósítás mindenféle sebezhetőséget és mellékcsatornákat tartalmazhat. A biztonság szintén nem bináris, ‘ fontos, hogy meddig hajlandó ‘ menni, hogy megvédjen az újabb és újabb egzotikus támadások .
- @ fgrieu sajnálom, az egyetlen kérdésre, amire válaszolhatok: nodejs.org / api / … @EllaRose Feltételezem, hogy az általam használt könyvtárak nem rendelkeznek sebezhetőséggel. Tehát a fenti álkódom csak a könyvtár függvények megvalósítása, ilyen randomBytes.
Válasz
A legrosszabb a pusztán kriptográfiai gyengeség a jelszó (1). A legsúlyosabb (és sokkal rosszabb) gyakorlati gyengeségek valószínűleg a megvalósításban vannak (6) (7), és azokban (4) (5), amelyeket a kriptográfusok elutasítanak, mint a titkosítás hatókörét (a kérdés csak megfogalmazott célja).
Jelölhetnek gyengeségekre, a kriptográfiától (de még mindig fontolóra kell venni) a megvalósításig:
- A jelszó: nehéz megjegyezni egy több mint 48 bites entrópiával rendelkező jelszót ( ez körülbelül egyenértékű egy 16 jegyű számmal, például a 3141592653589793 vagy a 2718281828459045, és több, mint amit a kötelező XKCD elképzel. Az N = 262144 = 2 18 , r = 1, p = 8 = 2 3 használatával legalább 18 + 3 + 1 = 22 bitet vásárol (lásd: ezt ) egy egyenes SHA-256 hash-hoz képest, amelyet az AES-128 követ, azt hiszem, körülbelül 32 bit erősebb, így a kulcs körülbelül 80 bites lehet, ami nem teljesen feltörhetetlen nyers erővel, de mégis meglehetősen biztonságos.
- AES-128: ennek 128 bites kulcsa van, nem ismert tisztán kriptanalitikus a támadás jobb, mint a nyers erő, és így sokkal jobb, mint a jelszó.
- CTR mód: Az AES 128 bites blokkjával a kulcsfolyam újrafelhasználásának egyetlen módja rossz véletlenszerű szám lehet generátor a IV-hez (lásd 6.)
- A sima szöveg mérete könnyedén levezethető a titkosított szöveg méretéből. Ez kifejezetten nem a titkosítás elméleti gyengesége, mivel a hossza ki van zárva abból, amit egy rejtjelnek el kell rejtenie a sima szöveggel kapcsolatban. Ez azonban gyakorlati gyengeség lehet. Mondjuk a rejtjelszöveg elemzésével arra a következtetésre jutunk, hogy 17267095423 oktett; és létezik, hogy az ügyészség valahol pontosan ekkora aktát állít ki, amely bizonyíthatóan megelőzte a titkosítás keresését és lefoglalását, és amely puszta őrizetbe vétele illegális.
- A (szándékos vagy véletlen) rejtjelszöveg-változások észlelésének hiánya, ami a sima szöveg kiszámítható változásának felel meg: ez megint kifejezetten nem a titkosítás elméleti gyengesége, de megengedhet néhány támadást ha az ellenfél megváltoztathatja a rejtjelszöveget (példa: ha a sima szöveg futtatható vagy ismert frakciójú PDF, akkor ez lehetővé teheti a futtatható fájl bármivel kapcsolatos megváltoztatását, vagy a PDF megjelenítését bármivel szemben). A Hitelesített titkosítás ( AES-GCM ..) megoldja ezt.
- Véletlenszám-generátor: ha ez rossz, vagy rosszabb, többé-kevésbé elakad (kötelező XKCD és Dilbert amelyek túl gyakran fordulnak a valóságba), ami sok esetben lehetővé tenné a sima szöveg helyreállítását, ideértve a különböző angol szöveg vagy e-mail címek ismételt titkosítását ugyanazzal a jelszóval.
- Oldalsó csatorna, amely nagyjából előre nem látható vagy nem szándékolt információszivárgás megszólalása a megvalósítás vagy a használat összefüggésében. Olyan sok van:
- Jelszó helyreállítása a jelszó birtokosától az eljárási tévedés kihasználásával (jelszó postit jegyzetben, fő jelszó lista), gumibetétes kriptanalízis (kötelező XKCD ), jogi változatok (beleértve a kifejezések használatát a bírósági megvetés n), megvesztegetés, kémiai impregnálás.
- Jelszó-helyreállítás vállszörfözés , kulcsnaplózó (szoftver vagy hardver), kamera, mikrofon (jó hangrögzítés a kulcsok hangja a jelszó megadásakor sok információt szivárog a jelszóról, különösen akkor, ha ugyanaz az operátor ismert billentyűzet-bejegyzésével azonos feltételek mellett áll fenn.
- A sima szöveg egyenes kompromisszuma a képernyőn látható módon ( TEMPEST ennek változatai), kinyomtatva, miközben továbbítják egy nyomtatóra vagy távolról hozzáférnek a hálózathoz, vagy csak “ideiglenesen” tárolják.
- A mach operációs rendszerének egyenes kompromisszuma titkosítást vagy visszafejtést végez (elég az ideiglenes gyökérhozzáférés, a 7.7-es eszközök a játékot jelentik a támadó számára).
- kriptanalitikus oldalsó csatorna távolságra, ideértve az DPA és a DEMA elektromágneses változata, valamint hipotetikusan időzítés , ha a titkosítást / visszafejtést végző géphez egy hálózat hozzáfér, és nem használja a AES utasítások .
- kriptanalitikus mellékcsatorna ugyanazon a hardveren (beleértve egy másik virtuális gépet is) futó folyamatból, beleértve az AES gyorsítótár-alapú célzását, ha nem használ AES-t utasítások, vagy általánosabbak (Meltdown, Spectre), amelyek manapság dühöngenek.
- Különböző szoftverhibák kihasználása; ez óriási.
Megjegyzések
- Hasznosabb lenne, ha kivonatolnám a jelszót a titkosítás előtt? Mint a sha vagy az md5 használata?
key = scrypt(sha(MY_PASSWORD), kdfparams)
- @EnZo: A jelszó hasítása a scryptbe történő bejegyzés előtt nem sokat változtat a jelszó támadásának nehézségén ( 1. pont. Ennek javításához jobb jelszóra, a scrypt jobb paraméterezésére vagy egy jobb jelszó alapú kulcs levezetési sémára (Argon? Balloon?) van szükség
Válasz
A fő séma, amely a fenti sémában megtámadható, természetesen a megfelelő kifejezés. Most a só fontos a szivárványos asztali támadások elkerülése érdekében, de egyébként nem ad annyi biztonságot. Ha a só és a jelszó ésszerűen egyedi, akkor a kulcs is egyedi. Ebben az esetben a IV nem olyan fontos.
Tehát bár a nem biztonságos véletlenszám-generátor használata rossz, valószínűleg nem lesz ekkora hatása a gyakorlati biztonságra. , ez azt jelzi, hogy valóban rossz gyakorlatokat telepítettek. Mi lenne, ha a jelszót ugyanazon nem biztonságos véletlen generátor segítségével generálták? Mi van, ha más megvalósítási hibák jelennek meg?
A nem hitelesített titkosított szöveg használata nagyobb problémát jelent, mivel lehetővé tenné, hogy az ellenfél megváltoztassa az egyes bitek egyszerű szövegét. Az ellenfél egyszerűen megfordíthat bármilyen titkosított bitet, és az ugyanabban a helyzetben lévő egyszerű szöveg is megfordul. Ez azt jelentené, hogy hibát vagy problémát kapna a pénztárca használatakor. A pénztárca tartalmának titkossága valószínűleg nem vész el, de a hitelesített titkosítás használata minden bizonnyal a legjobb gyakorlat.
Megjegyzések
- Köszönöm! Meg tudná magyarázni alig lehet elérni a hitelesített rejtjelezési szöveget ezzel a móddal? A fenti példák, mert úgy gondolom, hogy kapcsolódik az eredeti mac tulajdonsághoz, amelyet eltávolítottam az eredeti kulcstároló fájlból.
- A CTR mód a CCM, GCM, EAX, SIV és egy csomó más hitelesített mögöttes módja rejtjelek. A CTR mód és a (H) MAC kombinációja azonban szintén biztos lehet.Mindkettő nagyjából azonos méretű / biztonságú hitelesítési címkét állít elő. A CCM és az EAX alig több, mint a CTR és a MAC specifikus kombinációja, ahol ugyanaz a kulcs használható a titkosításhoz és a MAC-hoz.
- Ne feledje, hogy I ‘ ve legjobb tudásom szerint válaszolt erre a kérdésre, a rejtjelek általános ismereteinek felhasználásával (nem annyira Ethereum). Ella Rose igaza van abban, hogy a kérdésben kapott információk alapján nem következtethetünk a rendszer biztonságára. Tehát ‘ kizárólag a CTR használatára összpontosítottam.
- Nos, úgy tűnik, hogy a véletlenszerű – végül – a rendszer véletlenszerűségére támaszkodik. Gyakran a rendszer véletlenszerű forrásai viszonylag biztonságosak, és a CSPRNG kifejezést valóban megemlíti a forrás. Tehát téves az az állítás, hogy nem véletlenszerű, kivéve, ha a rendszer véletlenszerű alkalmazása nincs megfelelően végrehajtva vagy beágyazva.
- MAC létrehozása közvetlenül az SHA-3-ból nem ajánlott, inkább a KMAC-ot kellett volna használni (valószínűleg egyszerűen még nem volt megadva ‘ akkor). De eszembe sem jut olyan helyzet, ahol a kulcs és a titkosított szöveg összefűzése felett valaha is problémát jelentene.
Vélemény, hozzászólás?