È sicuro utilizzare diverse chiavi derivate ma dalla stessa passphrase per la crittografia AES CBC seguita dall'hash HMAC SHA256?

Question

È sicuro utilizzare diverse chiavi derivate ma dalla stessa passphrase per la crittografia AES CBC seguita dall'hash HMAC SHA256?

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

5

Sto lavorando a un'applicazione di gestione list multipiattaforma (JS / iOS / Android) che persiste i dati tramite un'API REST e voglio garantire che tutti i dati testuali siano correttamente crittografati sul lato client in modo che non ci sia modo di decifrare i dati sul lato server e nel caso sfortunato che il database venga rubato non vale la pena spendere alcuno sforzo per provare a decrittografarlo.

Molti mesi di ricerche e tentativi ed errori mi hanno portato a decidere che la crittografia AES in modalità operativa CBC è la scelta migliore a causa della sua forza e dell'adozione ampia su tutte le piattaforme. Ho deciso di eseguire la derivazione delle chiavi sulla base dell'algoritmo simile di OpenSSL in modo da avere uno strumento da riga di comando affidabile per testare l'accuratezza della mia implementazione.

L'unica cosa che rimane è quella di garantire in qualche modo la validità della frase di accesso di crittografia fornita dall'utente che non sarà mai diretta sul lato server. L'idea migliore che mi è venuta in mente finora è quella di decodificare diversi elementi dell'elenco dopo l'accesso per verificare se possono essere decodificati correttamente applicando l'hashing HMAC sul testo cifrato, che a sua volta richiede l'archiviazione dell'hash HMAC sul lato server. / p>

Ho un paio di domande:

c'è un altro modo per garantire in modo sicuro la validità della passphrase fornita dopo un login riuscito?
è sicuro riutilizzare la stessa passphrase nella crittografia AES CBC come chiave segreta nell'hash HMAC degli stessi dati crittografati?

Ho visto questo thread TLS ma io non hanno bisogno della crittografia tra un tipico setup client / server. Nel mio caso il client crittografa i dati, archivia nel cloud e la volta successiva o lo stesso client o un altro client lo decrittano. Quindi, le strette di mano e simili in TLS non hanno molto senso per me.

Nota 1: intenzionalmente la chiamo una "passphrase" sopra per enfatizzare che è diversa dalla password dell'utente che è convalidata all'accesso e che è memorizzata come hash all'interno dell'account utente.

Nota 2: in cima a tutto ciò, le richieste viaggeranno attraverso HTTPS. Il punto di cui sopra non è quello di garantire la sicurezza del trasporto, ma quello di limitare la leggibilità dei dati al lato client per numerosi vantaggi in termini di sicurezza.

Apprezzo qualsiasi feedback. Grazie!

encryption hash

posta Norbert 10.09.2011 - 15:55

fonte

3 risposte

9

Stai arrotolando la tua crittografia. Non eseguire il rollpoint della propria crittografia . Invece, ti consiglio di utilizzare PGP o GPG o di utilizzare il loro formato: vale a dire il formato di file OpenPGP.

Non si dovrebbe usare la stessa chiave sia per la crittografia che per l'autenticazione. Non è consigliabile utilizzare la stessa chiave per AES-CBC e per HMAC.

Invece, ti suggerisco di ricavare due chiavi dalla chiave principale. ad esempio, K _enc = AES (MK, 0), K _auth = AES (MK, 1), dove MK è la chiave principale (una chiave AES) e 0 , 1 sono due diversi testi in chiaro AES. Ora usa K _enc come chiave di crittografia per l'uso con AES-CBC e usa K _auth come chiave di autenticazione da usare con SHA1-HMAC o AES-CMAC.

In alternativa, puoi utilizzare una modalità di crittografia autenticata , come EAX, CCM, GCM o OCB. La crittografia autenticata si occupa di derivare le chiavi da una singola chiave principale e si occupa di fornire sia l'autenticazione che la crittografia.

Sembra anche che tu stia facendo un altro errore: usare una passphrase come chiave di crittografia. Devi cercare di evitare l'uso delle password come chiavi di crittografia .

C'è qualche possibilità che tu possa semplicemente usare la crittografia convenzionale GPG? GPG è stato accuratamente scritto e controllato per occuparsi di tutti questi problemi.

risposta data 10.09.2011 - 23:46

fonte

1

Sì, puoi usare quel modello.

Fornire un utente con testo in chiaro e un HMAC di quel testo non rivela la chiave dell'HMAC.
Fornire un utente con testo in chiaro non consente loro di derivare l'HMAC senza conoscere la chiave.
Fornire a un utente un HMAC senza una chiave non consente di testare l'HMAC con qualsiasi testo.

Con quei fattori noti, fornire all'utente un HMAC e un testo cifrato che utilizzano la stessa chiave non dà a quell'utente nulla se non conoscono la chiave. Non c'è nulla che possa ridurre il numero di tentativi richiesti per sconfiggere la crittografia.

La sostanziale differenza tra questo schema e il semplice hash del testo in chiaro è che non si può effettivamente tentare di usare la forza bruta / tabella arcobaleno l'hash (anche se il messaggio è probabilmente troppo lungo comunque).

Esistono altre modalità che crittografano un messaggio in modo tale da garantire l'autenticità. Questi sono menzionati nelle risposte degli altri e potrebbero essere più utili a seconda delle esigenze. Suggerisco di investigare anche quelli.

risposta data 11.09.2011 - 02:33

fonte

Leggi altre domande sui tag encryption hash

Dovrei essere preoccupato per le password brute-forcing che codificano AES? Perché le misure di sicurezza comuni su un server web non sono sufficienti su larga scala?

score 7 · Accepted Answer

È possibile utilizzare PBKDF2 con diversi sali per derivare le chiavi per l'hashing e la crittografia. Lo scopo delle funzioni PBKDF è derivare le chiavi da pass (parole | frasi). I sali dovrebbero essere generati usando un PRNG crittograficamente strong e dovrebbero essere lunghi (ad es. Fino a quando le vostre chiavi). Nota che i sali per PBKDF2 non sono necessariamente segreti, quindi è sicuro inviarli al server se necessario (almeno il sale usato come input nella derivazione della chiave usata per HMAC).