¿Qué autenticación al final del protocolo de contraseña remota segura?

"¿Cuántas de estas concatenaciones realmente aumentan la seguridad?"

Por seguridad, asumo que te refieres a la confidencialidad de K.

K está siendo protegido por no enviarlo directamente. Obviamente, si envía K como texto sin formato en un canal inseguro, será interceptado y cualquier cifrado que use K se verá comprometido.

K podría enviarse encriptado, pero eso requeriría otra clave y no nos llevará a ningún lado.

Por lo tanto, el protocolo envía una versión con hash de K. Los hash pueden ser derrotados usando la fuerza bruta o los ataques de la mesa del arco iris. Si se envió H (K), un ataque exitoso sobre H (K) puede revelar K al atacante. Dado que puede haber colisiones para un hash, un ataque exitoso en H (K) puede producir un valor distinto de K. Agregar datos de entrada a un hash hace que sea más difícil atacar exitosamente el hash porque hay un dominio de valores más grande para intentar. Cuanto mayor sea la entrada al hash, más difícil será atacar con éxito. Entonces, la respuesta es que cada concatenación aumenta la seguridad.

"Me imagino que sería igual de seguro si uno reemplaza el XOR con concatenación, por ejemplo."

No sé el propósito de la XOR. Hay debilidades en SHA1 y sospecho que el XOR de H (N) y H (g) está destinado a mitigar la debilidad. Creo que dado que K es un hash de una función de B, g, x, a, u, y N, g y N están hash y XORed para evitar que algún patrón conecte partes de los datos de entrada. Teóricamente, le gustaría tener la mayor cantidad de información posible al ingresar a la función hash y XORing dos valores reduce el tamaño de los datos de entrada en comparación con la concatenación de dos valores. Dado que N y g son públicamente conocidos, XOR no intenta proteger esos valores en caso de un ataque exitoso en el hash.

"¿Cuánta libertad tengo para modificarla sin reducir la seguridad?"

No es posible saber de manera intuitiva cuándo un cambio en el pedido o la operación mejorará o reducirá la seguridad. El supuesto seguro es que cualquier cambio reducirá la seguridad. Tome nota de la frecuencia de los anuncios sobre los cambios en los algoritmos que mejoran la seguridad en comparación con la frecuencia de los anuncios sobre los algoritmos que rompen los ataques. Mejorar la seguridad del algoritmo es difícil. Lea Cómo romper MD5 y otras funciones de hash , y luego encuentre los errores que cometieron los autores. Las condiciones suficientes de Wang para MD5 no son suficientes es al menos un artículo crítico de los hallazgos de los primeros artículos.

Al final de SRP, el cliente y el servidor se implícitamente se autentican entre sí. "Implícito" significa: "No sé si hablé con alguien que realmente conoce el secreto compartido, pero sé que él conoce la clave simétrica que acabo de recibir del protocolo solo si conoce el secreto compartido". Si quiere asegurarse de eso, desafíe a su compañero: haga que use la clave simétrica.

Ahora no es tan fácil como parece. En particular, un atacante podría intentar hacer que una máquina hable a sí misma. Para garantizar la seguridad, derivará varias claves simétricas de la que produjo SRP: una clave para cifrar del cliente al servidor, otra clave distinta del servidor al cliente. Y un par de llaves para verificaciones de integridad, también. Es difícil hacerlo bien, por lo que es altamente recomendado usar un protocolo donde todos esos detalles se afinaron dolorosamente durante años de ataques y contraataques, a saber, TLS. ¿Hablé sobre RFC 5054 ? TLS incluye los mensajes Finished que son, básicamente, los desafíos de los que estoy hablando. Cuando una máquina ha recibido un mensaje Finished del interlocutor y se puede procesar (MAC apropiado, valor apropiado cuando se descifra), el interlocutor está debidamente autenticado explícitamente .

Como señaló Thomas Pornin, debería preferir el RFC (especificación del ingeniero) sobre el papel (especificación del criptógrafo). Si el RFC5054 no funciona para usted, use 2945.

Por lo poco que sé de los protocolos criptográficos, los valores A, B, M son críticos para evitar que el adversario modifique el orden de los mensajes y su reproducción en las mismas conexiones o en conexiones paralelas con el mismo u otros hosts.

Los valores H (N) y H (g) no se usan en el documento original porque creo que son parámetros comunes allí, mientras que en la práctica estos parámetros de grupo se seleccionan mediante una negociación de protocolo inicial. Por lo tanto, los ataques pueden ser posibles si el parámetro cambia repentinamente. Un servidor de la vida real puede incluso tener múltiples valores de verificador de SRP para cada usuario para cada uno de los valores de verificador compatibles (g, N), o incluso valores múltiples para cada uno con diferentes "s". Supongo que Tom Wu los integró en el hash para asegurar que la seguridad del protocolo sea independiente de tales configuraciones extrañas, que es cómo deberían diseñarse tales protocolos. Tal vez ni siquiera identificó un ataque específico, pero solo lo hizo por "buena forma".

Quizás, ojalá, solo hayas olvidado arreglar tu explicación de U, pero:

Usted escribe que U es "privado" en su caso, pero que el hachís salado y la sal son públicos. El último bit, que el valor del verificador es público, es muy extraño y no está previsto en SRP. Los valores del verificador público solo ocurren después de que el servidor se comprometa. En este caso, SRP es tan seguro como un intercambio de desafío-respuesta basado en hash estándar: el valor del verificador es vulnerable a la fuerza bruta sin conexión.

Si la contraseña (P?) es muy fuerte, esto no es una preocupación, de lo contrario es un gran problema. En cualquier caso, no estás mejor que con la respuesta de desafío estándar.

U no puede ser "privado", se transfiere claramente en el primer paso.