¿Es posible probar qué clave pública se utilizó para cifrar un mensaje?

"Probar" depende de si el destinatario (Bob) coopera (es decir, acepta revelar su clave privada al verificador), y también del tipo de algoritmos criptográficos y detalles de la clave.

Si Bob coopera , entonces puede descifrar el mensaje; esto puede mostrar que el mensaje "tiene sentido" cuando se descifra con la clave privada de Bob, lo cual es un indicio bastante fuerte de que Bob tenía la intención de ser el destinatario, o al menos como un destinatario a . Esto depende de lo que califica como "tener sentido", por supuesto. La mayoría de los sistemas de encriptación asimétrica son híbrido : un intercambio de claves asimétricas produce una clave específica del mensaje compartida entre remitente y receptor, y la clave se utiliza para cifrar los datos reales del mensaje. Si el cifrado utiliza (como debería) un MAC para detectar alteraciones, esto se puede convertir en una prueba convincente de que El remitente realmente trabajó con la clave pública de Bob en mente (pero depende de los algoritmos exactos empleados).

Tenga en cuenta que, dependiendo de los algoritmos utilizados, Bob puede tomar un mensaje existente y calcular su propio par de claves para que el mensaje (como una secuencia de bytes), cuando descifrado con su nueva clave privada, descifra un mensaje de su elección. Por lo tanto, el cifrado asimétrico no puede, en general, considerarse equivalente a una reclamación de propiedad.

Si Bob no no coopera , las cosas pueden ser complicadas. Ahora estamos en el modelo de análisis de tráfico , donde un atacante intenta ver a través de comunicaciones anónimas. En ese modelo, Bob no es un atacante potencial, sino una víctima potencial. Ocultar la identidad del destinatario no es una propiedad principal del cifrado asimétrico y los sistemas de intercambio de claves. Si consideramos el cifrado asimétrico con RSA, entonces la clave tamaño se filtra, ya que coincide con el tamaño del mensaje cifrado; Esto puede reducir el número de posibles destinatarios.

Como un caso más extremo, considere Diffie-Hellman . DH se calcula en un grupo dado, que consiste en un módulo primo p , un tamaño de subgrupo q ( q se divide p-1 y normalmente es primo) y un generador de subgrupos g ( g tiene el orden q , lo que significa que g ^q = 1 mod p ). Estos valores (los "parámetros de grupo") son parte de la clave pública de Bob. El mensaje comenzará primero con un valor B = g ^b mod p , con un exponente elegido al azar b : ese valor es un elemento de subgrupo Para un mensaje cifrado asimétrico dado, es fácil mirar el encabezado, ver el valor B y verificar si coincide con un determinado ( p, q, g ) DH especificación del grupo: simplemente calcula B^q mod p ; para el grupo correcto, producirá 1 , pero (con una probabilidad abrumadora) no para un grupo distinto.

Entonces, si los posibles destinatarios usan Diffie-Hellman y cada uno genera su propio grupo, esta simple prueba señalará al destinatario real. Por otro lado, si varios destinatarios deciden generar sus respectivos pares de claves dentro del grupo same (que está permitido en DH y no incurre en ninguna debilidad de seguridad), los forasteros no ser capaz de determinar qué destinatario es el correcto: hacerlo implicaría resolver el Decisional Diffie-Hellman problema, que es difícil (no conocemos ninguna forma de resolver DDH, en un grupo DH normal, excepto a través de Discrete Logaritmo , que se ve frustrado por el tamaño suficiente p y q ).

Además, la localización precisa no está demostrando. Cualquiera puede tomar una copia de los parámetros del grupo DH de Bob (son parte de la clave pública de Bob, por lo tanto ellos mismos son públicos) y generar su propio par de claves dentro del mismo grupo. Por lo tanto, ser capaz de reconocer el grupo de Bob en un mensaje dado no demuestra que solo Bob pudo leer el mensaje; el mensaje podría estar dirigido a otra persona cuya clave funcione en el mismo grupo.

