Resumen

  • La revisión 12 del esquema BBS permite demostrar conocimiento de una firma sobre varios mensajes mientras el titular revela solo los que elige. Su garantía de no enlazabilidad se refiere al valor aleatorizado del proof: header, presentation_header, valores revelados, número total y posiciones, clave del firmante, dirección de red y datos de aplicación pueden seguir actuando como identificadores.
  • ProofVerify=VALID es un recibo criptográfico limitado. No acredita por sí solo identidad humana, diligencia del emisor, vigencia o revocación, suficiencia de lo presentado, autorización, privacidad integral ni resultado operativo.

Un equipo de privacidad ve dos cadenas aleatorias y celebra que no existe una firma estable. Un equipo de riesgo cruza cuatro campos visibles y obtiene una coincidencia casi única. Los dos análisis pueden ser técnicamente correctos. El primero responde si el proof delata la firma subyacente; el segundo responde si la presentación completa puede seguir a una persona.

draft-irtf-cfrg-bbs-signatures-12 resulta valioso porque no esconde esa diferencia. Define una primitiva capaz de firma multimensaje, prueba de conocimiento y divulgación selectiva. Después enumera aquello que queda fuera: encabezados, forma, claves, valores visibles y canal. La limitación no rebaja el diseño; evita que una afirmación precisa se transforme en propaganda.

Los nuevos vectores prueban reproducibilidad, no privacidad operativa

La revisión 12 fue presentada el 28 de septiembre de 2026 como documento activo de CFRG en el flujo IRTF, con intención Informational. Sigue siendo un Internet-Draft. No es un RFC final, una norma Standards Track ni evidencia de adopción, interoperabilidad o conformidad de un producto concreto.

Frente a la revisión 11, la nueva versión sustituye marcadores de plantilla por constantes, escalares, generadores, firmas y pruebas concretas para las ciphersuites. Un implementador puede ejecutar entradas fijas y comparar octeto a octeto. Es una mejora sustancial para detectar errores matemáticos, de serialización o de interfaz.

Pero el vector entrega de antemano la clave, los mensajes, los encabezados y la aleatoriedad simulada. En producción hay que averiguar quién publicó la clave, si todos recibieron la misma vista, cuántas personas comparten el encabezado, qué ocurrió con el RNG tras un fork o una restauración, y qué identificadores añadieron la cartera, la red y el verifier. Ningún fixture toma esas decisiones.

La carpeta de lanzamiento debe separar dos comprobaciones. Una declara que el build coincide con los resultados de la revisión 12. La otra documenta distribución de claves, cardinalidad, esquema, generación aleatoria, metadatos y pruebas de correlación. Un test determinista no asciende automáticamente a prueba sistémica.

La palabra VALID necesita una oración con punto final

BBS firma una lista ordenada de mensajes con una firma de tamaño constante. El holder produce después una prueba aleatorizada de conocimiento, muestra un subconjunto y oculta tanto la firma como los valores no revelados. El verificador aporta la clave pública, el proof, el header ligado a la firma, el presentation_header de esa prueba, los mensajes visibles y sus índices originales.

Si la operación valida, puede afirmarse que el Prover conoce una firma BBS válida bajo esa clave, que los mensajes mostrados ocupaban esas posiciones y que ambos encabezados están ligados a la prueba. El proof no entrega la firma escondida ni los valores que quedaron ocultos.

No identifica a la persona que maneja el dispositivo. No describe cómo el Issuer comprobó una afirmación real. No consulta de oficio un registro de revocación. No dice que el holder haya presentado todo lo relevante. No aplica la política local de acceso y no observa si la acción posterior tuvo éxito.

La cobertura existente de RFC 9901 conserva el problema de completitud en SD-JWT. Este encargo tiene otra tesis: BBS puede cumplir plenamente su no enlazabilidad criptográfica y, aun así, viajar en una envoltura que clasifica al usuario.

El header del emisor puede ser una matrícula permanente

El borrador distingue dos campos. header lo elige el Signer y queda ligado a la firma y a todos los proofs derivados. El Prover debe revelarlo siempre. Puede codificar contexto común —aplicación, dominio, versión de baja cardinalidad—, pero un valor individual se repite durante toda la vida de la credencial.

