¿De qué manera el secreto hacia adelante supera el cifrado de clave pública si la clave se actualiza regularmente?

Question

¿De qué manera el secreto hacia adelante supera el cifrado de clave pública si la clave se actualiza regularmente?

#1 de puzzlepalace (1 votos)
#2 de Daisetsu (1 votos)

1

¿Por qué el secreto de reenvío es mejor (por ejemplo, para WhatsApp) que el cifrado de clave pública con una clave revisada de forma rutinaria?

El problema anunciado es seguridad al revés: si en un punto se compromete una clave, alguien que almacene el historial de comunicaciones anteriores todavía no podrá descifrar todo ese historial de forma repentina.

Pero considere el siguiente método más simple utilizando el cifrado de clave pública ordinario. Cada vez que el cliente de Bob envía un mensaje, envía junto con ese mensaje una clave pública nueva , una generada algorítmicamente. La clave pública se almacena en el servidor (de WhatsApp). Aquellos que envían mensajes a Bob recuperarían esa clave pública y su cliente cifraría el mensaje que están enviando a Bob usando esa clave. La clave sigue siendo válida hasta que Bob vuelva a enviar un mensaje a cualquiera .

¿Cuál es la debilidad de este enfoque elemental en comparación con el secreto a futuro? Una vez que se comprometa un mensaje bajo secreto hacia adelante, los mensajes subsiguientes se volverán legibles. El método que acabamos de describir sería más fuerte a ese respecto.

forward-secrecy

pregunta Calaf 25.04.2016 - 23:06

fuente

2 respuestas

1

Lo que has descrito es esencialmente lo que hace el secreto hacia adelante. Genera una clave pública aleatoria para cada sesión.

enlace

respondido por el Daisetsu 25.04.2016 - 23:16

fuente

Lea otras preguntas en las etiquetas forward-secrecy

¿Hay algún mecanismo para verificar la exactitud de un disco grabado? ¿Los encabezados de las versiones de IIS / ASP.NET / MVC revelan la presencia de parches?

score 1 · Accepted Answer

Por lo general, el secreto hacia adelante se logra exactamente con lo que usted propone, a saber, las claves públicas efímeras (generalmente Diffie-Hellman). Esto básicamente funciona de la siguiente manera:

Genera algunos parámetros DH.
Firme los parámetros públicos a través de su clave pública a largo plazo.
Envíe los parámetros y su firma sobre los parámetros a cualquier computadora con la que quiera hablar.
Use los parámetros efímeros para generar un secreto compartido a partir del cual derivar claves simétricas.

Si observa el mecanismo de intercambio de claves para la mayoría de las conexiones HTTPS, verá que parte del conjunto de cifrado suele ser ECDHE_RSA, que significa Diffie-Hellman efímero (sobre un grupo de curvas elípticas) con los parámetros firmados mediante RSA (la clave RSA es la clave privada a largo plazo de los servidores para la cual se encuentra la clave pública correspondiente en el certificado de servidores).

Es importante que firme sus claves efímeras con su clave privada a largo plazo, de lo contrario, un atacante podría cargar una clave de su elección para decir los servidores de WhatsApp y leer todos los mensajes destinados a usted, ya que no habría Manera de verificar la legitimidad de las claves efímeras.

Una vez que se comprometa un mensaje bajo secreto hacia adelante, los mensajes subsiguientes se volverán legibles. El método que acabamos de describir sería más fuerte a ese respecto.

Esto no es correcto, solo los mensajes relacionados con la sesión cuyos parámetros efímeros se vieron comprometidos serían legibles. La próxima sesión tendría diferentes parámetros efímeros y aún sería segura.