Es posible que desee utilizar RFC 2945 y 5054 (descripción de SRP y de cómo usar SRP con TLS, respectivamente); son un poco más "hasta el cable" que la descripción matemática del autor.
Cuando el autor del SRP declara que el servidor puede elegir el primer n y enviarlo al cliente, no significa que el servidor pueda elegir un nuevo primer n para cada sesión; se debe utilizar el mismo n cuando se elige por primera vez la contraseña del usuario (y v que almacena el servidor) y cuando se intercambia una clave. Lo que el autor de SRP quiere decir es que una sesión de autenticación puede comenzar con el servidor enviando un valor n al cliente y diciéndole "usaremos este n , que es el n que usamos cuando elegimos la contraseña ". El cliente no tiene que estar seguro, desde el punto de vista de la seguridad, de que este es de hecho el mismo n y no otro n creado por un servidor falso. En ese sentido, el valor de n no necesita estar codificado en el cliente.
Sin embargo , si el cliente no necesita verificar que el valor de n sea el mismo que se usó de antemano (tendrá que ser el mismo para que el protocolo tenga éxito, pero un n distinto enviado por un servidor falso no pondrá en peligro la confidencialidad de la contraseña), el cliente todavía debe asegurarse de que n sea correcto, lo que implica que, al menos, , para comprobar que n y (n-1) / 2 son primos. Consulte, por ejemplo, la sección 3.2 de RFC 5054. La conclusión es que, para un uso eficiente de SRP, realmente desea utilizar algunos valores n codificados, que tanto el cliente como el servidor conocen.
Posiblemente, podría calcular previamente 3 o 4 conjuntos de parámetros (valores de n de distintos tamaños, para compensaciones de paranoia / eficiencia), que el servidor almacena, y solo en el cliente que almacena los hashes de esos valores; cuando se necesita cambiar una contraseña, el servidor envía n y el cliente verifica que su hash coincida con uno de sus valores hash codificados. Alternativamente, haga que el cliente y el servidor almacenen los valores de n , y simplemente use identificadores cortos para que tanto el cliente como el servidor usen el mismo valor. Tenga en cuenta que si el valor de n depende del usuario (un servidor determinado utiliza varios valores de n al mismo tiempo y debe enviar el "correcto" para un usuario determinado), entonces el protocolo debe disponer que el usuario primero indique su nombre; Este es el punto de la extensión TLS " srp " (sección 2.8.1 de RFC 5054).
No puede hacer que el servidor cambie n para un usuario determinado después de la elección de la contraseña, a menos que el servidor almacene el valor equivalente de contraseña x = H (s, P) , y SRP fue diseñado precisamente para evitar dicho almacenamiento.
Tenga en cuenta que no hay ningún problema de seguridad de tener varios usuarios distintos en un servidor determinado o los servidores distintos usan el mismo n . Un solo n puede ser adecuado para todo el mundo. RFC 5054 (apéndice A) enumera algunos n de tamaños 1024 a 8192 bits.