Un identificador aleatorio de credential, un correo, un número de terminal o una caducidad con precisión de segundos anuló la ventaja mucho antes de ProofGen. El draft exige que el emisor use un valor de baja entropía compartido por una población amplia.

La cardinalidad no es fija. Un código de país puede reunir millones o identificar a dos integrantes de un programa pequeño. Una versión común hoy puede aislar tres dispositivos rezagados mañana. La combinación de header, clave, región y longitud de esquema puede crear una clase única aunque cada elemento parezca inocuo.

El recibo del Issuer debe conservar bytes exactos, regla generadora, población prevista y observada, clave asociada y excepciones. El Holder no puede reemplazar un header ya firmado. Quien lo controla debe asumir también la evaluación periódica de su riesgo.

El presentation header ata el desafío, no inventa su significado

presentation_header se elige para una prueba concreta. Puede contener nonce, audiencia, dominio, periodo o un mensaje firmado por el mismo Prover que generó el proof. La validación garantiza que el valor está íntegramente ligado a la prueba.

La frescura requiere estado fuera de la primitiva. El Verifier tiene que demostrar quién generó el nonce, a qué sesión y audiencia pertenece, cuándo expira y si ya fue consumido. En un flujo no interactivo necesita otra regla de unicidad. Una cadena inédita puede estar ligada a la transacción equivocada.

Un valor de alta entropía es razonable si cambia en cada proof y no contiene información personal. Reutilizarlo crea un asa estable. Insertar cuenta, ubicación exacta o build raro puede identificar incluso una sola vez. Que el proof proteja la integridad del campo no convierte su contenido en privado.

Los registros deben conservar origen, sesión, audiencia, creación, caducidad y consumo durante un periodo limitado. Guardar solo “nonce válido” impide reconstruir la decisión; guardar para siempre cada challenge construye una nueva base de seguimiento.

La estructura de lo oculto sigue siendo información

La longitud del proof y la cantidad revelada permiten inferir cuántos mensajes fueron firmados. Los índices muestran su posición en el esquema. Cinco campos para empleados, nueve para contratistas y trece para un programa protegido ya clasifican al portador sin descubrir un solo valor.

Una combinación rara de índices funciona como huella. Cuando varios verifiers comparan registros, cada dimensión reduce el conjunto. El borrador aconseja relleno hasta una longitud común y orden estable cuando sea viable. Son decisiones de población, no ornamentos de codificación.

La evidencia debe incluir versión del esquema, distribución real de longitudes, regla de padding, mapa de posiciones y pruebas con campos opcionales. El relleno cuesta ancho de banda y complejidad, y una política de padding excepcional también identifica. Primero se define qué población debe ser indistinguible; luego se mide la clase mínima que el sistema produce.

La clave pública puede separar a los titulares antes del proof

Todo proof se valida con una clave del firmante. Si el Issuer usa una clave para una persona o una cohorte pequeña, cada prueba bajo esa clave revela la cohorte. No hace falta enlazar las cadenas aleatorias.

Puede ocurrir por rotaciones regionales desfasadas, despliegues canary, aislamiento de incidentes o jerarquías heredadas. También puede ser intencionado: mostrar una key view especial a determinados holders y usarla como etiqueta encubierta.

El recibo no es “clave válida”. Debe incluir bytes, identificador, canal de publicación, activación, retiro, población pretendida, población efectiva y prueba de consistencia. Los mecanismos de key consistency citados por el draft son una vía; la obligación general es impedir fragmentación selectiva de las vistas.

Una única clave agranda el anonimato, pero también el radio de compromiso y la dificultad de rotación. Una jerarquía reduce impacto operativo y puede fragmentar privacidad. La organización debe declarar el conjunto que protege cada clave y verificarlo tras cada cambio.

Una verdad revelada puede ser el identificador más directo

Nombre, documento, correo y teléfono pueden estar correctamente firmados y ser revelados deliberadamente. Repetidos, enlazan sin esfuerzo. Incluso profesión, fecha exacta y localidad pequeña pueden formar una combinación única.

