Entender el secreto hacia adelante

Question

Recientemente, un amigo me señaló un post, que describía el avance de Google hacia el secreto hacia adelante. Por lo que entiendo, la esencia del secreto hacia adelante parece residir en el hecho de que las claves privadas no se guardan en un almacenamiento permanente.

Tengo varias dudas sobre cómo algo así podría implementarse.

1. ¿Qué ocurre si el servidor se cae sin previo aviso? ¿Es necesario regenerar los pares de claves? ¿La clave pública debe ser firmada nuevamente para crear otro certificado?
2. Podría alguien dirigirme a publicaciones/pdfs donde se describe la implementación de algo como esto. ¿Recursos de lectura sugeridos?
3. ¿Conoces a alguien más que haya implementado secretos a futuro? ¿Has probado algo similar en tu lugar de trabajo?

¡Gracias!

Answer 1

En Reenviar secreto, todavía hay claves a largo plazo. La única implicación es que el compromiso de una clave a largo plazo no permitirá que un atacante comprometa las claves de sesión temporales, cuando la clave a largo plazo ha cambiado. Esto significa que una clave a largo plazo no debe derivarse de de otra clave (anterior).

Here es una buena encuesta sobre este tema.

Según Wikipedia:

• PFS es una característica opcional en IPsec (RFC 2412).
• SSH.
• Off-the-Record Messaging, un protocolo y biblioteca de criptografía para muchos clientes de mensajería instantánea, proporciona un secreto de avance perfecto y una encriptación denegable.
• En teoría, Transport Layer Security puede elegir cifrados apropiados desde SSLv3, pero en la práctica diaria muchas implementaciones se niegan a ofrecer PFS o solo le proporcionan un grado de cifrado muy bajo.

Answer 2

En TLS y muchos otros protocolos, la confidencialidad directa se proporciona a través del algoritmo Diffie-Hellman (DH). Vanilla DH es bastante simple y proporciona un secreto hacia adelante perfecto si los exponentes se generan aleatoriamente cada vez, pero no proporciona autenticación. Por lo tanto, en TLS se usa en combinación con un algoritmo de firma, generalmente RSA.

TLS proporciona muchos servidores de cifrado compatibles con PFS y muchos que no. La mayoría de los clientes de TLS admiten PFS pero muchos servidores no, porque se cree que PFS requiere demasiada CPU.