Codifica correttamente utilizzando AES-256 in modalità CBC?

Question

Codifica correttamente utilizzando AES-256 in modalità CBC?

#1 da (3 voti)
#2 da (2 voti)

3

Per lo scopo dello strumento che sono attualmente in fase di scrittura , ho bisogno di eseguire qualche crittografia / decrittografia AES su qualche input. È come una pipeline: i dati vengono alimentati, viene eseguito l'algoritmo e trasmesso al modificatore successivo.

Sono abituato a openssl enc -aes-256-cbc per crittografare e decrittografare tutto. La mia comprensione di questo è che, per prima cosa, si ottiene la chiave inserita usando una sorta di pbkdf-sha1 con circa 8 byte generati salt , quindi si ottiene iv da derived key + salt .

Ovviamente funziona solo con OpenSSL dato che non sono stato in grado di trovare nessuno standard su come comunicare - o scrivere su file - i parametri iv e salt . Mi aspettavo una specie di RFC (come per i parametri della curva ellittica) ma senza fortuna.

La mia idea è di avere un'intestazione di 64 byte: salt + iv prima nel file, quindi è seguito dai dati crittografati. Userò il salt con pbkdf2-sha256 per derivare la chiave.

Le intestazioni non hanno una lunghezza fissa, la regolazione dei parametri corretti quando avvii il programma otterrà il salt e iv impostato sui valori corretti.

Non voglio fare alcun errore. Sono rimasto sbalordito da come potrebbe essere il link più debole e quanto sia facile recuperare una password da una brutta derivazione di chiavi e / o dalla generazione di IV.

Sono piuttosto sicuro che ogni implementazione aes abbia il proprio protocollo sui parametri. E penso che sia triste.

Ovviamente userò crypto/aes da Go e il loro pbkdf2 , prendendo sempre la fonte casuale da crypto/rand e non math/rand .

Per riassumere:

Esiste uno standard con parametri AES come salt e iv ?
Devo generare iv o derivarlo da salt || dk ?

Modifica

Ho dimenticato di menzionare che stavo per usare PKCS 5#2.0 che specifica come derivare la chiave, ma questa domanda era più rivolta alle best practice su iv e salt di archiviazione per una maggiore compatibilità.

cryptography aes

posta tehmoon 28.11.2017 - 23:27

fonte

2 risposte

Leggi altre domande sui tag cryptography aes

Come posso sapere che chi mi ha chiamato è il mio fornitore di servizi di telefonia mobile? Verifica firma S / MIME senza certificato incluso

score 3 · Answer 1

Prima di tutto, salt non è un parametro AES. Hai due primitivi diversi qui:

Avresti:

pbkdf(salt, password) restituisce aes_key
aes(iv, aes_key)

La dimensione IV deve corrispondere alla dimensione del blocco che si sta utilizzando (in genere 128 bit in quanto è quella standard, sebbene sono possibili altre dimensioni di blocco ).

Genera una nuova iv casuale per ogni file che desideri crittografare.

Ogni implementazione AES deve fornire lo stesso algoritmo. Il modo in cui hai scelto di salvare i dati sul disco è diverso.

Una soluzione comune sarebbe semplicemente aggiungere tutto:

file_password_salt || file_iv || file_contents

Tuttavia, una soluzione più a prova di futuro incorpora alcuni parametri che puntano alla dimensione dei campi e all'algoritmo utilizzato. O, almeno, un numero di versione (ad esempio v1 PBKDF1 con SHA1 e AES-128, in pochi mesi potresti voler usare Argon, con Camellia ...).

Quindi, potresti decidere di utilizzare un formato già utilizzato da altri strumenti, in modo che sia compatibile con loro. Ad esempio, copia di cosa fa OpenSSL (vedi la stringa "SALTED"?), O rendi output un wrapper zip sul contenuto di aes.

score 2 · Answer 2

Vicino a cross-dupe link

openssl enc deriva sia la chiave che IV da pw e salt, basate su ma modificata da PKCS5 v1 , vedere (mio) link - ma non prendere questo come esempio da seguire.

Oltre al CMS basato su ASN.1, che è più RFC (vedi link sopra), il formato OpenPGP (che usa la propria codifica) supporta la crittografia basata su password ed è RFC 4880 , e gli standard per la crittografia e la firma XML sono pubblicati da w3.org in un processo aperto simile a RFC ma non sotto IETF. Sia PKCS7 / CMS che PGP sono stati originariamente progettati per la crittografia a chiave pubblica (davvero ibrida a chiave pubblica più simmetrica) e a chiave pubblica (idem), ma sono state aggiunte opzioni per la crittografia basata su password (più simmetrica).

Se hai bisogno di operazioni di pipeline / streaming sarà più difficile aggiungere (o includere) l'autenticazione, molto probabilmente lasciandoti aperto agli attacchi attivi.