Haciendo un protocolo de correo seguro tipo bitcoin, ¿cómo abordar las claves públicas?

2

Estoy creando un nuevo protocolo de correo (probablemente ya exista, pero he aprendido muchas cosas sobre seguridad y privacidad en el camino).

Aquí está el resumen (mucho más sencillo si conoce el funcionamiento interno de Bitcoin):

  • Cada usuario tiene una lista de claves públicas y privadas.
  • Cada correo está en un archivo del que cada nodo tiene una copia.
  • los usuarios pueden enviar mensajes usando el siguiente protocolo:
    • mensaje = encrypt("Your message here", receiver.publicKey);
    • firma = sign(message, sender.privateKey);
    • proofOfWork = hashcashAlg(message); vea: hashcash
  • Al enviar un correo nuevo, envía su clave pública, la clave pública del receptor, el mensaje, la firma y proofOfWork a todos los nodos que conozca. Cada nodo envía ese correo a todos los nodos que conocen.

Ahora tengo este problema: las claves públicas (actualmente RSA) son extremadamente largas. Cuando desee enviar un correo a alguien, deberá conocer su clave pública.

¿Hay algún algoritmo de cifrado asimétrico que use claves públicas más pequeñas? ¿O de alguna manera puedo poner la clave RSA larga a través de un RIPEMD160 y aún se puede usar?

    
pregunta user1009013 25.03.2014 - 11:52
fuente

1 respuesta

1
  

Ahora tengo este problema: las claves públicas (actualmente RSA) son extremadamente largas. Cuando desee enviar un correo a alguien, deberá conocer su clave pública.

     

¿Hay algún algoritmo de cifrado asimétrico que use claves públicas más pequeñas? ¿O de alguna manera puedo poner la clave RSA larga a través de un RIPEMD160 y aún se puede usar?

Este es un problema conocido con los sistemas criptográficos de clave pública convencionales, por ejemplo, RSA y DH y, entre otras cosas, una razón por la cual Criptografía de curva elíptica (ECC) es tan atractiva . Los tamaños de clave habituales oscilan entre 160 y 512 bits , al tiempo que ofrecen el mismo nivel de seguridad.

Otra forma potencial de resolver el problema es un esquema similar al implementado en DNSSEC . Aquí tienes dos pares de llaves, que son diferentes en longitud. El más corto debe reemplazarse más a menudo (una vez al mes o algo así), pero es el que realmente está haciendo todas las firmas. Personalmente no me gusta mucho este enfoque, pero se diseñó específicamente de esta manera para hacer que las firmas sean más cortas.

    
respondido por el Karol Babioch 25.03.2014 - 14:24
fuente

Lea otras preguntas en las etiquetas