Modelo de seguridad

La seguridad de Label 309 descansa sobre una sola idea: una prueba es algo que la parte que confía comprueba por sí misma. Un verificador confía en la cadena pública de Cardano y, para las afirmaciones sobre el contenido, en los bytes que se le entregan. No confía en nada más: ni en el emisor, ni en un dominio, ni en un servidor, ni en el operador del gateway a través del cual leyó la transacción. Cada garantía de esta página o bien se desprende de esa postura, o bien marca su límite, o bien señala un riesgo residual que queda fuera de ella.

Esta página es el modelo de amenazas del propio estándar: el modelo de confianza bajo el que opera un verificador conforme, las propiedades de privacidad de una PoE sellada sin firmar, las obligaciones criptográficas que toda implementación DEBE respetar y los límites que el formato de transmisión no puede, ni podría, superar. No describe la seguridad operativa de ningún despliegue concreto: describe lo que el formato garantiza a quien lo implemente correctamente.

El modelo de confianza

Una parte que comprueba una prueba de Label 309 plantea una pregunta acotada: ¿existían estos bytes en o antes del tiempo de este bloque, y depende este veredicto del buen comportamiento de alguien que no sea Cardano? El estándar está construido de modo que la respuesta a la segunda mitad sea siempre «no». No hay ningún intermediario controlado por el emisor en ningún paso: el gateway de la cadena y el gateway de almacenamiento que consulta un verificador son fuentes de datos no confiables, verificadas criptográficamente cuando es posible y contrastadas en cuanto a inclusión y firmeza.

En qué confía un verificador:

• La cadena pública de Cardano. La transacción, sus metadatos bajo la etiqueta 309 y el tiempo de su bloque son hechos replicados en cada nodo de Cardano. Un verificador los lee a través del gateway que elija y puede contrastarlos con varios.
• Los bytes del contenido, al comprobar una afirmación sobre el contenido. Un hash dentro del registro se compromete con una secuencia de bytes concreta. Un verificador que posee esos bytes recalcula el hash y lo compara; no acepta la palabra de nadie de que los bytes coinciden.

En qué no confía un verificador:

• El emisor. Label 309 no tiene un campo issuer. Cualquier billetera puede publicar cualquier registro; la validez del registro es independiente de quién lo envió. Un verificador nunca se pregunta «¿es de fiar este emisor?»: la pregunta no tiene cabida en el modelo. Consulte el invariante de independencia del emisor en la Introducción.
• Un servidor o un dominio. Ningún paso de la verificación contacta con un servicio operado por el emisor. No hay un registro de algoritmos canónico que consultar, ni un punto de estado que sondear, ni una autoridad de identidad contra la que resolver una clave.
• El operador de un gateway. Los gateways de Cardano, Arweave e IPFS a través de los que lee un verificador son intercambiables y sus datos se comprueban contra el contenido (más abajo). Un gateway es un medio de transporte, no una raíz de confianza.

Por qué los gateways no son una raíz de confianza

Un verificador puede leer la misma transacción a través de cualquier gateway de Cardano, y el mismo contenido a través de cualquier gateway de Arweave o IPFS. En ninguno de ellos se confía para que devuelva datos honestos, porque lo que devuelven se puede comprobar de forma independiente:

• Un gateway no puede falsificar un registro que lleve una firma válida: no posee la clave privada del firmante, y el verificador recalcula los bytes firmados y los comprueba él mismo. Consulte Firmas.
• Un gateway no puede sustituir el contenido bajo una URI direccionada por contenido sin que se detecte: un CID ipfs:// es un multihash que el verificador recalcula a partir de los bytes obtenidos, y un identificador de transacción ar:// se compromete con los datos bajo el consenso de Arweave. En un elemento conforme, el mapa hashes en la cadena es un segundo vínculo, independiente, con el texto plano, recalculado en el momento de la obtención.
• Un gateway que retiene una transacción o informa erróneamente de cuán profundamente está enterrada representa una forma de denegación de servicio, no una forma de falsificación. Un verificador que lee a través de más de un gateway y aborta ante cualquier discrepancia convierte «un gateway deshonesto» en «connivencia de todos los gateways que eligió», algo que él mismo controla.

