Dimensioni variabili ottimali nel protocollo Secure Remote Password

Question

Dimensioni variabili ottimali nel protocollo Secure Remote Password

#1 da (5 voti)

9

Sto implementando il protocollo Secure Remote Password:

  U = <username>              -->
                                 <--    s = <salt from passwd file>
  a = random()
  A = g^a % N                 -->
                                     v = <stored password verifier>
                                     b = random()
                              <--    B = (v + g^b) % N
  p = <raw password>
  x = SHA(s | SHA(U | ":" | p))

  S = (B - g^x) ^ (a + u * x) % N    S = (A * v^u) ^ b % N
  K = SHA_Interleave(S)              K = SHA_Interleave(S)

Quale numero di numeri dovrei impostare per tutte le variabili? RFC 2945 ha raccomandato che u sia 32 bit ma non inferiore. N è 4096-bit, g = 2.

Il mio obiettivo è massimizzare la sicurezza senza spese inutili. Quanto dovrebbe essere grande s, a, b? Ultimo ma non meno importante, qual è la lunghezza ottimale per la chiave di sessione K, che verrà utilizzata da un codice AES?

Modifica: SHA_Interleave (S) restituisce l'hash SHA di ogni altro byte concatenato con l'hash SHA dei byte rimanenti, raddoppiando quindi la lunghezza del risultato. SHA256 sarebbe sufficiente? Quale chiave dimensione sarò dopo per AES?

authentication cryptography encryption passwords key-exchange

posta jnm2 16.06.2011 - 18:09

fonte

1 risposta

Leggi altre domande sui tag authentication cryptography encryption passwords key-exchange

Come faccio a verificare il codice di un'estensione di Chrome per assicurarmi che non stia rubando le mie informazioni? Come posso verificare se Notepad ++ stia utilizzando una versione della libreria SciLexer.dll che è stata modificata dalla CIA?

score 5 · Accepted Answer

RFC 5054 ha raccomandazioni un po 'più precise. Per essere coerenti, si deve cercare di raggiungere un determinato "obiettivo di sicurezza" espresso in bit come parametro t : cioè, che il sistema è sicuro contro attacchi che hanno potenza di calcolo fino a 2 ^t operazioni elementari. Il valore tradizionale per t era di 80 bit, ma i progressi tecnologici rendono la potenza di calcolo disponibile scomodamente vicina a tale limite. Poiché i crittografi amano semplicemente i poteri di 2, è ormai consuetudine utilizzare 128 bit come obiettivo di sicurezza. Anche con una stima troppo ottimistica di quanto a lungo la legge di Moore continuerà e che cosa significa, 128 bit sono ancora al sicuro per almeno i prossimi 40 o 50 anni, e al di là di tali previsioni sono piuttosto prive di significato.

Per ottenere t bit di sicurezza, dovresti avere il seguente:

Gli elementi privati Diffie-Hellman (qui a e b ) dovrebbero avere dimensioni almeno 2t bit (quindi 256 bit - Questo è quello che RFC 5054 raccomanda, a proposito).
Le funzioni di hash coinvolte dovrebbero avere dimensioni di output almeno di 2t in tutta la generalità, anche le dimensioni di output più brevi sono tollerabili in molti casi ( 2t bit di output si tratta di avere una 2 ^t resistenza alle collisioni, ma in molti casi le collisioni non sono un problema, vogliamo solo 2 ^t resistenza alle preimmagini, e per che i bit di uscita t siano sufficienti).
Le chiavi di crittografia simmetrica e le chiavi MAC devono avere almeno la lunghezza di t bit (e AES può funzionare con chiavi a 128 bit).
Idealmente, i sali dovrebbero avere lunghezza 2t bit in modo che i rischi di avere una collisione (due sali identici per utenti distinti) siano inferiori a 2 ^-t , ma puoi avere sali più brevi perché il server può controllare quanti utenti può avere e sarà sicuramente molto più lento di 2 ¹²⁸ ( qui, stiamo parlando della potenza di calcolo del server, non della potenza di calcolo dell'attaccante).
Il valore u , come una sfida online, dovrebbe avere lunghezza t bit, ma anche in questo caso un valore più breve è perfettamente tollerabile perché la dimensione di < em> u può essere sfruttato solo negli attacchi online: con un u a 32 bit, un utente malintenzionato ha una probabilità di 1 su 4 di strappare un attacco impersonante, ma ogni errore è visibile al client e al server. Anche in questo caso, il server avrà qualche problema a servire miliardi di richieste in breve tempo e certamente non lo farà in modo discreto. Inoltre, l'utente malintenzionato potrebbe anche provare a indovinare la password stessa, con le stesse condizioni di controllo online, quindi è piuttosto priva di significato avere un u più lungo dell'entropia media prevista della password - e 32 bit di l'entropia della password è già una cifra ottimistica.
n (il numero primo) dovrebbe essere abbastanza grande che il modulo logaritmo discreto n abbia almeno 2 ^t . Tale "difficoltà" è difficile da stimare poiché funziona su costi di natura distinta rispetto a quelli a cui è abituato, ad es., Interruzione della crittografia simmetrica. Tuttavia, ci sono tentative . 4096 bit sono piuttosto un overkill; Personalmente sarei abbastanza contento di 2048 bit.

SRP produce un valore segreto condiviso S , che viene poi esteso al materiale della chiave simmetrica attraverso una Chiave Funzione di derivazione . SHA_Interleave() è una proposta per tale KDF. In RFC 5054, viene utilizzato il KDF definito in TLS (con il nome "funzione pseudocasuale"). Per il corretto tunneling dei dati, sono necessarie quattro chiavi simmetriche a 128 bit: una chiave di crittografia e una chiave di verifica dell'integrità in entrambe le direzioni. Se si utilizza una modalità di crittografia e integrità combinata, sono necessarie solo due chiavi simmetriche a 128 bit (una in ciascuna direzione).

Sembra davvero che tu stia reinventando TLS con SRP, qualcosa che è difficile ottenere a così tanti livelli che dovresti davvero usare il vero TLS.