Quanto è insicuro AES-128-CTR per crittografare qualsiasi tipo di dati utilizzando il formato di file del keystore di Ethereum?
Su Novembre 18, 2020 da adminSto utilizzando il formato di file del keystore di Ethereum per crittografare qualsiasi altro dato come testo normale o JSON.
Ecco un esempio di pseudocodice dellimplementazione:
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)
Con questo codice posso generare il file keystore simile a questo:
{ "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" } }
Questo è il file standard che memorizza milioni di dollari di persone in Ethers.
Domande:
- È sicuro?
- In caso negativo, perché?
- In caso affermativo, è sicuro anche crittografare il testo normale o JSON (nessun formato esadecimale)?
- È sicuro impostare un
kdfparams.n
?
Modifica: per chiarire perché lo chiedo è perché unaltra persona ha detto questo:
Questo non è affatto sicuro. Questa implementazione contiene molti errori di base. Un esempio è lutilizzo di un generatore di numeri casuali non sicuro, che distrugge completamente la sicurezza della crittografia. Un altro è lutilizzo di AES- 128-CTR senza autenticazione.
Commenti
- Innanzitutto, definisci ” secure ” . Ma secondo una definizione ragionevole, con una password dello stesso livello di ‘ 1234 ‘ e testo in chiaro così grande e ridondante, niente di utilizzabile è sicuro.
- Sicuro in termini di molto molto difficile da violare anche se è un buon crittografo L et me edit per chiarire che sarebbe una password molto efficace.
- Ora, definisci ” break ” . È trovare la password originale? Indovinare il testo in chiaro da un testo cifrato? Indovinare parte del testo in chiaro da molti testi cifrati che condividono alcuni? Indovinare un testo in chiaro da molti testi cifrati e tutti gli altri testi in chiaro? Possiamo ottenere aiuto da un eseguibile in esecuzione sulla stessa macchina (e se sì, esattamente quale CPU con quale patch di microcodice? Viene utilizzato AES-NI?). Possiamo usare lEMI come canale laterale? Un keylogger, hardware o sotfare? Infatti, qual è ‘ limplementazione di randomBytes, che ha uninfluenza?
- Non puoi rispondere a questa domanda guardando psuedocode. Lattuale implementazione può contenere tutti i tipi di vulnerabilità e canali secondari . Anche la sicurezza non è un sistema binario, ‘ dipende da quanto ‘ sei disposto ad andare per proteggerti da sempre più attacchi esotici .
- @ fgrieu scusa, lunica domanda a cui posso rispondere è: nodejs.org / api / … @EllaRose Presumo che le librerie che sto utilizzando non abbiano vulnerabilità. Quindi il mio pseudocodice sopra è solo unimplementazione di quelle funzioni delle librerie, come randomBytes.
Answer
Il peggiore debolezza puramente crittografica è la password (1). I punti deboli pratici peggiori (e molto peggiori) risiedono probabilmente nellimplementazione (6) (7) e in quelli (4) (5) che i crittografi scartano come al di fuori del campo di applicazione della crittografia (la domanda è lunico obiettivo dichiarato).
Candidati per debolezze, dalla crittografia (ma ancora da considerare) allimplementazione:
- La password: è difficile ricordare una password con oltre 48 bit di entropia ( che “è quasi equivalente a un numero di 16 cifre, come 3141592653589793 o 2718281828459045, e più di quanto previsto dallobbligatorio XKCD ). Utilizzando N = 262144 = 2 18 , r = 1, p = 8 = 2 3 , si acquista almeno 18 + 3 + 1 = 22 bit (vedere this ) rispetto a un hash SHA-256 diretto seguito da AES-128, immagino che sia più potente di circa 32 bit, quindi la chiave potrebbe essere buona per circa 80 bit, il che è non del tutto indistruttibile con la forza bruta ma comunque abbastanza sicuro.
- AES-128: questa ha una chiave a 128 bit, non nota puramente crittoanalitica attacco migliore della forza bruta, ed è quindi molto meglio della password.
- Modalità CTR: con il blocco a 128 bit di AES, lunico modo in cui il riutilizzo del flusso di chiavi potrebbe dare il via sarebbe un numero casuale errato generatore per IV (vedi 6)
- La dimensione del testo in chiaro può essere dedotta senza sforzo dalla dimensione del testo cifrato. Questo non è esplicitamente una debolezza teorica della crittografia, poiché la lunghezza è escluso da ciò che un cifrario dovrebbe nascondere riguardo al testo in chiaro. Tuttavia, questa può essere una debolezza pratica. Supponiamo che lanalisi del testo cifrato concluda che è 17267095423 ottetti; ed esiste, da qualche parte nellaccusa “s esibisce un file con esattamente quella dimensione, che precede in modo dimostrabile la ricerca e il sequestro del testo cifrato, e la cui semplice detenzione è illegale.
- Mancanza di rilevamento di alterazioni (intenzionali o accidentali) del testo cifrato, corrispondenti ad alterazioni prevedibili nel testo in chiaro: ancora una volta questa non è esplicitamente una debolezza teorica della crittografia, ma può consentire alcuni attacchi se lavversario può alterare il testo cifrato (esempio: se il testo in chiaro è un eseguibile o PDF con una frazione nota, ciò può consentire di modificare ciò che leseguibile fa su qualsiasi cosa, o fare in modo che il PDF venga visualizzato come qualcosa). Crittografia autenticata ( AES-GCM ..) risolve questo problema.
- Generatore di numeri casuali: se questo è cattivo o peggiore si blocca più o meno (obbligatori XKCD e Dilbert che si trasformano in realtà troppo spesso), ciò consentirebbe il recupero del testo in chiaro in molti scenari, inclusa la ripetuta cifratura di diversi testi in inglese o indirizzi e-mail con la stessa password.
- Un canale laterale, che è ampiamente parlare di fuga imprevista o totale di informazioni nellimplementazione o nel contesto di utilizzo. Ce ne sono così tanti:
- Recupero della password dal proprietario della password sfruttando un imbroglio procedurale (password su una nota postit, elenco di password principali), crittoanalisi con tubo di gomma (obbligatoria XKCD ), varianti legali (che implicano luso di espressioni sul tono di oltraggio alla corte ), corruzione, impregnazione chimica ..
- Recupero password da shoulder surfing , key logger (software o hardware), fotocamera, microfono (una buona acquisizione audio di il suono dei tasti durante limmissione di una password fa trapelare molte informazioni sulla password, specialmente se correlato allimmissione nota da tastiera dello stesso operatore nelle stesse condizioni) ..
- Semplice compromissione del testo in chiaro come mostrato sullo schermo (con TEMPEST di questo), stampato, trasmesso a una stampante o accessibile in remoto da una rete, o semplicemente memorizzato “temporaneamente” ..
- Diretto compromesso del SO della macchina sta eseguendo crittografia o decrittografia (è sufficiente ottenere un accesso root temporaneo, significa che nella versione 7.7 è un gioco per lattaccante).
- Canale laterale crittoanalitico a distanza, incluso DPA e variante elettromagnetica DEMA e ipoteticamente tempistica se la macchina che esegue la crittografia / decrittografia è accessibile da una rete e non utilizza Istruzioni AES .
- Canale laterale crittografico da un processo in esecuzione sullo stesso hardware (inclusa unaltra VM), incluso il targeting basato su cache per AES quando non si utilizza AES istruzioni, o più generali (Meltdown, Spectre) che vanno di moda in questi giorni.
- Sfruttamento di vari bug del software; è enorme.
Commenti
- Sarebbe più utile se eseguissi lhash della password prima della crittografia? Come usare sha o md5?
key = scrypt(sha(MY_PASSWORD), kdfparams)
- @EnZo: Lhashing della password prima dellingresso in scrypt non cambia di molto la difficoltà di attacco della password ( punto 1). Per migliorarlo è necessaria una password migliore, una migliore parametrizzazione della crittografia o un migliore schema di derivazione della chiave basato su password (Argon? Balloon?)
Risposta
Lelemento di sicurezza principale che può essere attaccato nello schema sopra è – ovviamente – la passphrase. Ora il sale è importante per evitare attacchi alla tavola arcobaleno ma altrimenti non aggiunge molta sicurezza. Se il sale e la password sono ragionevolmente univoci, anche la chiave è unica. In tal caso, lIV non è così importante.
Quindi, sebbene luso di un generatore di numeri casuali non sicuro sia dannoso, probabilmente non avrà molta influenza sulla sicurezza pratica. , indica che sono state effettivamente utilizzate cattive pratiche. E se la passphrase fosse stata generata utilizzando lo stesso generatore casuale non sicuro? E se dovessero emergere altri errori di implementazione?
Luso di testo cifrato non autenticato è più un problema, poiché consentirebbe allavversario di cambiare il testo in chiaro per ogni bit. Lavversario può semplicemente invertire qualsiasi bit di testo cifrato e anche il bit di testo in chiaro nella stessa posizione si capovolgerà.Ciò significherebbe che si otterrebbe un errore o un problema quando si utilizza il portafoglio. È probabile che la riservatezza dei contenuti del portafoglio non venga persa, ma lutilizzo della crittografia autenticata è sicuramente la migliore pratica.
Commenti
- Grazie! Potresti spiegare a malapena come ottenere un testo cifrato autenticato con questa modalità? Gli esempi sopra perché penso sia correlato alla proprietà mac originale che ho rimosso dal file keystore originale.
- La modalità CTR è la modalità sottostante di CCM, GCM, EAX, SIV e un intero gruppo di altri autenticati cifre. Tuttavia, anche una combinazione della modalità CTR con un (H) MAC può essere sicuramente sicura.Entrambi producono un tag di autenticazione con allincirca le stesse dimensioni / sicurezza. CCM e EAX sono poco più che combinazioni specifiche di CTR e MAC in cui la stessa chiave può essere utilizzata per la crittografia e il MAC.
- Tieni presente che ‘ ve ha risposto a questa domanda al meglio delle mie capacità, utilizzando una conoscenza generica dei cifrari (non tanto Ethereum). Ella Rose ha ragione sul fatto che non possiamo dedurre la sicurezza del sistema dalle informazioni fornite nella domanda. Quindi ‘ mi sono concentrato esclusivamente sulluso del CTR.
- Ebbene, il random sembra basarsi – alla fine – sul sistema random. Spesso le fonti casuali di sistema sono relativamente sicure e il termine CSPRNG è effettivamente menzionato dalla fonte. Quindi laffermazione che non è casuale è sbagliata, a meno che il sistema casuale non sia ben implementato o seminato.
- La creazione di un MAC direttamente da SHA-3 non è raccomandata, invece avrebbe dovuto essere usato KMAC (probabilmente semplicemente non era ‘ ancora specificato al momento). Ma non riesco a pensare a nessuna situazione in cui luso sulla concatenazione della chiave e del testo cifrato potrebbe mai rappresentare un problema.
Lascia un commento