La profundidad de bloque, es decir, cuántas confirmaciones exige un verificador antes de dar un registro por asentado, es política del verificador, no un valor que Label 309 imponga. El estándar no fija ninguna profundidad numérica; la parte que confía establece un umbral acorde a su propia tolerancia al riesgo. Consulte Verificación.

Propiedades de privacidad de la PoE sellada

Una PoE sellada mantiene confidencial un texto plano y al mismo tiempo ancla su marca de tiempo. Más allá de la confidencialidad, la construcción está diseñada para que la cadena filtre lo menos posible sobre el mensaje y nada sobre su audiencia. Son garantías del formato de transmisión: se cumplen en cualquier implementación correcta, porque son propiedades de los bytes, no de ningún despliegue concreto.

Anonimato del remitente en la PoE sellada sin firmar

Una PoE sellada sin firmar, es decir, un registro que lleva enc y ningún sigs, NO DEBE revelar la identidad del remitente en la cadena. Sus bytes de transmisión DEBEN ser independientes de las claves de largo plazo del remitente.

Esto se cumple por construcción:

• Ninguna clave del firmante en la transmisión. La clave de identidad de un remitente llega a la cadena únicamente a través de una entrada sigs. Un registro sin sigs no lleva ningún byte del lado del firmante. La autoría es opcional; el anonimato es el comportamiento por defecto. Las claves X25519 y Ed25519 de largo plazo del remitente nunca aparecen en un registro sin firmar.
• Encapsulamiento fresco por slot. Cada slot de destinatario lleva material KEM por registro y por slot, generado de nuevo en el momento del sellado: la clave pública efímera X25519 en slot.epk en la ruta x25519, o el texto cifrado X-Wing en slot.kem_ct en la ruta mlkem768x25519. No guarda relación con la clave de largo plazo del remitente y no revela nada que vincule registros con un autor común.
• Slots barajados. El array de slots se baraja con un CSPRNG antes de la publicación, de modo que el orden posicional («el destinatario principal primero») no transmite ninguna señal.

Un productor que más tarde firme un registro revela su clave de identidad solo en ese registro; no aparece en ningún registro anterior sin firmar, y ninguna operación remite el material KEM por slot de los registros anteriores de vuelta al autor. Las claves de identidad X25519 y Ed25519 se derivan de la semilla maestra mediante cadenas de contexto HKDF distintas, y una clave pública Ed25519 no puede derivar ni coincidir con una clave pública X25519, de modo que firmar un registro nunca vincula los que están sin firmar. Optar por la autoría es un acto hacia adelante, no una desanonimización retroactiva.

Este invariante cubre únicamente los bytes del registro de label-309. La dirección de Cardano que paga la comisión en las entradas de la transacción, la identidad del productor a nivel de red tal como la ve un gateway y cualquier metadato del blob de texto cifrado fuera de la cadena quedan fuera del formato de transmisión: Label 309 vive en los metadatos, no en las entradas de la transacción, y no puede defenderse contra la correlación de quien paga la comisión. Un productor que necesite anonimato como pagador de la comisión debe abordarlo en la capa de construcción de la transacción.

Imposibilidad de vincular destinatarios

Un registro sellado nunca nombra a sus destinatarios. Un destinatario reconoce que un mensaje es suyo solo cuando logra descifrar de prueba un slot; no hay ningún campo de destinatario que leer. De aquí se derivan dos garantías distintas, que no deben confundirse.

La primera se cumple para ambos KEM y frente a cualquier observador:

• Los destinatarios no pueden verse entre sí. Cada slot es una clave envuelta de forma independiente. Un destinatario que abre su propio slot no deduce nada sobre ningún otro slot y no puede saber a quién más iba dirigido.
• Ninguna clave pública de destinatario en la transmisión. Solo aparecen el encapsulamiento por slot (epk o kem_ct) y la clave envuelta. Un observador sin claves candidatas no puede enumerar a los destinatarios: solo se entera del número de slots, de la familia de KEM (enc.kem) y de la distinción entre sellado y abierto.

La segunda (el anonimato del destinatario frente a un adversario que ya posee un conjunto de claves públicas de destinatario candidatas y quiere comprobar si un slot está dirigido a una de ellas) es una propiedad más fuerte, específica de cada KEM, y el estándar la reclama solo para la ruta clásica:

• x25519 es con privacidad de clave. El epk por slot es una clave pública efímera fresca, estadísticamente independiente de la clave del destinatario. Solo a partir de epk y wrap, un adversario que posea las claves no puede decidir a qué candidata (si a alguna) apunta un slot sin la clave privada que coincide.
• mlkem768x25519 no lo reclama. El anonimato del destinatario frente a un adversario que posea las claves es una propiedad independiente que no implica la seguridad IND-CCA del KEM híbrido, y no se reclama para la ruta X-Wing mientras no se justifique de forma independiente para X-Wing. Un despliegue cuyo modelo de amenaza exija anonimato del destinatario frente a un adversario que posea las claves NO DEBE depender de la ruta híbrida para esa propiedad. Las filtraciones honestas de más arriba (número de slots, familia de KEM, sellado frente a abierto) son idénticas para ambos KEM; nada más sobre los destinatarios queda expuesto en ninguna de las dos rutas.

Vínculo con el texto plano

El hash en la cadena se compromete con el texto plano, no con el texto cifrado. Un destinatario que descifra una PoE sellada recalcula el hash del texto plano y lo compara con el mapa hashes de la cadena. Esto significa que una capa de almacenamiento que sirva un texto cifrado manipulado queda al descubierto tras el descifrado, con independencia del modelo de integridad de la propia URI: la afirmación de la marca de tiempo es una afirmación sobre el texto plano con el que se comprometió el remitente, y nada que haga el gateway puede satisfacerla con bytes distintos.

Independencia frente a la retransmisión

Las firmas de un registro quedan fijadas en el momento en que se envía su transacción. La cadena no tiene noción de un «conjunto de firmantes ampliado» que se acumule a lo largo de varias transacciones.

Retransmitir un cuerpo de registro idéntico en una transacción separada con un conjunto sigs distinto crea un registro separado e independiente con su propio tiempo de bloque, nunca una extensión del original.

Quien quiera respaldar un registro ya publicado publica su propio registro: referenciando el mismo contenido, o apuntando a la transacción anterior mediante supersedes, firmado con su clave. No añade un testigo al registro de otra persona. En consecuencia, un atacante que copie los bytes de un registro firmado en una transacción nueva no pasa a ser cofirmante del original: produce una afirmación posterior y duplicada con los sigs que haya elegido, y el tiempo de bloque anterior del original sigue siendo el registro canónico de existencia. Los verificadores y los indexadores NO DEBEN fusionar dos transacciones con cuerpos de registro idénticos en una sola vista de «firmantes combinados»; hacerlo falsearía la semántica de tiempo de bloque por registro de la que dependen los consumidores posteriores.

Reglas normativas para las implementaciones

Las siguientes son normativas en materia de seguridad para cualquier implementación conforme, sea cual sea su lenguaje o plataforma. Las palabras clave de RFC 2119 / RFC 8174 se emplean en su sentido normativo.

Nada de criptografía novedosa

Label 309 admite deliberadamente solo primitivas bien analizadas, cada una nombrada en los registros de algoritmos e implementada por una biblioteca auditada. Una implementación NO DEBE introducir un cifrador simétrico, un KDF, una construcción de firma ni una stanza de envoltura de claves propios. El formato de transmisión es una composición de partes estándar precisamente para que su seguridad se reduzca a la seguridad de esas partes.

Solo cifrado autenticado

Todo cifrado simétrico en Label 309, la capa de contenido y la envoltura de clave por slot, es AEAD. No hay ningún modo de cifrado sin autenticar en ninguna parte del formato. Un descifrador cuya comprobación del tag AEAD falle DEBE exponer un error estructurado con un discriminador de código estable y NO DEBE proseguir hasta devolver bytes sin autenticar. Los datos autenticados adicionales forman parte del cálculo del tag, de modo que un AAD incorrecto falla igual que una clave incorrecta: no hay ningún estado de éxito parcial que sondear.

Comparación de secretos en tiempo constante

Un bucle de comparación cuyo tiempo de ejecución dependa de bytes secretos es un oráculo. Toda comprobación de igualdad sobre un secreto o un tag MAC/AEAD DEBE ejecutarse en tiempo constante:

