En la criptografía asimétrica, ¿está limitado el número de claves privadas?

0

Mi pregunta es un poco importante, porque asumo que el número de Claves Privadas es un número finito.

Sin embargo, es posible que el número sea tan grande que, en teoría, nunca se alcanzaría.

Todo esto me lleva a la pregunta real en la que estoy tratando de encontrar la respuesta a:

Pregunta principal

¿Por qué no generar un par de clave privada / clave pública para un solo uso y luego eliminarlos después del uso?

¿Por qué querría hacer eso?

Digamos que quiero enviar algo privado a Alice, pero nunca hemos hablado antes.

  1. Alice abriría la aplicación que desarrollé usando su teléfono y presionó un botón.
  2. Esto se pondría en contacto con mi servidor. El servidor generaría 1 clave privada y 1 clave pública.
  3. Enviaría la clave pública a su aplicación.
  4. Luego vería un formulario donde puede escribir los datos que estoy esperando de ella. Luego presiona un botón para enviar los datos.
  5. La aplicación usaría la clave pública que recibió de mí y cifraría los datos.
  6. la aplicación también creará una nueva clave privada en su teléfono para firmar los datos cifrados.
  7. la aplicación generará una clave pública a partir de su clave privada
  8. finalmente, la aplicación enviaría todos los datos a mi servidor y publicaría su clave pública (para que pueda autenticar que ella envió los datos).
  9. después de que se publicara con éxito, eliminaría su clave privada, la clave pública que le envié y la clave pública que me acaba de enviar.
  10. Finalmente, mi lado de la aplicación autenticaría los datos que recibí, descifraré y eliminaré mi clave privada, la clave pública que envié y su clave pública.

El punto Tendría sus datos seguros que ella quería enviarme. Las claves privadas utilizadas para todo esto nunca podrían volver a utilizarse.

  

Esto ayudaría a aliviar el problema donde está su clave privada   expuesto ya que solo se usa para un intercambio de una sola vez.

¿Por qué no se produce este tipo de cifrado ad hoc?

¿Ofrecería esto una capa adicional de seguridad ya que está basada en el tiempo? Usado una vez para este intercambio en vivo.

¿Se quedaría sin claves privadas? Es poco probable, ya que solo genera otro valor que se utiliza durante un período de tiempo específico.

¿La colisión de la clave privada ocurrirá con más frecuencia? ¿Imagina si millones de personas utilizan una aplicación que hace esto todos los días? ¿Haría que los datos de las personas se descifren accidentalmente con la clave privada de otra persona? Improbable.

¿Sería esta una manera de permitir el intercambio ad hoc de datos privados?

Por último, tengo curiosidad de si esta sería una manera de permitir un intercambio más ad hoc de datos privados de manera segura.

Por ejemplo, Alice llama a Bob y necesita la información de su tarjeta de crédito.

¿No estaría esto más cerca de la idea de un pad de una sola vez? ¿Y ofrecer más seguridad?

    
pregunta raddevus 11.10.2015 - 18:54
fuente

1 respuesta

2

El problema fundamental que parece pasar por alto aquí es que Alice y Bob necesitan algún canal seguro para garantizar que nadie pueda manipular las claves que se están intercambiando. Como se explica en el comentario de Cthulhu, en el escenario particular que describe, un hombre en el medio podría romper la confidencialidad de los mensajes intercambiados al generar su propio par de claves y enviar su propia clave pública a Alice. Una forma de abordar este problema es usar un par de claves a largo plazo, que es la práctica de la que quiere deshacerse.

Para abordar las implicaciones catastróficas de la pérdida de una clave privada a largo plazo, los sistemas de cifrado modernos realmente generan pares de claves por sesión que nunca se almacenan en ninguna memoria permanente. Esta propiedad de un protocolo de acuerdo clave se llama secreto hacia adelante perfecto. En cualquier caso, aún tendrá que confiar en un par de claves a largo plazo para iniciar todo el proceso.

    
respondido por el zinfandel 11.10.2015 - 19:12
fuente

Lea otras preguntas en las etiquetas