Revisione dell'algoritmo di archiviazione dei dati crittografati

0

Sto costruendo un piccolo strumento a linea di comando (principalmente per divertimento) destinato a memorizzare dati (come password o file) crittografati in un database locale, con una password fornita dall'utente, praticamente la stessa funzionalità di KeePass.

Sto cercando una recensione su quello che sto facendo per confermare che non sto lasciando alcun buco di sicurezza e sto usando correttamente algoritmi noti o se c'è troppa ridondanza.

È anche importante quanto resilienti i dati siano contro la forza bruta.

Il processo è il seguente:

Crittografia:

  • L'utente fornisce una password e dati

  • Due chiavi da 32 byte derivano dalla password dell'utente (chiamatela d_key e s_key), usando PBKDF2 con un RNG (os urandom) di 16 byte (diverso sale per ogni chiave) e 10000 iterazioni (configurabile)

  • I dati vengono crittografati utilizzando AES CTR con d_key e una firma viene calcolata dal testo cifrato utilizzando HMAC sha512 con s_key

  • Sia il testo cifrato che le firme hmac sono archiviati nel database, insieme ai sali usati e al conteggio delle iterazioni.

Decodifica:

  • L'utente inserisce la sua password e l'ID dei dati che desidera recuperare

  • d_key e s_key vengono generati utilizzando i sali memorizzati e il conteggio delle iterazioni.

  • I dati vengono caricati decrittografati usando d_key

  • HMAC viene ricalcolato dai dati crittografati, utilizzando s_key e confrontato con quello memorizzato per confermare che i dati non sono stati modificati e la chiave è valida.

  • Tutto bene, dati restituiti all'utente.

Ora la mia domanda principale è, HMAC sembra ridondante, ma sembra l'unico buon modo per verificare che la chiave sia valida, altrimenti sarebbe necessario confrontare un hash dei dati in testo semplice, il che sarebbe molto facile da decodificare / forza bruta.

Inoltre, ho davvero bisogno di due chiavi separate per AES e HMAC? Anche se stai usando un sale?

Infine, PBKDF2 aiuta davvero? O sarebbe lo stesso usare semplicemente una funzione di hash per derivare la chiave? Dal momento che la chiave non è memorizzata da nessuna parte, sembra ridondante, anche se suppongo che se la chiave non è salata e la bruta iterata potrebbe essere più semplice.

    
posta user1777914 05.02.2018 - 18:40
fonte

1 risposta

1

Now my main question is, HMAC seems redundant, but seems like the only good way to check that the key is valid, otherwise a hash of the plain text data would need to be compared which would be very easy to reverse engineer / brute force.

HMAC è importante. La crittografia AES CTR ti garantisce la riservatezza. Ma non è abbastanza. È inoltre necessario un controllo di integrità, che HMAC può fornire. Cerca Crittografia autenticata per i dettagli.

Ottenere l'implementazione giusta può essere complicato quindi ti consiglio di utilizzare AES GCM, che ha il built-in di verifica dell'integrità.

Ma dal momento che stai arrotolando il tuo controllo di integrità ...

Also, do I really need two separate keys for AES and HMAC?

Sì, ma facile da fare. Abbassare la stessa password tramite PBKDF2 ma con un conteggio di iterazione diverso (ad esempio 20000). Ciò che è interessante di questo approccio è che potresti usare la chiave derivata per HMAC per autenticare l'utente, cioè se il controllo HMAC fallisce, non provare a decifrare il testo cifrato - basta restituire un errore indicando che la password era sbagliata. Sebbene sia una semplificazione, questo è il modo in cui i gestori di password funzionano in poche parole: la stessa password viene utilizzata per l'autenticazione e la crittografia.

Lastly, does PBKDF2 really help?

Sì, per mitigare gli attacchi di forza bruta di:

  1. Fare intenzionalmente PBKDF2 un'operazione costosa, specialmente con iterazioni più elevate.
  2. Espansione della password per occupare l'intero spazio AES di 128 o 256 bit. Altrimenti avresti bisogno di password ridicolmente lunghe.
risposta data 14.02.2018 - 17:34
fonte

Leggi altre domande sui tag