• El MAC del conjunto de slots y cualquier tag HMAC: una fuga de tiempo byte a byte sobre un MAC de 32 bytes puede, mediante repetición adversaria, recuperar el tag.
• La verificación del tag AEAD: la función decrypt de la biblioteca subyacente ya devuelve un fallo sin revelar qué byte no coincidió; las implementaciones NO DEBEN reimplementar esta comprobación.
• La verificación de firmas: use la función verify de la biblioteca, nunca una ecuación hecha a mano.

Un simple == / === sobre arrays de bytes que toque cualquiera de estas superficies es un defecto. Encaminar cada una de esas comparaciones a través de un único helper tipado hace que la propiedad sea auditable.

La disciplina de tiempo constante se extiende a la forma del bucle de descifrado de prueba, no solo a las comparaciones individuales. Para preservar la propiedad de ocultación del destinatario, un verificador de destinatario DEBE procesar todos los slots dentro de la pasada de una sola clave privada (un número constante de operaciones de slot por clave, sin salida anticipada ante la primera coincidencia), de modo que un observador a nivel de red con acceso a los tiempos no pueda inferir qué índice de slot desenvolvió una clave, ni si alguno lo hizo. La clave candidata se selecciona en tiempo constante. La validez del secreto X25519 se captura mediante un bit independiente del secreto, kem_ok = NOT constantTimeEqual(shared, 0^32), calculado con una comparación en tiempo constante en lugar de una ramificación anticipada; la KEK es entonces una selección en tiempo constante entre la KEK real y una KEK ficticia derivada de un secreto compartido todo a cero bajo el mismo salt e info, y kem_ok se pliega en la aceptación del slot (ok = kem_ok AND open_ok AND mac_ok), de modo que un slot con ECDH inválido nunca puede aceptarse mientras el bucle sigue realizando un trabajo idéntico. El array de slots se publica en orden barajado con CSPRNG, así que la posición en la transmisión ya no transmite ninguna señal de «destinatario principal primero»; combinado con la pasada en tiempo constante, un observador solo se entera del número de slots. Un destinatario que posee varias claves privadas (por ejemplo, claves archivadas tras una rotación de identidad) itera clave × slot y PUEDE cortocircuitar entre claves (eso filtra solo la señal débil de «qué clave coincidió»), pero DEBE mantenerse en tiempo constante a lo largo de los slots de cualquier clave individual, rederivando la mitad del salt de la KEK correspondiente a la clave del destinatario por cada clave, ya que ambos KEM comprometen el salt con la codificación de transmisión canónica de esa clave (exactamente la clave pública X25519 de 32 bytes, o exactamente los bytes de clave pública X-Wing fijados de 1216 bytes, nunca una recodificación no canónica).

Verificación estricta de Ed25519

Las firmas de Label 309 DEBEN verificarse en modo estricto (canónico). Un verificador laxo, con cofactor, acepta ciertas firmas maleables o con claves de orden bajo que un verificador estricto rechaza, lo que permitiría que dos implementaciones conformes discreparan sobre el mismo registro, rompiendo la propiedad de veredicto único de la que depende todo el estándar. El corpus de conformidad entre lenguajes fija un vector de prueba de orden bajo justamente para detectar un verificador que se haya deslizado al modo laxo. Consulte Firmas.

Nunca registrar material secreto

Los bytes de semilla, las claves privadas derivadas, las claves de cifrado de clave, las claves de cifrado de contenido, el material derivado de la frase de contraseña y el texto plano descifrado NO DEBEN llegar a los registros a ningún nivel. La redacción basada en rutas en la configuración de un logger es necesaria, pero no suficiente por sí sola: un valor anidado más profundamente de lo que alcanza el glob de redacción puede colarse, así que las implementaciones DEBEN además tratar cada valor de tipo byte (Uint8Array, bytes y similares) como redactado de forma opaca y sin condiciones, incluso para valores públicos del protocolo como un nonce. El secreto más barato de proteger es el que nunca entra en una línea de registro.

Garantías de la construcción de la PoE sellada

Tres propiedades adicionales son específicas de la construcción de la PoE sellada. Son normativas en materia de seguridad para cualquier implementación que produzca o abra un registro sellado.

