Nota
Soportado desde la versión 0.9.49. Despliegue en red y pruebas en progreso. Sujeto a revisiones menores. Ver propuesta 156 .
Resumen
Este documento especifica el cifrado de mensajes garlic encryption para routers ECIES, utilizando primitivas criptográficas introducidas por ECIES-X25519 . Es una parte de la propuesta 156 general para convertir routers de claves ElGamal a claves ECIES-X25519. Esta especificación está implementada desde la versión 0.9.49.
Para una descripción general de todos los cambios requeridos para routers ECIES, consulta la propuesta 156 . Para mensajes garlic a destinos ECIES-X25519, consulta ECIES-X25519 .
Primitivas Criptográficas
Las primitivas requeridas para implementar esta especificación son:
- AES-256-CBC como en Criptografía
- Funciones STREAM ChaCha20/Poly1305: ENCRYPT(k, n, plaintext, ad) y DECRYPT(k, n, ciphertext, ad) - como en NTCP2 , ECIES-X25519 , y RFC-7539
- Funciones DH X25519 - como en NTCP2 y ECIES-X25519
- HKDF(salt, ikm, info, n) - como en NTCP2 y ECIES-X25519
Otras funciones Noise definidas en otro lugar:
- MixHash(d) - como en NTCP2 y ECIES-X25519
- MixKey(d) - como en NTCP2 y ECIES-X25519
Diseño
El ECIES Router SKM no necesita un Ratchet SKM completo como se especifica en ECIES para Destinations. No hay requisito para mensajes no anónimos usando el patrón IK. El modelo de amenazas no requiere claves efímeras codificadas con Elligator2.
Por lo tanto, el router SKM utilizará el patrón “N” de Noise, el mismo que se especifica en Prop152 para la construcción de túneles. Utilizará el mismo formato de payload que se especifica en ECIES para Destinations. No se utilizará el modo de clave estática cero (sin enlace o sesión) de IK especificado en ECIES .
Las respuestas a las consultas serán cifradas con una etiqueta ratchet si se solicita en la consulta. Esto está documentado en Prop154 , ahora especificado en I2NP .
El diseño permite que el router tenga un único ECIES Session Key Manager. No hay necesidad de ejecutar Session Key Managers de “clave dual” como se describe en ECIES para los Destinations. Los routers solo tienen una clave pública.
Un router ECIES no tiene una clave estática ElGamal. El router aún necesita una implementación de ElGamal para construir túneles a través de routers ElGamal y enviar mensajes cifrados a routers ElGamal.
Un router ECIES PUEDE requerir un Administrador de Claves de Sesión ElGamal parcial para recibir mensajes etiquetados con ElGamal recibidos como respuestas a búsquedas NetDB de routers floodfill anteriores a la versión 0.9.46, ya que esos routers no tienen una implementación de respuestas etiquetadas con ECIES como se especifica en Prop152 . Si no es así, un router ECIES puede no solicitar una respuesta cifrada de un router floodfill anterior a la versión 0.9.46.
Esto es opcional. La decisión puede variar en varias implementaciones de I2P y puede depender de la cantidad de la red que se haya actualizado a 0.9.46 o superior. A la fecha, aproximadamente el 85% de la red es 0.9.46 o superior.
Marco de Protocolo Noise
Esta especificación proporciona los requisitos basados en el Noise Protocol Framework (Revisión 34, 2018-07-11). En la terminología de Noise, Alice es la iniciadora y Bob es el respondedor.
Se basa en el protocolo Noise Noise_N_25519_ChaChaPoly_SHA256. Este protocolo Noise utiliza las siguientes primitivas:
- Patrón de Handshake Unidireccional: N - Alice no transmite su clave estática a Bob (N)
- Función DH: X25519 - X25519 DH con una longitud de clave de 32 bytes según se especifica en RFC-7748 .
- Función de Cifrado: ChaChaPoly - AEAD_CHACHA20_POLY1305 según se especifica en RFC-7539 sección 2.8. Nonce de 12 bytes, con los primeros 4 bytes establecidos en cero. Idéntico al usado en NTCP2 .
- Función Hash: SHA256 - Hash estándar de 32 bytes, ya usado extensivamente en I2P.
Patrones de Handshake
Los handshakes utilizan patrones de handshake Noise .
Se utiliza la siguiente correspondencia de letras:
- e = clave efímera de un solo uso
- s = clave estática
- p = carga útil del mensaje
La solicitud de construcción es idéntica al patrón Noise N. Esto también es idéntico al primer mensaje (Solicitud de Sesión) en el patrón XK utilizado en NTCP2 .
<- s
...
e es p ->
Cifrado de mensajes
Los mensajes se crean y se cifran asimétricamente hacia el router de destino. Este cifrado asimétrico de mensajes es actualmente ElGamal como se define en Cryptography y contiene una suma de verificación SHA-256. Este diseño no es forward-secret (sin secreto hacia adelante).
El diseño ECIES utiliza el patrón Noise unidireccional “N” con DH (intercambio de claves Diffie-Hellman) efímero-estático ECIES-X25519, con un HKDF, y AEAD ChaCha20/Poly1305 para secreto hacia adelante, integridad y autenticación. Alice es el remitente anónimo del mensaje, un router o destino. El router ECIES objetivo es Bob.
Cifrado de respuesta
Las respuestas no son parte de este protocolo, ya que Alice es anónima. Las claves de respuesta, si las hay, se incluyen en el mensaje de solicitud. Consulta la especificación I2NP para los Mensajes de Búsqueda en Base de Datos.
Las respuestas a los mensajes Database Lookup son mensajes Database Store o Database Search Reply. Se cifran como mensajes de Sesión Existente con la clave de respuesta de 32 bytes y la etiqueta de respuesta de 8 bytes como se especifica en I2NP y Prop154 .
No hay respuestas explícitas a los mensajes Database Store. El remitente puede agrupar su propia respuesta como un Garlic Message hacia sí mismo, conteniendo un mensaje Delivery Status.
Especificación
X25519: Ver ECIES .
Identidad del Router y Certificado de Clave: Ver Estructuras Comunes .
Cifrado de Solicitudes
El cifrado de la solicitud es el mismo que el especificado en Tunnel-Creation-ECIES y Prop152 , usando el patrón “N” de Noise.
Las respuestas a las búsquedas se cifrarán con una etiqueta ratchet si se solicita en la búsqueda. Los mensajes de solicitud de búsqueda en la base de datos contienen la clave de respuesta de 32 bytes y la etiqueta de respuesta de 8 bytes según se especifica en I2NP y Prop154 . La clave y la etiqueta se utilizan para cifrar la respuesta.
Los conjuntos de etiquetas no se crean. El esquema de clave estática cero especificado en ECIES-X25519-AEAD-Ratchet Prop144 y ECIES no se utilizará. Las claves efímeras no se codificarán con Elligator2.
Generalmente, estos serán mensajes de Nueva Sesión y se enviarán con una clave estática cero (sin vinculación o sesión), ya que el remitente del mensaje es anónimo.
KDF para ck y h iniciales
Este es el protocolo Noise estándar para el patrón “N” con un nombre de protocolo estándar. Es el mismo que se especifica en Tunnel-Creation-ECIES y Prop152 para los mensajes de construcción de tunnel.
This is the "e" message pattern:
// Define protocol_name.
Set protocol_name = "Noise_N_25519_ChaChaPoly_SHA256"
(31 bytes, US-ASCII encoded, no NULL termination).
// Define Hash h = 32 bytes
// Pad to 32 bytes. Do NOT hash it, because it is not more than 32 bytes.
h = protocol_name || 0
Define ck = 32 byte chaining key. Copy the h data to ck.
Set chainKey = h
// MixHash(null prologue)
h = SHA256(h);
// up until here, can all be precalculated by all routers.
KDF para Mensaje
Los creadores de mensajes generan un par de claves X25519 efímero para cada mensaje. Las claves efímeras deben ser únicas por mensaje. Esto es lo mismo que se especifica en Tunnel-Creation-ECIES y Prop152 para mensajes de construcción de tunnel.
// Target router's X25519 static keypair (hesk, hepk) from the Router Identity
hesk = GENERATE_PRIVATE()
hepk = DERIVE_PUBLIC(hesk)
// MixHash(hepk)
// || below means append
h = SHA256(h || hepk);
// up until here, can all be precalculated by each router
// for all incoming messages
// Sender generates an X25519 ephemeral keypair
sesk = GENERATE_PRIVATE()
sepk = DERIVE_PUBLIC(sesk)
// MixHash(sepk)
h = SHA256(h || sepk);
End of "e" message pattern.
This is the "es" message pattern:
// Noise es
// Sender performs an X25519 DH with receiver's static public key.
// The target router
// extracts the sender's ephemeral key preceding the encrypted record.
sharedSecret = DH(sesk, hepk) = DH(hesk, sepk)
// MixKey(DH())
//[chainKey, k] = MixKey(sharedSecret)
// ChaChaPoly parameters to encrypt/decrypt
keydata = HKDF(chainKey, sharedSecret, "", 64)
// Chain key is not used
//chainKey = keydata[0:31]
// AEAD parameters
k = keydata[32:63]
n = 0
plaintext = 464 byte build request record
ad = h
ciphertext = ENCRYPT(k, n, plaintext, ad)
End of "es" message pattern.
// MixHash(ciphertext) is not required
//h = SHA256(h || ciphertext)
Carga útil
La carga útil tiene el mismo formato de bloque definido en ECIES y Prop144 . Todos los mensajes deben contener un bloque DateTime para la prevención de repetición.
Notas de Implementación
- Los routers más antiguos no verifican el tipo de cifrado del router y enviarán mensajes cifrados con ElGamal. Algunos routers recientes tienen errores y enviarán varios tipos de mensajes malformados. Los implementadores deberían detectar y rechazar estos registros antes de la operación DH si es posible, para reducir el uso de CPU.