BBS acredita autenticidad de lo mostrado, no necesidad. Finalidad, proporcionalidad, retención y alternativa son decisiones del servicio. Pedir fecha completa cuando bastaría demostrar mayoría de edad elimina privacidad sin violar el esquema.

Pruebas de rango o pertenencia pueden disminuir exposición, pero son construcciones adicionales. El BBS base no convierte una edad en umbral ni prueba no revocación solo porque el identificador permanezca oculto. Cada extensión añade parámetros, implementación y una nueva frase de verificación.

La aleatoriedad es material confidencial

ProofGen necesita varios escalares independientes, uniformes y únicos por llamada. Reutilización, predicción o relaciones conocidas pueden revelar mensajes no divulgados o la firma escondida. Un proof puede conservar sintaxis válida después de perder su secreto.

El texto menciona además un canal de exfiltración: un atacante puede manipular bits del generador para codificar información en la salida. Un RNG determinista, sembrado una vez con una semilla única y uniforme, puede limitar ese canal en sistemas sensibles; no elimina la necesidad de entropía confiable y custodia de semilla.

Los recibos identifican generador, build, ruta de seed, pruebas de salud, límites de proceso o dispositivo, fork, restauración de snapshots y manejo de fallos. “RNG del sistema” es una intención arquitectónica, no un rastro de ejecución.

También son controles independientes la deserialización de la clave, membership checks de subgrupo, domain separation, operaciones resistentes a side channels y preprocesamiento uniforme de mensajes. Superar los vectores no prueba ninguno de ellos por inferencia.

No atribuir al BBS base las extensiones vecinas

Blind BBS Signatures es un protocolo separado para firmar mensajes que el Holder oculta al Signer mediante un compromiso. La divulgación selectiva base oculta al Verifier durante la presentación; no demuestra que el Issuer ignorase el dato durante la emisión.

BBS per Verifier Linkability introduce un pseudónimo ligado al contexto para que un Verifier reconozca regresos sin crear, bajo sus supuestos, un identificador común entre contextos. El esquema base no entrega ese pseudónimo estable por sí solo.

La suite W3C bbs-2023 es un perfil de Verifiable Credentials con punteros obligatorios y selectivos, transformaciones y opciones de holder binding o pseudónimo. La compra debe nombrar revisión, ciphersuite, interfaz, extensión y perfil. “Compatible con BBS” no basta.

El futuro cuántico rompe una mitad, no convierte todo en una etiqueta

La autenticidad de BBS depende del logaritmo discreto y no es post-cuántica. Un ordenador criptográficamente relevante podría extraer el secreto del Signer, fabricar firmas y producir proofs válidos sobre mensajes elegidos.

El borrador separa la confidencialidad de proofs ya generados. El ocultamiento de mensajes no revelados y firma es informacional; ni computación ilimitada ni el secreto del Signer permiten extraerlos del proof. Es privacidad duradera de ese valor, no seguridad cuántica del sistema completo.

La migración necesita dos calendarios. La autenticidad debe cambiar antes de que la amenaza alcance la vida útil de decisiones y archivos. Los transcripts pueden seguir ocultando, mientras sus encabezados, valores visibles, IP y metadatos continúan enlazables. Rotar una clave no borra los registros.

El recibo debe cubrir toda la conversación

La cadena mínima separa versión y ciphersuite; origen y consistencia de clave; emisión ciega o no; header y tamaño de cohorte; esquema, orden y padding; valores e índices revelados; presentation header, nonce, audiencia y frescura; proof y resultado; RNG; parser, subgrupo y domain separation; metadatos de red y dispositivo; estado o revocación; regla local; autorización; acción; efecto; retención; migración.

No es necesario centralizar. Issuer, wallet, Verifier, aplicación, seguridad y privacidad custodian su decisión y la unen con un identificador de transacción acotado. La especificación inicial mínima de Lu Heng mantiene pequeña la capa común. La disciplina de capas impide que zero knowledge herede autoridad de una decisión. Running-Code Primacy exige saber qué clave, configuración, RNG, binario y ruta de logs funcionaron.

BBS no promete poco. Promete algo fuerte y delimitado. El error aparece cuando una organización añade “todo el sistema” a la frase sin añadir pruebas.

Fuentes