El MAC del conjunto de slots es un compromiso de ~128 bits

El MAC del conjunto de slots es lo que convierte una clave de contenido recuperada en un compromiso con el conjunto de slots que coincidió el destinatario: un remitente malicioso no puede construir dos conjuntos de slots distintos que un único destinatario acepte como «suyos». La propiedad requerida es un compromiso de clave restringido para la clave de contenido del sobre, en el sentido de RFC 9771 —la clave recuperada se vincula a una única transcripción de slots—, no un AEAD plenamente comprometedor sobre entradas arbitrarias. El destinatario deriva una clave de un slot y luego exige que esa misma clave reproduzca slots_mac sobre el hash de la transcripción de slots antes de tratar el slot como propio. En concreto, el compromiso se apoya en la resistencia a colisiones multiclave de

CEK ↦ HMAC-SHA-256( HKDF-SHA-256(CEK, info="cardano-poe-slots-mac-v1"), slots_hash )

para CEK y transcripciones elegidas de forma adversaria. Como el adversario controla tanto la CEK como la transcripción, la cota relevante es la de colisión genérica (del cumpleaños) sobre la salida HMAC de 256 bits: encontrar dos pares (CEK, transcripción) que produzcan el mismo slots_mac es una búsqueda de ~128 bits, no el nivel de 256 bits de la segunda preimagen. Un margen de colisión genérica de 128 bits es el nivel de seguridad del que depende este compromiso, y es adecuado para el modelo de amenaza.

Precalcular el hash de la transcripción a un slots_hash de 32 bytes antes del HMAC no lo debilita: una colisión de slots_mac implica o bien una colisión de slots_hash (una colisión de SHA-256) o bien una colisión del HMAC con clave sobre slots_hash iguales, ambas al nivel de ~128 bits. La evidencia de manipulación de la propia transcripción hereda la cota de colisión 2^128 de SHA-256: cualquier cambio en un campo de cabecera comprometido o en un byte de slot altera slots_hash, y forjar un slots_hash inalterado sobre una transcripción distinta es exactamente esa búsqueda de colisión de ~128 bits. Una consecuencia directa es que el envoltorio por slot no tiene por qué ser un AEAD que comprometa: el compromiso lo aporta slots_mac, no el envoltorio, así que un envoltorio no comprometedor (el ChaCha20-Poly1305 por defecto) es sólido aquí.

La seguridad del envoltorio con nonce a cero descansa en la unicidad de clave por slot

Cada slot envuelve la clave de contenido bajo una clave de cifrado de clave por slot con ChaCha20-Poly1305 con un nonce a cero. Un nonce a cero es seguro solo porque la clave de cifrado de clave es por slot y se usa para exactamente un envoltorio: cada slot extrae aleatoriedad KEM fresca, así que la clave de envoltorio es única por slot con probabilidad de colisión despreciable. La condición de seguridad es exactamente la unicidad de clave por slot, y un productor NO DEBE introducir nada que pudiera repetir un par (key, nonce): un fallo del CSPRNG que repita aleatoriedad KEM, un encapsulamiento determinista o con colisiones, la reutilización de un slot entre registros, el cacheo de una clave derivada por (destinatario, efímero), o la deduplicación de dos apariciones del mismo destinatario en un solo slot.

Esto se divide limpiamente en una porción comprobable por el verificador y una obligación exclusiva del productor:

• Los duplicados dentro del registro los rechaza el verificador. Un verificador DEBE exigir que el material de encapsulamiento sea distinto dentro de un mismo slots[]: todos los valores epk distintos en la ruta x25519, todos los valores kem_ct distintos en la ruta mlkem768x25519. Un duplicado se rechaza antes de ejecutar ninguna primitiva KEM o AEAD, con el código tipado ENC_SLOTS_DUPLICATE_KEM_MATERIAL. El corpus de conformidad ejercita esto con un registro que lleva dos slots que comparten un epk (o kem_ct) y exige ese rechazo. Este rechazo se dispara solo ante un epk / kem_ct repetido; no prohíbe sellar dos veces para el mismo destinatario, ya que la duplicación honesta sigue extrayendo aleatoriedad KEM fresca por slot en cada aparición (véase la regla de múltiples slots coincidentes más abajo).
• La reutilización entre registros y entre claves es una obligación del productor. Ningún verificador puede detectar que un productor reutilizó material KEM entre dos registros o destinatarios distintos; eso queda fuera de los bytes de un único registro y sigue siendo responsabilidad del productor. Si una revisión futura llegara a permitir la reutilización de claves, el nonce a cero tendría que reemplazarse por un nonce fresco en ese mismo cambio.

