Resumen

  • RFC 9529 publica entradas, mensajes, hashes de transcripción, PRK, cifrados, exportadores, parámetros OSCORE y ejemplos inválidos para comparar una implementación byte a byte.
  • Reproducir cada valor demuestra ese recorrido de cálculo; no acredita aleatoriedad fresca, custodia de claves, validación exhaustiva, autoridad de la credencial ni el efecto de una sesión en vivo.
  • Una garantía útil enlaza cinco recibos: reproducción del vector, cobertura negativa, entropía y custodia, identidad y política, y resultado operativo.

La canalización de integración no encontró una sola diferencia. Desde message_1 hasta PRK_exporter y el secreto maestro de OSCORE, cada valor coincidía. El tablero resumió cientos de comprobaciones con una frase: EDHOC verificado.

Sin embargo, el equipo reutilizaba la misma clave privada efímera después de cada reinicio.

La escena es ilustrativa, no un incidente atribuido. Sirve para medir la autoridad del ensayo. RFC 9529 contiene trazas anotadas de EDHOC con entradas, salidas y resultados intermedios, verificadas por dos implementaciones independientes. Permiten hallar el primer punto de divergencia en vez de discutir sobre un único semáforo final.

No pueden certificar una propiedad que el vector fijo nunca varió.

Una cadena larga se vuelve inspeccionable

EDHOC está pensado para entornos restringidos, pero combina selección de método y suite, identificadores de conexión, Diffie-Hellman efímero, credenciales, hashes de transcripción, entradas de MAC o firma, cifrado autenticado, exportadores y parámetros OSCORE.

La primera traza autentica con firmas, identifica certificados X.509 mediante x5t, emplea X25519 para DH efímero y EdDSA. La segunda usa autenticación DH estática, credenciales CCS identificadas por kid, P-256 y una negociación que incluye un error y un segundo message_1.

El RFC imprime los insumos y resultados de TH_2, TH_3 y TH_4, las PRK intermedias, textos claros y cifrados, datos asociados, PRK_out, PRK_exporter, secreto y salt maestros de OSCORE y valores posteriores a KeyUpdate. Una diferencia puede rastrearse hasta una secuencia CBOR, una credencial, una suite o un contexto KDF.

Ese es el enunciado autorizado: con estas entradas, el cálculo especificado produce estos bytes.

Las claves publicadas pertenecen al laboratorio

La reproducibilidad exige entradas fijas. Por eso RFC 9529 muestra claves privadas cuando hacen falta y advierte que no son secretas ni deben usarse. El vector necesita secretos conocidos; el despliegue necesita secretos impredecibles, generados y retenidos bajo control. Los mismos bytes no cumplen ambas funciones.

Un resultado verde no mide la salud del generador aleatorio, la independencia entre reinicios, la extracción de claves, el borrado de memoria, el aislamiento de hardware o la separación entre sesiones simultáneas. Esas propiedades requieren pruebas propias.

El expediente debe guardar el identificador del vector, la versión y la plataforma junto con recibos separados de entropía, procedencia de la clave, custodia, reinicio, clonación y concurrencia. “RFC 9529 pasó” no sustituye esa información.

Igualar la transcripción no identifica al par vivo

Los hashes de transcripción son uniones potentes. TH_2 incorpora la clave efímera del respondedor y el hash de message_1; los estados posteriores añaden texto autenticado y credenciales. Cualquier cambio altera derivaciones y cifrados.

Pero la traza entrega de antemano la credencial y su clave. En producción hay que resolver x5t o kid, validar según la política correcta, asociar la credencial con un dispositivo o principal y decidir qué puede hacer. Una autenticación criptográfica válida puede coexistir con una asignación de identidad o autorización equivocada.

Tampoco el exportador es el desenlace. Derivar material OSCORE no prueba que un mensaje posterior se aceptó, que funcionó la protección contra repetición, que una lectura era reciente o que un actuador cambió de estado. Es evidencia anterior al evento.

Los ejemplos inválidos son una muestra

La sección 4 incluye mensajes que una implementación no debe componer y que debe o puede rechazar: array CBOR donde corresponde una secuencia, envoltorios superfluos, número o tipo de elementos incorrecto, clave efímera codificada como texto y formas CBOR no deterministas.

Los errores criptográficos abarcan longitud errónea, coordenada fuera del campo, punto ajeno a la curva, punto Curve25519 de orden bajo, MAC corto y omisión de un cero inicial.

El documento los llama una pequeña selección. Invalididades semejantes pueden aparecer en otros campos y mensajes. Rechazar la lista publicada no prueba seguridad ante toda profundidad, longitud, transición o consumo de recursos. Fuzzing, propiedades, comparación diferencial, límites de recursos y revisión de código cubren otras dimensiones.

La promesa auditable es “rechaza estos casos de RFC 9529”. “Resiste entradas EDHOC malformadas” necesita un cuerpo de pruebas mucho mayor.

CBOR determinista forma parte del estado criptográfico

Algunas discrepancias parecen criptográficas y nacen en la codificación. El RFC separa bytes crudos de su representación CBOR y recuerda que secuencias y arrays contienen elementos ya codificados. Entre sus errores están enteros innecesariamente largos y arrays de longitud indefinida cuando se exige determinismo.

No es estética. Hashes, firmas, MAC y KDF consumen bytes. Dos estructuras que un depurador muestra iguales pueden producir estados distintos si su codificación cambia.

Por ello el recibo debe conservar el mensaje crudo, la decisión de codificación, la primera divergencia, la suite y el tipo de credencial. Registrar solo el objeto decodificado puede borrar la causa.

Interoperabilidad no significa cobertura universal

Dos implementaciones independientes coincidieron con las trazas. Eso reduce el riesgo de convertir una convención privada en norma y constituye evidencia real.

Sigue siendo acuerdo sobre ejemplos seleccionados. No prueba todas las suites, métodos, credenciales, EAD o rutas de error. El registro EDHOC de IANA asigna significado a valores; no certifica que un producto los implemente ni que una operación deba habilitarlos.

El estándar y las trazas son un mínimo portátil. El alcance, la política, el mantenimiento y el comportamiento ante fallos siguen siendo responsabilidad local.

Cinco recibos hacen una garantía

El primero documenta la reproducción: vector, versión, plataforma, compilador, backend y primera diferencia. El segundo documenta casos negativos: qué se rechazó, dónde, con qué coste y en qué estado quedó la sesión.

El tercero cubre entropía y custodia: salud, repetición tras reinicio o clonación, origen de claves, aislamiento y borrado. El cuarto cubre identidad y permiso: resolución de x5t o kid, ancla, reglas, principal, métodos y acciones autorizadas.

El quinto documenta la realidad: par, sesión, repetición, uso del exportador, contexto OSCORE, mensaje protegido y efecto observado.

La separación de capas de Heng Lu evita que un símbolo ocupe el lugar de un estado. La especificación no es la implementación; el cálculo correcto no es una clave fresca; la credencial válida no autoriza por sí sola; el secreto derivado no es el resultado. La unión de recibos preserva causalidad.

Lo que no acreditan las fuentes

Las fuentes no señalan a un proveedor que haya repetido claves, ni ofrecen cifras de adopción, fallos de flota o canales laterales. La apertura es una hipótesis de control.

Lejos de restar valor al RFC, el límite explica por qué es útil. La traza convierte un cálculo opaco en evidencia ejecutable. El despliegue debe aportar lo que ocurre después.

Fuentes