(Tener muchas claves en el mismo grupo es una ocurrencia muy común cuando se usa la versión de curva elíptica de DH, porque generar su propia curva es un trabajo duro y limita severamente la interoperabilidad).

Voy a adoptar un enfoque diferente en mi respuesta aquí. Usted declara: " pruebe que el texto cifrado fue cifrado con la clave pública de Bob " Yo digo, ¿cómo está seguro de que es la clave de Bob? Debido a la estructura de los servidores de claves públicas ( enlace ), no hay nada que me impida hacer una clave que pretende ser "Bob". Tampoco hay MECANISMO para validar que Bob es el último período de destinatarios. P.ej. Consulte aquí: enlace

¿Cuál es el final del juego final con esta pregunta? ¿Es eso del repudio? Aunque me gustó la respuesta de Tom Leek, mi respuesta es una de " amenaza " en la que el propósito es ilustrar que NO PUEDE finalmente confiar en el cifrado. No hay ningún mecanismo para validar quién puso la clave en ese servidor. Puede citar MIT en esperanzas que están registrando, pero ¿entiendes qué? Una IP. Esto no tiene sentido.

Para profundizar en esto, las claves privadas pueden verse comprometidas con un registrador de pulsaciones de teclas, malware, etc. Así es como los autores de malware que se han dirigido a "distros" (Debian, FreeBSD, etc.) han logrado colarse en trozos de basura en todo los años. Horrible gestión de claves.

Usando solo RSA como se implementa actualmente, no, esto no es posible. La única forma en que Eve pudo probar que el mensaje se cifró con la clave pública de Bob es descifrarlo con la clave privada de Bob, y eso anula todo el propósito de la criptografía de clave pública (mantener la clave del par que demuestre que eres tú, la "clave privada", privada).

Hay mecanismos disponibles que permiten que alguien aprenda algo sobre el mensaje sin descifrarlo completamente. Considere un esquema en el que Alice encripta el mensaje real usando la clave pública de Bob, luego toma ese mensaje, agrega información de "encabezado" no confidencial que incluye la fuente y el destinatario deseado, luego firma el paquete completo con el algoritmo de firma digital utilizando el propio Alice. llave privada. Cualquiera que conozca la clave pública de Alice (y esa es información pública) puede verificar la firma digital y, por lo tanto, puede saber que Alice envió este mensaje exactamente como lo tiene actualmente, incluida la información sobre el destinatario deseado. Todavía no pueden ver el mensaje, ni pueden probar que el mensaje realmente fue cifrado con la clave pública de Bob, pero de todos modos eso no es asunto suyo; Si Bob no puede descifrarlo, entonces puede decirle a Alice que ella cometió un error.

Con una modificación adicional para cifrar simétricamente el mensaje real, y luego cifrar la clave de ese mensaje de forma asimétrica con la clave pública del destinatario, esta es la idea básica detrás de PGP. Hay información inherente al tránsito de correo electrónico que simplemente debe ser claramente visible para poder enviar el correo electrónico al destinatario. Pero es valioso poder probar quién lo envió, cuáles fueron sus intenciones y que nadie lo manipuló antes de intentar leer el contenido real.

Otra capa de complejidad detrás de todo esto es cómo probar que la clave pública de cualquiera es realmente suya; esto se logra con la firma de la clave, donde una entidad confiable confirma la validez de la información agregando información que solo alguien que conoce la clave privada de la entidad podría producir (ya sea una firma DSA o un hash criptográfico que luego se cifra con la clave privada de la entidad). ). En SSL / TLS, la firma forma una "cadena de confianza" jerárquica, con una CA que avala el certificado de un usuario final, otra CA que avala el certificado de esa CA, y así sucesivamente, lo que lleva de vuelta a uno de los certificados de "raíz confiable" distribuidos con su navegador web o sistema operativo, en el que debe confiar si va a utilizar el sistema. En PGP es una estructura de "red de confianza" más plana, donde los compañeros que se conocen y confían entre sí firman las claves de los demás en un entorno seguro y luego los distribuyen a otras personas que conocen y confían en el firmante, por lo que pueden confiar en el certificado.