Múltiples slots coincidentes: el relleno es válido, un conflicto de CEK no

La clave privada de un destinatario PUEDE coincidir legítimamente con más de un slot. Sellar la misma clave de contenido para el mismo destinatario en varios slots —cada uno con efímeros frescos por slot— es una técnica válida de relleno y privacidad, que eleva el número visible de slots sin revelar que dos de ellos comparten un destinatario. Es distinta del rechazo de encapsulamiento duplicado dentro del registro de más arriba: la duplicación honesta extrae aleatoriedad KEM fresca, así que sus epk / kem_ct difieren y nunca dispara ENC_SLOTS_DUPLICATE_KEM_MATERIAL. Por tanto, un verificador DEBE seleccionar la clave de contenido del primer slot coincidente y NO DEBE rechazar solo porque coincidiera más de un slot.

La única anomalía que un verificador DEBE rechazar son dos slots coincidentes que recuperan claves de contenido distintas, comparadas en tiempo constante. El bucle de descifrado de prueba arrastra un bit cek_conflict a lo largo de todos los slots y aflora el único fallo genérico si cualquier coincidencia posterior recupera una clave que difiera de la ya seleccionada. Esto es defensa en profundidad: bajo la propiedad de compromiso de más arriba, una coincidencia con clave distinta ya es inviable —es exactamente la colisión multiclave que esa propiedad descarta—, así que la comprobación falla de forma segura frente a una implementación defectuosa o un debilitamiento futuro de la suposición. El negativo de clave distinta no es construible como vector de bytes (construir uno sería la propia colisión del compromiso), así que la propiedad se fija mediante pruebas de comportamiento a nivel de implementación en lugar de un fixture, junto a un fixture positivo para la duplicación legítima de destinatario.

Cotas de recursos del analizador antes de cualquier primitiva

Un verificador DEBE acotar el uso de recursos del analizador antes de invocar ninguna primitiva KEM o AEAD, de modo que un sobre sobredimensionado no pueda imponer trabajo antes de ser rechazado. Los límites de referencia son MAX_SLOTS = 1024 slots y 65536 bytes para el sobre enc decodificado, ambos muy por encima del techo de ~16 KiB de los metadatos de transacción de Cardano que acota cualquier registro honesto, así que un registro que supere cualquiera de las dos cotas está mal formado. Un exceso de recuento se rechaza con ENC_SLOTS_TOO_MANY, un sobre sobredimensionado con ENC_ENVELOPE_TOO_LARGE. Son constantes impuestas por el verificador y fijadas por despliegue —no campos de transmisión— y un despliegue PUEDE endurecerlas. La guarda análoga en la ruta de frase de contraseña es una longitud máxima de entrada de frase de contraseña en bruto impuesta antes de la normalización y de Argon2id (cota de referencia 4096 bytes UTF-8, MAX_PASSPHRASE_INPUT_BYTES), de modo que una frase de contraseña patológica no pueda provocar una denegación de servicio previa al KDF.

La validez de la clave pública X-Wing acota el piso híbrido

El KEM híbrido mlkem768x25519 nunca baja del piso de seguridad clásica de X25519, pero ese piso está acotado a claves de destinatario generadas de forma válida. XWing.Encapsulate DEBE aplicar la comprobación de validez de clave pública de la revisión fijada de X-Wing a la clave del destinatario y negarse a encapsular hacia una clave que no la supere, en lugar de tratar una clave mal formada como si llevara la garantía clásica. Un productor que omita la comprobación renuncia al piso para ese destinatario; la comprobación es la precondición bajo la cual el piso se mantiene.

Tamaño de carga útil acotado

