Jak nejistá je AES-128-CTR k šifrování jakýchkoli dat pomocí formátu souboru úložiště klíčů Ethereum?
On 18 listopadu, 2020 by adminK šifrování jakýchkoli dalších dat, jako je prostý text nebo JSON, používám formát souboru úložiště klíčů Ethereum.
Zde je příklad pseudokód implementace:
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)
S tímto kódem mohu vygenerovat soubor úložiště klíčů, který vypadá takto:
{ "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" } }
Toto je standardní soubor, který ukládá miliony lidí v Ethers.
Otázky:
- Je to bezpečné?
- Pokud ne, proč?
- Pokud ano, je také zabezpečené šifrování prostého textu nebo JSON (bez hexadecimálního formátu)?
- Je bezpečné nastavit menší
kdfparams.n
?
Upravit: Abych objasnil, proč se ptám, je to proto, že to řekla jiná osoba:
Toto není vůbec bezpečné. Tato implementace obsahuje mnoho základních chyb. Jedním příkladem je použití nezabezpečeného generátoru náhodných čísel, který zcela zničí zabezpečení šifrování. Jiný používá AES- 128-CTR bez ověření.
Komentáře
- Nejprve definujte “ zabezpečený “ . Ale rozumnou definicí, s heslem ve stejné lize jako ‚ 1234 ‚ a prostý text, který je velký a nadbytečný, není nic použitelného zabezpečeno.
- Zabezpečeno, pokud jde o velmi obtížné rozbití, i když je dobrý kryptograf. L. Upravte mě a ujasněte si, že by to bylo velmi silné heslo.
- Nyní definujte “ break “ . Je to nalezení původního hesla? Hádáte holý text z jednoho šifrovacího textu? Hádáte část holého textu z mnoha sdílených šifrovacích textů, že některé? Hádáte jeden holý text z mnoha šifrovacích textů a všechny ostatní holý text? Můžeme získat pomoc od spustitelného souboru běžícího na stejném stroji (a pokud ano, přesně jaký procesor s jakou mikrokódovou opravou používá AES-NI?). Můžeme použít EMI jako postranní kanál? Keylogger, hardware nebo sotfare? Jaká je ‚ implementace randomBytes, která má vliv?
- Na tuto otázku nemůžete odpovědět, když se podíváte na psuedocode. Skutečná implementace může obsahovat nejrůznější chyby zabezpečení a postranní kanály . Zabezpečení také není binární, ‚ záleží na tom, jak daleko jste ‚ ochotni jít k ochraně před čím dál více exotické útoky .
- @ fgrieu omlouvám se, jediná otázka, na kterou mohu odpovědět, je: nodejs.org / api / … @EllaRose Předpokládám, že knihovny, které používám, nemají chyby zabezpečení. Můj výše uvedený pseudokód je tedy jen implementací těchto funkcí knihoven, jako je randomBytes.
Odpověď
Nejhorší čistě kryptografickou slabinou je heslo (1). Nejhorší (a mnohem horší) praktické slabiny budou pravděpodobně v implementaci (6) (7) a v těch (4) (5), které kryptografové odmítají jako mimo rozsah šifrování (otázka je pouze stanoveným cílem).
Kandidáti na slabé stránky, od kryptografických (ale stále je třeba je zvážit) po implementaci:
- Heslo: je těžké si zapamatovat heslo s více než 48 bity entropie ( to odpovídá zhruba 16místnému číslu, například 3141592653589793 nebo 2718281828459045, a více, než si představoval povinný XKCD ). Pomocí N = 262144 = 2 18 , r = 1, p = 8 = 2 3 nakupuje minimálně 18 + 3 + 1 = 22 bitů (viz this ) ve srovnání s přímým hashem SHA-256 následovaným AES-128, myslím, že asi o 32 bitů silnější, takže klíč může být asi 80-bitový dobrý, což je ne zcela nerozbitný hrubou silou, ale stále docela bezpečný.
- AES-128: má 128bitový klíč, není znám čistě kryptoanalyticky útočí lépe než hrubou silou, a je tedy mnohem lepší než heslo.
- Režim CTR: se 128bitovým blokem AES by jediným způsobem, jak by bylo možné znovu použít klíčový proud, bylo špatné náhodné číslo generátor pro IV (viz 6)
- Velikost holého textu lze snadno odvodit z velikosti ciphertextu. Toto je výslovně není teoretická slabost šifrování, protože délka je vyloučeno z toho, co má šifra skrýt o prostém textu. To však může být praktická slabost. Řekněme, že analýza šifry dospěla k závěru, že je 17267095423 oktetů; a tam někde v obžalobě existuje spis přesně takové velikosti, který prokazatelně předchází hledání a zabavení šifrovacího textu a jehož pouhé zadržení je nezákonné.
- Nedostatečná detekce (úmyslných nebo náhodných) změn šifrovacího textu, což odpovídá předvídatelným změnám v prostém textu: opět se jedná výslovně není o teoretickou slabost šifrování, ale může umožnit některé útoky pokud může protivník změnit šifrovací text (příklad: je-li holý text spustitelný soubor nebo PDF se známým zlomkem, může to umožnit změnu toho, co spustitelný soubor dělá, o čemkoli, nebo umožnit zobrazení PDF jako o čemkoli). Ověřené šifrování ( AES-GCM ..) to řeší.
- Generátor náhodných čísel: pokud je to špatné nebo se horší víceméně zasekne (povinné XKCD a Dilbert , které se až příliš často obracejí k realitě), což by umožnilo obnovit holý text v mnoha scénářích, včetně opakovaného šifrování různých anglických textových nebo e-mailových adres stejným heslem.
- Postranní kanál, který je obecně mluvení nepředvídaného nebo nezpochybněného úniku informací v kontextu implementace nebo použití. Je jich tolik:
- Obnova hesla od držitele hesla využitím procedurální chyby (heslo na poštovní poukázce, hlavní seznam hesel), dešifrování gumové hadice (povinné XKCD ), legální varianty (zahrnující použití výrazů ve smyslu opovržení soudem ), úplatkářství, chemická impregnace ..
- Obnova hesla procházení ramen , záznamník klíčů (software nebo hardware), kamera, mikrofon (dobrý zvukový záznam zvuk kláves při zadávání hesla prozrazuje spoustu informací o hesle, zejména pokud souvisí se známým zadáním klávesnice stejným operátorem za stejných podmínek).
- Přímý kompromis prostého textu, jak je zobrazen na obrazovce (s TEMPEST jejich variant), tištěné, přenášené na tiskárně nebo vzdáleně přístupné ze sítě nebo pouze „dočasně“ uložené ..
- Přímý kompromis operačního systému stroje šifrování nebo dešifrování (získání dočasného přístupu root je dost, prostředky v 7.7 jsou hra pro útočníka).
- Kryptanalytický boční kanál na dálku, včetně DPA a elektromagnetická varianta DEMA a hypoteticky časování , pokud je stroj provádějící šifrování / dešifrování přístupný sítí a nepoužívá Pokyny AES .
- Kryptanalytický postranní kanál z procesu běžícího na stejném hardwaru (včetně jiného virtuálního počítače), včetně cílení založeného na mezipaměti pro AES, když nepoužíváte AES instrukce nebo obecnější pokyny (Meltdown, Spectre), které dnes zuří.
- Využívání různých softwarových chyb; to je obrovské.
Komentáře
- Bylo by užitečnější, kdybych měl hash heslo před šifrováním? Stejně jako použití sha nebo md5?
key = scrypt(sha(MY_PASSWORD), kdfparams)
- @EnZo: Hashování hesla před vstupem do scryptu moc nezmění obtížnost útoku hesla ( bod 1). Abychom to vylepšili, potřebuješ lepší heslo, lepší parametrizaci scryptu nebo lepší schéma odvození klíče na základě hesla (Argon? Balloon?)
Odpověď
Hlavním bezpečnostním prvkem, který lze napadnout ve výše uvedeném schématu, je – samozřejmě – fráze. Nyní je sůl důležitá, aby se zabránilo útokům na duhovou tabulku, ale jinak nepřidává tolik bezpečnosti. Pokud jsou sůl a heslo přiměřeně jedinečné, je jedinečný také klíč. V takovém případě IV není tak důležité.
Takže i když je použití nezabezpečeného generátoru náhodných čísel špatné, pravděpodobně nebude mít na praktickou bezpečnost tolik vlivu. , znamená to, že byly skutečně nasazeny špatné postupy. Co když byla přístupová fráze vygenerována pomocí stejného nezabezpečeného náhodného generátoru? Co když se objeví další chyby implementace?
Používání neověřeného šifrovacího textu je spíše problém, protože umožnilo by to protivníkovi změnit holý text pro každý bit. Protivník může jednoduše invertovat jakýkoli bit ciphertext a bit holého textu na stejné pozici se také otočí. To by znamenalo, že byste při používání peněženky dostali chybu nebo problém. Důvěrnost obsahu peněženky se pravděpodobně neztratí, ale použití ověřeného šifrování je určitě osvědčeným postupem.
Komentáře
- Děkuji! Mohli byste vysvětlit sotva, jak dosáhnout ověřeného šifrovacího textu s tímto režimem? Výše uvedené příklady, protože si myslím, že souvisí s původní vlastností macu, kterou jsem odstranil z původního souboru úložiště klíčů.
- Režim CTR je základním režimem CCM, GCM, EAX, SIV a celé řady dalších ověřených šifry. Kombinace režimu CTR s (H) MAC však může být jistě také bezpečná.Oba vytvářejí ověřovací značku se zhruba stejnou velikostí / zabezpečením. CCM a EAX jsou něco víc než konkrétní kombinace CTR a MAC, kde lze použít stejný klíč pro šifru a MAC.
- Všimněte si, že jsem ‚ ve odpověděl jsem na tuto otázku podle svých nejlepších schopností pomocí obecných znalostí šifer (ne tolik Ethereum). Ella Rose má pravdu, že nemůžeme vyvodit bezpečnost systému z informací, které jsme dostali v otázce. Takže jsem se ‚ zaměřil pouze na použití CTR.
- No, zdá se, že náhoda se spoléhá – nakonec – na náhodný systém. Systémové náhodné zdroje jsou často relativně bezpečné a zdroj CSPRNG je skutečně uveden. Tvrzení, že to není náhodné, je nesprávné, pokud není náhodný systém dobře implementován nebo nasazen.
- Přímé vytváření MAC z SHA-3 se nedoporučuje, místo toho měl být použit KMAC (pravděpodobně prostě nebyl ‚ dosud specifikován). Ale nedokážu si představit žádnou situaci, kdy by použití zřetězení klíče a šifrovacího textu někdy představovalo problém.
Napsat komentář