Posso memorizzare la password, rendendola la chiave in AES-256?

Naviga le tue risposte
-1

Vorrei cercare un altro modo per salvare le credenziali, utilizzate per verificare l'accesso dell'utente al mio database.

Mi è venuta in mente questa idea. Dal momento che ritengo che anche conoscendo un testo in chiaro e un corrispondente testo cifrato derivato con il codice AES-256 non debba portare alla rivelazione della chiave, quando la chiave è sufficientemente lunga e abbastanza casuale, posso prendere la password come chiave di crittografia qui ?

Consideriamo un esempio, supponiamo che l'utente 'test' dovrebbe usare 'apple' come sua password. Nella registrazione, il programma funziona in questo modo:

  1. Scegli una stringa casuale di 32 byte. Denotato da R ;
  2. Costruisci il testo in chiaro P , di P = Whirlpool(R:'test':'apple') ; Qui Whirlpool è l'algoritmo di hash con lo stesso nome.
  3. Vorrei rendere la chiave più lunga, quindi dedurre K come chiave utilizzata per AES-256: K=Whirlpool('apple') ;
  4. Encrypt P di AES-256, quindi ottieni il testo cifrato E=AES256Encrypt(K, P) ;
  5. Quindi unisciti insieme a R e E , otteniamo la credenziale AUTH che dovrebbe essere salvata nel database: AUTH=R:E .

E quando ne avremo in seguito uno che inserisce il nome utente e la password, potremmo verificare ciò facendo:

  1. Cerca il nome utente e recupera AUTH ;
  2. Separa questo AUTH e abbiamo ottenuto R e E ;
  3. Utilizza il nome utente e la password forniti, potremmo calcolare P' , che è basato su R dal database, il nome utente e la password dall'input.
  4. E potremo derivare K' , un hash nell'algoritmo Whirlpool con questa password come input.
  5. Quindi utilizziamo K' per provare a decrittografare E , e quando decodificato con successo, confronta il decrittografato con P' .

In breve: posso usare la mia password come chiave in AES-256 e confrontando un testo in chiaro noto e il risultato della decrittografia del testo cifrato memorizzato, per verificare gli utenti e per evitare perdite di password degli utenti dopo che il database è in qualche modo trapelato ?

A mio modo di vedere, solo conoscere il nome utente (con poche parole qui) e il AUTH dovrebbe solo far trapelare i suggerimenti su come costruire una chiave di decrittografia possibile. L'attaccante è in grado di conoscere sia un testo in chiaro piuttosto randomizzato (e che non ha scelta di personalizzare) sia un testo cifrato fisso. E se qui è AES-256, non ci dovrebbe essere alcuna possibilità di rivelare la chiave (che non è la vera password) basandosi solo su questi due fattori.

E anche la casualità di questo testo in chiaro (derivato da una congiunzione di R , nome utente, password) non è importante. Ma sembra che la casualità della chiave possa dirlo.

L'ultimo aspetto della considerazione potrebbe essere la velocità. Per me, la velocità non è un vero problema, almeno ora. E sebbene il processo sopra descritto abbia utilizzato (sia in fase di registrazione che in fase di verifica) 2 tempi di hashing e una volta di AES, potremmo comunque ridurre il Whirlpool a una sola volta. Quando paragono questo con l'HMAC con l'idromassaggio (due volte Whirlpool è usato qui), vedo qui è solo una volta di Whirlpool e una volta di AES. Se AES dovesse essere più veloce di un algoritmo hash come Whirlpool, penso che ci possa essere un vantaggio. Ma apprezzerei chiunque parlasse di questo aspetto.

    
posta Lucifer Orichalcum 20.10.2013 - 15:10
fonte

2 risposte

2

Ciò che stai proponendo qui non è altro che costruire la tua funzione di hash con un codice a blocchi, immettendo i dati in hash come il tasto per il codice a blocchi e crittografando un "valore noto" ". Questo è, in effetti, un modo ben noto e ben studiato di costruire funzioni hash, noto come Merkle-Damgård. MD5, SHA-1, SHA-256, SHA-512 ... sono progettati in questo modo. Così è, infatti, Whirlpool .

Quest'ultimo caso è interessante: Whirlpool è indirettamente basato su AES; tuttavia, i progettisti di Whirlpool lo trovarono idoneo a "modificare" il cifrario del blocco di base in uno nuovo, chiamato "W". Volevano cambiare due cose: volevano blocchi più grandi (AES utilizza blocchi a 128 bit, il suo superset Rijndael va a 256 bit, ma volevano una "funzione hash a 512 bit") e, cosa più importante, avevano bisogno di un pianificazione dei tasti .