La capa de contenido es un STREAM segmentado: el texto plano se divide en segmentos de 65536 bytes, cada uno sellado bajo la clave de contenido con un nonce de contador distinto. El contador de 88 bits por segmento admite 2^88 segmentos y cada segmento se mantiene holgadamente dentro del límite de invocación única de RFC 8439, así que (a diferencia de un AEAD de una sola pasada sobre todo el texto plano) no hay ninguna colisión de flujo de clave por desbordamiento del contador contra la que protegerse y el formato no impone ningún techo criptográfico a la carga útil. El máximo que impone un despliegue es, por tanto, una política de denegación de servicio, no una cota criptográfica: los productores y los verificadores DEBERÍAN acotar el tamaño de la carga útil para que quepa en sus recursos e imponerlo de forma incremental a medida que el flujo se escribe o se lee, abortando antes de almacenar en memoria una carga útil sobredimensionada. El truncamiento se detecta estructuralmente mediante la marca final de cada segmento (un segmento final ausente, datos sobrantes o un segmento no final corto hacen fallar el descifrado), no mediante una comprobación de tamaño. La postura es idéntica en la ruta de slots y en la ruta de frase de contraseña.

La agilidad en algoritmos como propiedad de seguridad

Cada elección criptográfica de un registro de Label 309 se nombra mediante una cadena de un registro de algoritmos extensible: el hash, el AEAD, el KEM, el KDF, el esquema de firma. No es una elección estilística; es el sustrato de migración que permite al formato sobrevivir a cualquier algoritmo concreto.

Si una primitiva queda debilitada por el criptoanálisis:

1. El registro de algoritmos correspondiente recibe un identificador sucesor. Nada del formato existente cambia: el nuevo nombre es aditivo.
2. Los registros existentes siguen siendo válidos. Un verificador continúa reconociendo el identificador antiguo para los registros históricos; sus afirmaciones sobre el tiempo de bloque no se evaporan porque exista un algoritmo más nuevo. Una implementación PUEDE presentar un registro que dependa únicamente de un algoritmo debilitado posteriormente como de menor garantía, pero NO DEBE borrarlo ni rechazarlo solo por ese motivo.
3. Los registros nuevos se publican bajo el sucesor. Un productor que quiera defensa en profundidad PUEDE comprometer un hash del contenido bajo dos algoritmos de familias de diseño distintas, de modo que una ruptura de una sola familia no haga colapsar el valor probatorio del registro, aunque los registros de un solo algoritmo siguen siendo plenamente conformes.

Como los identificadores son cadenas y los registros de algoritmos son abiertos, migrar a hashes, KEM o firmas poscuánticos es un cambio aditivo en el registro de algoritmos, nunca una revisión del formato que rompa la compatibilidad. El KEM híbrido poscuántico que ya figura en el registro de algoritmos es un ejemplo de esta propiedad en acción, no un caso especial añadido a posteriori.

Límites conocidos del estándar

No son defectos que deban corregirse en una revisión posterior; son propiedades inherentes a anclar pruebas en un libro mayor público y permanente y al cifrado de clave pública dirigido a claves de largo plazo. Un modelo de seguridad honesto los nombra.

Permanencia en la cadena

Los metadatos de Cardano son permanentes y se replican globalmente. Un registro de Label 309 ya publicado no se puede eliminar, redactar ni invalidar: esa durabilidad es la razón misma de ser de una prueba de existencia. La consecuencia es una responsabilidad en el momento de publicar: un hash del contenido, una firma ligada a un stake o cualquier otra cosa comprometida bajo la etiqueta 309 queda en la cadena para siempre. Label 309 omite deliberadamente del registro los metadatos descriptivos de formato libre para mantener mínima la huella en la cadena, pero un productor DEBE comprender que lo que publica es irrevocable antes de publicarlo.

El número de destinatarios es visible

Una PoE sellada nunca nombra a sus destinatarios, pero el número de slots de destinatario es la longitud del array, claramente visible en la cadena, igual que la familia de KEM (enc.kem) y la distinción entre sellado y abierto. Las claves públicas de los destinatarios quedan fuera de la transmisión y los slots se barajan, pero el relleno para ocultar el recuento no forma parte de la base. Un remitente para quien el número de destinatarios sea en sí mismo sensible debe tener en cuenta esta fuga de metadatos a nivel operativo: por ejemplo, rellenando él mismo el conjunto de slots, o publicando registros separados.

