Potresti voler utilizzare RFC 2945 e 5054 (descrizione di SRP e di come utilizzare SRP con TLS, rispettivamente); sono un po 'più "down to the wire" rispetto alla descrizione matematica dell'autore.
Quando l'autore di SRP afferma che il server può scegliere il primo n e inviarlo al client, non significa che il server possa scegliere un nuovo primo n per ogni sessione; lo stesso n deve essere usato quando la password dell'utente viene prima scelta (e v archiviata dal server) e quando viene scambiata una chiave. Ciò che l'autore SRP intende è che una sessione di autenticazione può iniziare dal server che invia un valore n al client e dice "useremo questo n , che è il n che abbiamo usato quando è stata scelta la password ". Il cliente non ha bisogno di essere sicuro, per quanto riguarda la sicurezza, che questo sia effettivamente lo stesso n , e non un altro n creato da un server falso. In questo senso, il valore di n non deve essere codificato nel client.
Tuttavia , se il client non ha bisogno di verificare che il valore di n sia lo stesso di quello usato in precedenza (dovrà essere lo stesso per il successo del protocollo, ma un distinto n inviato da un server falso non mette in pericolo la riservatezza della password), il client deve comunque assicurarsi che n sia corretto, il che implica, almeno , per verificare che n e (n-1) / 2 siano primi. Si veda ad esempio la sezione 3.2 di RFC 5054. La linea di fondo è che, per un uso efficiente di SRP, si vuole veramente usare alcuni valori n codificati, che sia il client che il server conoscono.
Probabilmente, potresti precomporre 3 o 4 serie di parametri (valori di n di dimensioni distinte, per paranoia / compromissioni di efficienza), che il server memorizza e nel client che archivi solo gli hash di quei valori; quando è necessario scambiare una password, il server invia n e il client verifica che il suo hash corrisponda a uno dei suoi valori hash codificati. In alternativa, sia il client che il server memorizzano i valori di n e utilizzano semplicemente identificatori brevi in modo che client e server utilizzino lo stesso valore. Si noti che se il valore di n dipende dall'utente (un determinato server utilizza diversi valori di n contemporaneamente, e deve inviare il "right" per un dato utente), quindi il protocollo deve disporre che l'utente indichi per primo il suo nome; questo è il punto dell'estensione TLS " srp " (sezione 2.8.1 di RFC 5054).
Non puoi cambiare il server n per un dato utente dopo la scelta della password, a meno che il server non memorizzi il valore equivalente alla password x = H (s, P) , e SRP è stato progettato proprio per evitare tale archiviazione.
Si noti che non vi è alcun problema di sicurezza di avere diversi utenti distinti su un determinato server o server distinti che usano lo stesso n . Un singolo n può essere adatto per il mondo intero. La RFC 5054 (appendice A) elenca alcuni n di dimensioni da 1024 a 8192 bit.