RFC 6637: Campos específicos de algoritmo para ECDH

Question

RFC 6637: Campos específicos de algoritmo para ECDH

#1 de Thomas Pornin (3 votos)

5

Estoy tratando de integrar RFC 6637 en Bouncy Castle C # que es más desafiante como se pensó inicialmente porque tanto la clave privada como la pública deben estar presentes para calcular el secreto de la acción: que no encajen en la API del castillo hinchable.

De todos modos, La Sección 10 de la RFC define una clave pública que se debe codificar en el Público. Paquete de claves de sesión cifrada clave. ¿Es esta la clave pública del remitente o del receptor? De cualquier manera, ¿por qué el OID no es parte de él? Porque sin el OID, el punto es más o menos inútil.

ACTUALIZACIÓN: Acabo de usar la herramienta Symantec Pgp Command Line para volcar los paquetes de archivos cifrados con ecc. Ahora comprendo un poco más: para cada cifrado, el remitente genera una nueva clave ECDH que coincide con la curva del receptor y envía la nueva clave pública como parte del paquete.

ACTUALIZACIÓN 2:

RFC 6637 ahora es totalmente compatible. Consulta el repositorio .

pgp ecc

pregunta esskar 12.05.2013 - 02:15

fuente

1 respuesta

Lea otras preguntas en las etiquetas pgp ecc

Limpie el disco duro inaccesible antes de volver al proveedor ¿Cómo evito que XSS tenga acceso directo a las API de AJAX / JSON?

score 3 · Accepted Answer

En el Diffie-Hellman , el remitente y el destinatario deben jugar en el mismo grupo: - En el caso de ECDH, la misma curva. Las personas con pares de claves no a priori comparten los mismos parámetros de grupo (aunque en el caso de las curvas elípticas, hay muy pocas "curvas estándar"). Si los pares de claves del remitente y del receptor usan la misma curva, pueden usarla para calcular una clave compartida, pero, en general, esto no se puede asumir.

Además, PGP sigue el contexto del correo electrónico, que es unidireccional: se envía un solo mensaje desde el remitente al receptor, y el receptor no recibe notificación de la transacción hasta que el correo electrónico se emite realmente. El receptor es entonces completamente estático durante toda la operación. Por lo tanto, el remitente y el receptor deben usar el grupo del par de claves del receptor.

Se deduce que el remitente debe (normalmente) crear un nuevo par de claves, considerado "efímero" (esa es la palabra importante en la sección 10 de RFC 6637), solo para ese envío de correo electrónico, en El mismo grupo que la clave del receptor. El remitente no almacenará esa clave (de ahí la denominación). El mensaje debe incluir la parte pública del par de claves efímeras del remitente, es decir, un punto de curva; la curva OID no se debe especificar porque, por definición, se utiliza la curva del receptor: el receptor ya lo sabe.

Nota: dado que el remitente utiliza un par de claves efímeras totalmente nuevas, ECDH no implica la autenticación del remitente. Si el remitente desea demostrar su identidad al destinatario, debe también firmar su correo electrónico, con su propio par de claves de firma no efímeras.