Sin revocación por destinatario

No existe ninguna primitiva en la cadena para revocar el acceso de un único destinatario a una PoE sellada ya publicada. Una vez que un registro se cifra hacia una clave pública y se ancla, ese vínculo es permanente. Es una propiedad inherente al cifrado de clave pública dirigido a una clave de largo plazo, no una carencia del formato. Una clave que se considera comprometida se gestiona en adelante: dirigiendo los registros nuevos a una clave fresca y, opcionalmente, publicando un registro que la sustituya como señal de advertencia, nunca volviendo atrás para alterar lo que ya está en la cadena.

Sin secreto hacia adelante para el destinatario, por diseño

Quien posee una clave privada de destinatario puede descifrar, para siempre, toda PoE sellada que se le haya dirigido alguna vez. El texto cifrado fuera de la cadena es permanente y no hay primitiva de revocación, de modo que un registro sellado es privado para el mundo, pero no para su destinatario. Este es el comportamiento esperado al cifrar hacia una clave pública de largo plazo. Un remitente que necesite limitar el alcance futuro de un destinatario debe cifrar hacia una clave de destinatario de vida corta en lugar de una clave de identidad de largo plazo: una elección del lado del remitente que el formato permite, pero no impone.

Los fallos del descifrado de prueba no filtran material de claves

Un destinatario descubre su slot mediante el descifrado de prueba. Internamente, solo para el diagnóstico de un llamante local de confianza, las rutas de fallo llevan códigos tipados distintos: «ningún slot se abrió con mi clave» (WRONG_RECIPIENT_KEY), «un slot se abrió, pero ninguna clave candidata reprodujo slots_mac» (TAMPERED_HEADER) y «el AEAD de contenido falló tras recuperar una clave y verificar el MAC» (TAMPERED_CIPHERTEXT). Estos códigos no tienen valor de oráculo: un adversario sin la clave privada correspondiente no abre ningún slot, y toda ruta de error DEBE excluir de su mensaje y de su cadena de causas los bytes secretos subyacentes (el secreto compartido, la clave de cifrado de clave, la clave de cifrado de contenido).

Un llamante externo no confiable, sin embargo, DEBE recibir exactamente una forma de fallo genérico con independencia de por qué falló el descifrado, y la respuesta externa NO DEBE distinguir las tres causas por su forma, ni revelar qué slot coincidió. Los códigos internos existen para la depuración local; NO DEBEN filtrarse a un observador externo a través de una respuesta distinguible.

El modelo de tiempo está deliberadamente acotado. Un verificador PUEDE retornar en la comprobación de no-coincidencia, antes del descifrado del contenido, de modo que un no destinatario (ningún slot se abrió) pueda medirse aparte de un destinatario cuyo slot se abrió pero cuyo texto cifrado de contenido no consigue abrir. Esa distinción revela solo destinatario frente a no destinatario; nunca revela qué slot coincidió ni material de clave alguno. No se exige un tiempo uniforme entre el caso de no destinatario y el caso de texto cifrado defectuoso, y NO DEBE imponerse una apertura de contenido ficticia: forzar el coste del descifrado del contenido sobre todo no destinatario no compraría nada. La garantía de tiempo constante que sí se mantiene es la invariante de entre slots (consulte Comparación de secretos en tiempo constante): dentro de la pasada de una sola clave, el bucle recorre todos los slots con comparaciones en tiempo constante, de modo que un observador no puede averiguar qué slot, si alguno, desenvolvió una clave dada y, más allá de la distinción destinatario-frente-a-no-destinatario, solo se entera del número de slots.

Páginas relacionadas

• Introducción: los cinco invariantes, entre ellos la independencia del emisor y la verificabilidad autónoma.
• Firmas: la verificación estricta de Ed25519 y el modelo de autoría tolerante a fallos.
• PoE sellada: el sobre de cifrado y las propiedades de privacidad que aquí se resumen.
• Registros de algoritmos: los identificadores con nombre que hacen posible la agilidad en algoritmos.
• Verificación: el flujo, la política de profundidad de confirmación y el catálogo de errores.