Esiste una debolezza piuttosto esoterica dei cifrari a blocchi noti come attacchi a chiave correlata che analizzano cosa succede quando diversi le chiavi di crittografia vengono utilizzate con differenze specifiche tra le chiavi. Gli attacchi a chiave correlata non rappresentano un problema per i codici a blocchi quando vengono utilizzati per quello per cui sono stati progettati, ovvero crittografia . Pertanto, non siamo eccessivamente preoccupati con AES che si è dimostrato non ottimale per quanto riguarda le chiavi correlate (il suo "key schedule", la parte che ricava la chiave dalle 11 alle 15 sottochiavi necessarie per la crittografia, non protegge bene contro relativi tasti). Tuttavia, se si utilizza il codice a blocchi come blocco predefinito in una funzione di hash MD, gli attacchi a chiave correlata si traducono quasi immediatamente in attacchi di collisione. Questo è il motivo per cui i progettisti di Whirlpool lo hanno trovato in grado di modificare il programma chiave di W in qualcosa che è più costoso (ha bisogno di più CPU) ma anche più strong rispetto alle chiavi correlate rispetto al programma base di Rijndael.

Quindi ciò che suggerisci è, fondamentalmente, costruire una funzione di hash in un modo che anche i designer di Whirlpool hanno considerato, ma rifiutato come "troppo debole". Questo non promette nulla di buono. Il solito avvertimento contro la crittografia fatta in casa è questo: non puoi sapere se la tua costruzione è sicura fino a quando molti crittografi lo hanno studiato per un po 'di tempo (anni), e non hanno trovato nulla di sbagliato in esso. Qui, alcuni crittografi hanno studiato la costruzione suggerita, e hanno trovato qualcosa di sbagliato in essa.

Tutto ciò detto, anche se trasformare AES-256 in una funzione di hash con la struttura MD era sicuro, farebbe solo una parte del lavoro. In effetti, l'hashing password ha alcuni requisiti extra che l'hashing normale non soddisfa. Le password sono deboli nel senso seguente: la forza bruta lavora contro di loro. Le funzioni di hashing della password devono far fronte alla bassa entropia delle password in due modi:

  • Non devi utilizzare la funzione di hash one , ma una grande famiglia di hash, in modo che ogni istanza di hashing della password utilizzi la propria funzione di hash. Questo è il concetto alla base di sali . Ciò impedisce attacchi paralleli , in particolare una classe specifica di attacchi paralleli noti come "tabelle precompilate" (comprese le tabelle arcobaleno). La tua "R" casuale potrebbe svolgere il ruolo di un salt (ma è difficile dirlo fino a quando non è stata eseguita un'analisi approfondita su in che modo viene iniettato il sale nel processo).

  • La funzione di hash deve essere lenta . Questo viene normalmente eseguito con un processo iterato, in cui il numero di iterazioni è di migliaia o addirittura di milioni. Altrimenti, enumerare potenziali password e provarle è troppo efficiente. Il conteggio delle iterazioni deve essere regolarmente aggiornato per tenere conto dei miglioramenti tecnologici (i computer diventano più veloci nel tempo, ma non i cervelli umani). La tua proposta è troppo veloce per il massimo comfort.

Vedi questa risposta per una discussione e puntatori più lunghi .

    
risposta data 20.10.2013 - 16:13
fonte
1

In primo luogo, si tratta di un'idea orribile per pubblicare il tuo schema di crittografia. Non farlo Utilizza bcrypt , scrypt o pbkdf2 .

La fase di crittografia nel tuo schema è inutile. È solo una sostituzione di un rapido confronto dell'hash output con un passo di crittografia leggermente meno efficiente. Lo schema si riduce essenzialmente a due iterazioni di hash, una con R e il nome utente che funge da sale e una volta senza alcun tipo di sali. Ciò non risolve il problema di un utente malintenzionato che scarica il database delle password e lo esegue tramite un cracker password che è esattamente quello che gli schemi di hashing della password lenta come bcrypt , scrypt o pbkdf2 stanno cercando di evitare.

    
risposta data 20.10.2013 - 15:20
fonte

Leggi altre domande sui tag

Come posso crittografare la sessione di accesso alla pagina di amministrazione del router? [chiuso] Sicurezza e privacy nell'e-mail e in altre comunicazioni [chiuso]