Resumen

  • El CFRG publicó el 7 de septiembre de 2026 la revisión 14 de draft-irtf-cfrg-pairing-friendly-curves. Es un Internet-Draft activo de un grupo de investigación de la IRTF, previsto como documento Informativo; no es un RFC ni un estándar del IETF.
  • La revisión define procedimientos normativos para serializar y deserializar puntos BLS12-381 y BLS48-581, y escalares de esas curvas y de BN462. La salida es un elemento del grupo o INVALID tras comprobar canonicidad, curva y subgrupo.
  • El protocolo que usa esas rutinas conserva tres decisiones: qué forma de punto acepta, si admite el elemento identidad y si admite el escalar cero. Las dos últimas son independientes.
  • Frente a la revisión 13, la nueva versión elimina una recomendación universal de rechazar la identidad, separa el cero de esa regla e incorpora la elección explícita de forma de punto. No fija un formato normativo para puntos BN462 porque las prácticas estudiadas no han convergido.
  • Daniel Kade propone que los documentos dependientes publiquen un perfil de aceptación de siete campos. Es una recomendación analítica, no una exigencia del borrador ni del CFRG.

El descodificador no conoce la semántica de la aplicación

Validar puede significar dos cosas distintas. En la capa matemática, hay que comprobar que los bytes tienen la longitud y las marcas correctas, que la coordenada es canónica, que el punto pertenece a la curva indicada y que está dentro del subgrupo exigido. En la capa del protocolo, hay que decidir si ese valor válido está permitido en un mensaje, una clave o una prueba concreta.

La revisión 14 fortalece la primera capa. Sus rutinas rechazan coordenadas iguales o superiores al módulo en vez de reducirlas. Reconstruyen el punto, comprueban su pertenencia a la curva y ejecutan la prueba de subgrupo. Mantienen separados tipos de punto aunque compartan longitud de representación. El resultado contractual de la rutina común es claro: un elemento del grupo o INVALID.

Con los escalares ocurre algo paralelo. El entero codificado debe ser inferior al orden del campo escalar, lo que deja una representación única. Cero es un escalar canónico. Sin embargo, su presencia puede carecer de sentido o ser peligrosa en un campo determinado. Esa segunda respuesta solo puede darla el protocolo que conoce la operación.

Por eso dos implementaciones pueden cumplir el mismo documento de curvas y no interoperar. La rutina común les entrega el mismo objeto matemático; una lo acepta y otra lo rechaza, o ambas lo aceptan pero conservan bytes diferentes como identidad del objeto.

Tres decisiones que no deben esconderse bajo «valor no nulo»

La primera es la forma del punto. La revisión pide que el protocolo declare si recibe puntos comprimidos, no comprimidos o ambos. La aceptación dual permite dos cadenas de bytes para el mismo punto. Si los bytes de entrada se firman, se incluyen en un hash, se comparan directamente o forman una clave de caché, esa libertad puede producir resultados distintos sin que ninguna curva esté mal implementada.

La segunda es el elemento identidad. Algunas construcciones tienen un motivo específico para excluirlo. El borrador de firmas BLS, por ejemplo, impide que la validación de claves acepte la identidad, relacionada con la clave secreta cero inválida y la firma identidad. En otra construcción, el elemento neutro puede participar legítimamente. La revisión 14 no establece un valor predeterminado universal: remite la decisión a la semántica y al modelo de amenazas.

La tercera es el escalar cero. La revisión 13 presentaba el rechazo de la identidad como opción recomendada por defecto y vinculaba la política del cero con la de la identidad. La revisión 14 deshace esa unión. RFC 9591 ayuda a ver la diferencia: su deserialización de elementos rechaza la identidad, mientras que la de escalares no añade un rechazo equivalente del cero.

No hay una combinación obligatoria. Un protocolo puede exigir compresión, rechazar la identidad y aceptar cero en cierto campo. Otro puede admitir ambas formas de punto, utilizar la identidad en una operación y excluir cero. Convertir esas opciones en una sola casilla de biblioteca borra información que pertenece al contrato del protocolo.

BN462 muestra el límite deliberado de la regla común

El texto define la codificación de puntos para BLS12-381 y BLS48-581, pero no para BN462. El módulo del campo base de BN462 ocupa 462 bits. Una cadena de 58 bytes ofrece 464 bits, solo dos libres, mientras que el formato comprimido común necesita tres indicadores.

El apéndice informativo recoge esquemas incompatibles en programas existentes: un byte de tipo al estilo SEC1, un byte separado para banderas y representaciones empaquetadas sin la misma convención. Los autores señalan que las especificaciones examinadas no necesitan una codificación de puntos BN462 y que no existe una práctica convergente. En vez de declarar vencedor a uno de esos esquemas, la revisión 14 no define ninguno como ruta normativa.

La ausencia no equivale a decir que BN462 carece de implementaciones, que sus formatos sean vulnerables o que todos deban cambiar. Significa algo más preciso: una especificación que envíe puntos BN462 necesita nombrar otra norma de codificación o escribir su propia convención. Citar solo la revisión 14 dejaría incompleto el contrato de bytes.

La autonomía local exige una declaración local

El historial explica por qué se buscó una definición central. La incidencia 74 del repositorio pedía una fuente autorizada para evitar copias inconsistentes. La solicitud de cambios 108 llevó a la revisión 14 procedimientos con nombre, controles de pertenencia, decisiones del protocolo y vectores de prueba. Mensajes en la lista del CFRG avisaron a autores de documentos dependientes. Los borradores de firmas BBS y de representación COSE de claves BLS muestran usos reales de esa dependencia.

Un núcleo común reducido puede estabilizar las matemáticas sin decidir la semántica de cada aplicación. Esa división coincide con una gobernanza modular solo cuando la parte local es pública. Una opción que vive únicamente en el valor predeterminado de una biblioteca no es una decisión localizada: es una bifurcación invisible.

Mi propuesta es que cada especificación publique un perfil de aceptación con la revisión del documento de curvas, la curva elegida, las formas de punto admitidas, la regla de identidad, la regla del escalar cero, la ruta de validación del subgrupo y, si usa puntos BN462, la referencia externa exacta de codificación. El perfil es una herramienta de Daniel Kade; no aparece como requisito en la revisión 14.

Fuentes