Sto implementando il protocollo Secure Remote Password e simile a questa domanda , mi chiedo se posso usare la funzione hash SHA-512 al posto di SHA-1 attualmente in uso. Questo contribuirebbe a migliorare la riservatezza della chiave?
M = SHA1(A | B | Key) -->
<-- SHA1(A | M | Key)
Penso che sia corretto usare SHA1 in SRP. SHA1 va bene per questi scopi. L'utilizzo di SHA1 non danneggerà la riservatezza della chiave.
Alcuni dicono che "SHA1 ha alcuni punti deboli". Tuttavia, queste debolezze sono relativamente minori e, in ogni caso, influenzano solo la resistenza di SHA1 agli attacchi di collisione. Questi attacchi non influenzano o mettono in pericolo l'SRP, dal momento che SHA1 non si basa sulla resistenza alle collisioni di SHA1. Il passaggio a una diversa funzione di hash non è in grado di migliorare la riservatezza della chiave. Per una discussione più dettagliata, vedi Sezione 3.4 di RFC 5054 , che tratta dell'uso di SHA1 nell'SRP protocollo.
Sono un po 'scettico sul fatto di apportare modifiche a un protocollo crittografico, su principi generali. I protocolli di crittografia sono complicati e pochi dettagli possono fare una grande differenza per la sicurezza, in particolare i protocolli di accordo sulle chiavi autenticati da password (dove il layout esatto dei bit di alcuni campi può essere importante per la sicurezza). Il mio suggerimento sarebbe quello di trovare una specifica esistente, ben controllata, che fornisca una specifica completa del protocollo SRP e la adotti esattamente. Apportare modifiche ha il potenziale per introdurre sottili punti deboli di sicurezza.
Tuttavia, se si desidera modificare la funzione di hash nel modo in cui si delinea, penso che sarebbe un cambiamento relativamente ragionevole, a basso rischio. Infatti, Sezione 3.2 di RFC 2945 (una specifica di SRP versione 3) dice che è OK cambia SHA1 in un'altra funzione hash crittograficamente strong, quindi cambiare l'hash utilizzato nel passaggio di conferma della chiave in SHA256 o SHA512 sarebbe probabilmente OK.
La proprietà di SHA-1 qui usata è la sua resistenza alle pre-immagini : è computazionalmente impossibile da calcolare, per quanto sappiamo, un messaggio m che produce un dato l'output SHA-1 ( m ), o anche per ottenere alcune "informazioni" su m . Ci sono due modi per calcolare una pre-immagine:
Il metodo "fortuna" richiede una media di 2 n tentativi per una funzione di hash con un output n -bit; con SHA-1, n = 160 , il che rende l'attacco di fortuna costare troppo caro (circa un miliardo di miliardi di miliardi di volte rispetto a quanto tecnologicamente fattibile). Per quanto riguarda le debolezze strutturali, non si sa ancora nulla (ci sono noti punti deboli in SHA-1, ma influenzano la resistenza alle collisioni, non alle pre-immagini). Persino MD5 andrebbe bene qui, nonostante la sua interruzione pubblicizzata (e là è una debolezza strutturale nota in MD5 che rende le preimmagini più facili da calcolare rispetto all'utilizzo della fortuna - ancora irrealizzabile, ma leggermente più semplice).
Pertanto, la sostituzione di SHA-1 con SHA-256 o SHA-512 non sarebbe d'aiuto - dal momento che SHA-1 è già sicuro come si può ottenere, e non vi è alcun livello di sicurezza oltre a non essere rotto. D'altra parte, qualsiasi modifica a un protocollo crittografico rompe la compatibilità con le implementazioni esistenti e ti catapulta nel pericoloso regno della crittografia fatta in casa, quindi non può essere raccomandato.
Leggi altre domande sui tag cryptography hash key-exchange