datekeys-dart

Librería Dart del protocolo DateKeys: DateKey, DateKeyCap (.dkc) y DateKeys Access Key (.dkk). Es Dart puro, sin Flutter ni plataforma, para que la app Flutter la use como dependencia de ruta (datekeys: { path: ../datekeys-dart }).

Es la tercera implementación de la especificación, después de la de referencia en Go (datekeys-go) y la de TypeScript (datekeys-ts). Como la de TypeScript, no genera datos de prueba propios: se contrasta con el testdata/ de datekeys-go, y con los vectores de test/vectors/, que calcula Go con los programas de tool/ (ver «Datos de prueba»).

Estado

Están hechas las etapas 0 a 3 del plan (docs/PLAN_dart.md del espacio de trabajo) y la parte 4b de la etapa 4:

• la etapa 0, el paquete, sus herramientas y testdata/ sincronizado;
• la etapa 1, los errores normativos, los bytes, el perfil CBOR del §58 y el DER estricto, también el de los tiempos;
• la etapa 2, las primitivas y la lectura de age;
• la etapa 3, BLS12-381 y tlock: el emparejamiento, el hash a G1, el IBE de drand y la verificación de la firma de la ronda;
• la parte 4b, los formatos de la cápsula y de la llave de acceso: las tramas, PUBLIC_HEADER, CONTROL_CBOR de los tres formatos, la .dkk, las extensiones, el Provider Profile, la DateKey con sus rondas y el relleno.

Las etapas 2 y 3 se hicieron en paralelo, en ramas aparte desde la etapa 1, y se integraron el 5 de octubre de 2026.

La etapa 1 porta tres ficheros de datekeys-go en 601e6d2, con las mismas lecturas, las mismas comprobaciones en el mismo orden y los mismos textos de error:

Módulo	Contenido	En Go
lib/src/errors.dart	Los 19 códigos del §69 en su orden (ErrorCode), DateKeysException con el mensaje contexto: CÓDIGO, wrap, withContext y errorCode	errors.go
lib/src/bytes.dart	Hexadecimal, comparación y concatenación; UTF-8 estricto que conserva un U+FEFF inicial; utf8.DecodeRune y el %q de Go, con la tabla de strconv.IsPrint de Go 1.26	unicode/utf8, strconv
lib/src/cbor.dart	CborEncoder, CborDecoder, unmarshalCbor, peekSchema, checkSchema y walkCbor	codec/codec.go
lib/src/der.dart	check, split, content, setOfSorted y parseTime, con UTCTime y GeneralizedTime exactos al nanosegundo. Es interno, como en Go	internal/der/der.go, ya del borrador v0.12

La etapa 2 trae las primitivas, todas de código propio salvo SHA-512, y la lectura de los ficheros age de filippo.io/age v1.3.2. Son internas, como en Go y en datekeys-ts: lib/datekeys.dart no las exporta.

Módulo	Contenido	En Go
lib/src/sha256.dart	SHA-256 con su compresión; HMAC-SHA256 con los estados interior y exterior de la clave calculados una vez; HKDF-SHA256 (RFC 5869); PBKDF2-HMAC-SHA256 (RFC 8018), cuyas iteraciones son dos compresiones sobre palabras, sin bytes entre medias	crypto/sha256, crypto/hmac, x/crypto/hkdf, x/crypto/pbkdf2
lib/src/scrypt.dart	scrypt (RFC 7914) con Salsa20/8, con las comprobaciones y los textos de scrypt.Key	x/crypto/scrypt
lib/src/chacha20poly1305.dart	ChaCha20, Poly1305 y ChaCha20-Poly1305 (RFC 8439); el tag se compara en tiempo constante	x/crypto/chacha20poly1305
lib/src/curve25519.dart	X25519 (RFC 7748) con clamping y el secreto todo a ceros rechazado; la verificación estricta de Ed25519 del §29.9, con canonical, smallOrder y onCurve	x/crypto/curve25519, internal/ed25519strict
lib/src/base64.dart	El Base64 de Go, con su modo estricto y el offset de sus errores	encoding/base64
lib/src/bech32.dart	El Bech32 de age, con sus textos de error	codec/bech32
lib/src/age.dart	La cabecera y sus límites (2 MiB, 1024 stanzas, un tipo y 128 argumentos por stanza), el MAC de la cabecera, los stanzas X25519 y scrypt, la clave del payload y el STREAM, con los mismos casos de fin de fichero que Go. Cada fallo es una AgeException con el texto de Go y su fase: la cabecera (age.Decrypt) o el payload (la lectura del STREAM)	filippo.io/age, internal/format, internal/stream
lib/src/agewrap.dart	Las reglas de stanzas de OUTER_TIME_AGE, PAYLOAD_AGE e INNER_ACCESS_AGE, la lectura de los stanzas sin secretos y las identities del payload y del acceso, con los textos y los códigos de Go	agewrap

Notas de la etapa 2:

• La identity de scrypt rechaza por defecto un factor de trabajo por encima de 16, el de los ficheros de clave de autor (§29.12), como SetMaxWorkFactor(16) en el authorkey de Go. El de age es 22: 4 GiB de memoria, que un fichero hostil podría pedir a un móvil. ScryptIdentity(maxWorkFactor: …) lo cambia.
• El STREAM se descifra según llega el texto cifrado (AgePayloadDecryptor), como el lector de Go: entrega el texto de cada chunk en cuanto se autentica, y un fallo que revela un byte posterior llega en la llamada siguiente.
• La identity de OUTER_TIME_AGE se compone en la etapa 4, con el perfil: checkTimeStanzas de esta etapa, que recibe la ronda, el chain hash y el id del perfil, y checkTlockProfile y unwrapTlockStanza de la etapa 3.

La etapa 3 porta BLS12-381 de kilic/bls12-381 v0.1.0, sobre el que calcula drand/kyber-bls12381 v0.3.4 para drand y tlock; el IBE de encrypt/ibe de drand/kyber v1.3.2, el de tlock v1.2.0 con Quicknet; y provider.Verify y el stanza tlock de agewrap de datekeys-go, con las mismas comprobaciones en el mismo orden y los mismos textos de error. Como datekeys-ts, verifica solo el scheme de Quicknet, bls-unchained-g1-rfc9380. Todo es código propio: de package:crypto usa solo SHA-256.

Módulo	Contenido	En Go
lib/src/bls12381_fp.dart	El cuerpo Fp sobre BigInt (Fp) y las sumas de productos sin reducir (FpWide): la única capa que toca la representación de un elemento	fp.go de kilic
lib/src/bls12381_tower.dart	Fp2, Fp6 y Fp12 con las fórmulas de kilic, cada coeficiente reducido una vez; el Frobenius y el cuadrado ciclotómico; GT serializado c1 antes que c0 en cada nivel	fp2.go, fp6.go, fp12.go de kilic
lib/src/bls12381_curve.dart	G1 y G2 en coordenadas jacobianas, su codificación comprimida y los veredictos de FromCompressed (§12.2): checkCompressedPoint	g1.go, g2.go de kilic
lib/src/bls12381_pairing.dart	El emparejamiento ate óptimo: el bucle de Miller con las rectas de kilic y su exponenciación final	pairing.go de kilic
lib/src/bls12381_hash.dart	expand_message_xmd, hash_to_field, el mapa SWU simplificado, la isogenia de grado 11 y el cofactor: el hash a G1 del RFC 9380 con el DST de Quicknet	hash_to_field.go, swu.go, isogeny.go de kilic
lib/src/ibe.dart	El IBE-CCA de tlock sobre G2 (§63 paso 11): H2, H3 con su rechazo de candidatos, H4, la identidad de la ronda, el descifrado y el cifrado, este con sigma inyectable	encrypt/ibe de kyber
lib/src/release.dart	verifyRelease (§17, §51, §63 paso 10), Release, ReleaseSource, suppliedRelease y fetchRelease, la regla del paso 9	provider
lib/src/tlock.dart	El stanza tlock de OUTER_TIME_AGE (§32, §35, §63 paso 11): abrirlo, como NewTimeIdentity y su Unwrap, y escribirlo, como NewTimeRecipient	agewrap

Notas de la etapa 3:

• La capa del cuerpo. Fp es un extension type sobre BigInt, sin envoltorio en ejecución, y FpWide una suma de productos sin reducir. La torre, las curvas, el emparejamiento y el hash solo usan sus operaciones: una implementación con limbs fijos, más rápida, cambiaría ese fichero y nada más.
• Los veredictos de un punto son los de FromCompressed de kilic: el flag de compresión a 1; el punto en el infinito solo como 0xc0 y ceros; coordenadas menores que p, sin reducir; un punto de la curva; y un punto del subgrupo de orden r. En G1 el subgrupo se comprueba con [r]·P = O; en G2, con ψ(P) = ·P (Scott, eprint 2021/1130, como noble), que las pruebas comparan con [r]·P = O en puntos fuera del subgrupo, también con torsión de cada orden pequeño del cofactor.
• GT es el valor del emparejamiento de kilic, con su exponenciación final, f^(3·(p⁴ − p² + 1)/r), y se serializa en su orden (§63, «Serialización de GT en H2»).
• El hash a G1 sigue a kilic, que suma las dos salidas del mapa en E′ antes de la isogenia. kilic se aparta del RFC 9380 solo donde ningún hash llega: dos salidas iguales u opuestas, que suma con la fórmula de E. Este código las suma con la ley de grupo de E′, como el RFC.
• Las diferencias con Go, a propósito, son las de datekeys-ts: otro scheme que el de Quicknet da ERR_UNKNOWN_PROFILE con un texto propio, donde Go verificaría los otros schemes de drand; y el punto en el infinito nunca es una firma válida (§63 paso 10), mientras que Go la acepta si la clave pública también es el punto en el infinito, una clave que ningún perfil pinneado tiene (§12.1). Las pruebas fijan las dos.
• El stanza tlock. unwrapTlockStanza recibe los argumentos y el cuerpo del único stanza y hace lo que NewTimeIdentity y su Unwrap en Go: el perfil, los argumentos, otra vez el release y el cuerpo. El número y el tipo de los stanzas los comprueban las reglas de agewrap de la etapa 2, que necesitan la cabecera entera. Se guarda el último release verificado: el paso 11 vuelve a verificar el del paso 10, como en Go, sin otro emparejamiento.
• La fuente de releases. La librería no trae cliente HTTP: recibe una ReleaseSource, como OpenOptions.Source en Go. fetchRelease aplica la regla del paso 9: lo que lance la fuente es ERR_RELEASE_UNAVAILABLE, con su texto y ningún otro código.
• Lo que se exporta. lib/datekeys.dart exporta la verificación de releases y checkCompressedPoint, como datekeys-ts. El IBE y el stanza tlock son internos: los usará la apertura de la etapa 4. El cifrado no se exporta todavía: es del escritor, la etapa 6.

La parte 4b de la etapa 4 porta los formatos de la cápsula y de la llave de acceso de datekeys-go en c531e93 (la rama v0.12: la v0.11 con los arreglos de la revisión del 2 de octubre), con las mismas comprobaciones en el mismo orden, las mismas capas del §69.1 y los mismos textos de error. El API sigue al de datekeys-ts:

Módulo	Contenido	En Go
lib/src/framing.dart	El PRELUDE y la trama de la .dkk (parsePrelude, splitAccessKey), splitCapsule con los pasos 1 a 3 de la inspección y headerBinding; CapsuleFormat	capsule/framing.go, inspect.go; accesskey.Decode
lib/src/padding.dart	PaddingRule, paddedLength, payloadAgeLength y PaddingCheck, la comprobación del plaintext frente a L y P	capsule/padding.go; checkPadding de open.go
lib/src/body.dart	La trama de BODY y el área del formato 3, sin el head	ParseBodyFrame, CheckArea de format3.go
lib/src/digest.dart	El SHA-256 incremental del capsule_digest y su comparación	checkCapsuleDigest de open.go
lib/src/extension.dart	Los arrays de extensiones, los registros con sus lugares, checkCritical, checkNoncritical y la regla de los codificadores del §72 (checkWrite, StandardExtensions)	extension
lib/src/schema.dart	Lo común de los decodificadores de objetos: la clave de un fallo, las claves obligatorias, los arrays de extensiones	required, encodeExtensions de capsule
lib/src/profile.dart	El Provider Profile: su CBOR, profile_hash, el §12.1, maxRound, Quicknet y el registro	profile
lib/src/datekey.dart	dk1_, las rondas y sus horas, Instant y el RFC 3339 de Go	datekey; time.Parse, Format
lib/src/header.dart	PUBLIC_HEADER y AccessPolicy	DecodeHeader, EncodeHeader
lib/src/control.dart	CONTROL_CBOR de las versiones 1, 2 y 3	DecodeControl, EncodeControl
lib/src/accesskey.dart	La .dkk: su cuerpo, su trama y su escritura con la regla del §72	accesskey

Notas de la etapa 4b:

• Los enums. El formato, la regla de relleno y la política son enums de Dart (CapsuleFormat, PaddingRule, AccessPolicy), donde Go y datekeys-ts usan números. La regla de relleno no se llama Padding, que es un widget de Flutter.
• Los errores sin código. Lo que Go devuelve sin código normativo, como un código de relleno que no existe al codificar, un L por encima de L_MAX en paddedLength o una extensión de la especificación fuera de su sitio al escribir, es un ArgumentError con el texto de Go: un error del llamador.
• Las extensiones de la especificación. StandardExtensions es el Standard de Go. Las reglas de texto de la nota necesitan las tablas de las rutas, y la data de datekeys.capsule es del localizador: se le dan sus comprobaciones (validateNote, validateCapsule), y sin ellas solo se comprueba que haya data, como el Standard de Go sin ValidateCapsule.
• Los enteros. Una ronda, L y P son un int hasta 2^53-1, exactos en la web; un entero de ocho bytes se lee como dos mitades de 32 bits, y Padmé se calcula con potencias de dos, sin desplazamientos.
• Un nombre con un surrogate suelto se cita en los textos como Go citaría sus bytes en UTF-8 generalizado (\xed\xa0\x80), como en la etapa 1; datekeys-ts escribe U+FFFD. Go no tiene esos nombres.
• La rama v0.12 de Go frente al tag spec-v0.11. Para estos paquetes, la única diferencia es la regla de los codificadores del §72: en spec-v0.11, accesskey.Encode escribe datekeys.note en una .dkk y datekeys.capsule en un array crítico. El generador da la misma salida en las dos para todo lo demás.
• Lo que se exporta. lib/datekeys.dart exporta los formatos, como index.ts de datekeys-ts. La trama de BODY, el digest y lo común de los esquemas son internos: los usará la etapa 4c, con el head, la nota, la inspección y la apertura.

Los enteros son exactos en la VM y en la web. El int de Dart tiene 64 bits con signo en la VM y en la web es un double, exacto hasta 2^53. Por eso la librería no usa un int por encima de 2^53-1, ni desplazamientos u operaciones de bits de más de 31 bits:

• un entero de CBOR es un int hasta 2^53-1 y un BigInt por encima, como el number | bigint de datekeys-ts;
• CborDecoder.uint devuelve un int, porque todos los esquemas acotan sus enteros en 2^53-1, y uint64 devuelve un BigInt;
• SHA-256, ChaCha20 y Salsa20 trabajan con palabras de 32 bits: suman de dos a cinco y enmascaran la suma, y en cada rotación enmascaran la mitad desplazada a la izquierda, así que la VM y la web dan los mismos 32 bits;
• Poly1305 guarda el acumulador y r en diez limbs de 13 bits: cada producto queda por debajo de 2^31 y cada suma por debajo de 2^35, y sus acarreos se toman con ~/, no con un desplazamiento, que en la web truncaría a 32 bits;
• el cuerpo de curve25519 es el de TweetNaCl en su versión de JavaScript: dieciséis limbs de 16 bits en un Float64List, con sumas de productos por debajo de 2^44;
• en BLS12-381 los elementos del cuerpo y los escalares son BigInt, y una ronda es un int hasta 2^53-1, cuyos 8 bytes se escriben como dos mitades de 32 bits.

BigInt no es de tiempo constante. En las primitivas se usa solo con datos públicos: la reducción de escalares módulo ℓ y las comprobaciones de onCurve en Ed25519, que solo verifica, y el factor de trabajo de un stanza scrypt. Los secretos de las primitivas (el escalar de X25519, las claves de HMAC, ChaCha20 y Poly1305) van en la aritmética de limbs, sin ramas ni índices que dependan de ellos; ni la VM ni un motor de JavaScript prometen tiempo constante, aun así.

BLS12-381, en cambio, hace con BigInt toda su aritmética. Verificar un release y descifrar un stanza tlock solo manejan datos públicos: la firma de la ronda lo es desde que drand la publica, y el stanza va en la cápsula. Cifrar no: sigma y r son secretos, y el tiempo del código depende de ellos. El escritor (etapa 6) cifrará el stanza tlock donde ese tiempo no se pueda observar, o con una capa del cuerpo de limbs fijos sin ramas que dependan de los datos.

Las etapas siguientes traen el resto del protocolo en este orden:

Etapa	Contenido
4	El resto de la etapa: las rutas y la llave de palabras, el head y la nota pública, la inspección (pasos 1 a 8) y la apertura (pasos 9 a 18)
5	Firma y sello, con los textos de los veredictos
6	Escritor
7	Localizador y claves de autor

Rendimiento

Las cifras del 5 de octubre de 2026 son del PC de desarrollo (Windows 11, Dart 3.13, Node.js 24.9). No hay cifras de un móvil de gama media: están por medir.

Primitivas

dart run tool/bench.dart mide las primitivas en la VM. Compilado a JavaScript:

dart compile js -O2 -o bench.js tool/bench.dart

node bench.js

Operación	VM	Node.js
X25519, un acuerdo de claves	1,2 ms	0,9 ms
Ed25519 estricto, una verificación	4,5 ms	9,4 ms
ChaCha20-Poly1305, 1 MiB, cifrar o descifrar	21 ms	16 ms
PBKDF2-HMAC-SHA256, 600 000 iteraciones (§38.1)	1,1 s	0,9 s
scrypt con logN 16 y r 8 (§29.12)	0,55 s	0,9 s

En la VM, el HMAC de package:crypto, que calcula otra vez los estados de la clave en cada llamada, tarda unos 3,5 s en las mismas 600 000 iteraciones.

La app llama a PBKDF2 y a scrypt en un Isolate (plan, «Rendimiento»).

BLS12-381 y tlock

dart run tool/bls12381_bench.dart mide BLS12-381 y tlock en la VM. Compilado a JavaScript:

dart compile js -O2 -o bench.js tool/bls12381_bench.dart

node -e "globalThis.self = globalThis; require('./bench.js')"

Son medianas de 15 ejecuciones en la VM y de 7 en Node.js:

Operación	VM	Node.js
Decodificar un punto de G1, la firma	3 ms	60 ms
Decodificar un punto de G2, U	1,3 ms	40 ms
Un emparejamiento	11 ms	230 ms
Verificar la firma de una ronda de Quicknet	16 ms	380 ms
La misma verificación, decodificando además la clave pinneada	18 ms	420 ms
Descifrar un stanza tlock (IBE)	20 ms	435 ms
Cifrar un stanza tlock (IBE)	20 ms	460 ms
Pasos 10 y 11: verificar el release y abrir el stanza	35 ms	760 ms

La verificación hace el hash a G1, decodifica la firma y comprueba e(H(m), clave) · e(−firma, G2) = 1 con un solo bucle de Miller para los dos pares y una exponenciación final. El descifrado decodifica U, hace un emparejamiento y comprueba U = r·G2. En los pasos 10 y 11, el paso 11 verifica otra vez el release, como en Go, sin repetir el emparejamiento del paso 10.

Una estimación para un móvil: si uno de gama media, con Dart compilado AOT para ARM64, va de dos a cuatro veces más lento que esta VM, la verificación y el descifrado tardarán entre 30 y 80 ms cada uno, y los pasos 10 y 11 juntos, entre 70 y 150 ms. La app los llama en un Isolate (plan, «Rendimiento»). En la web, el BigInt de dart2js es unas veinte veces más lento que el de la VM; una capa del cuerpo de limbs fijos sería la forma de acelerarlo.

Versiones

Número	Dónde	Hoy
Librería	version de lib/src/version.dart y de pubspec.yaml, que una prueba mantiene iguales	0.1.0-dev
Especificación	specVersion de lib/src/version.dart: la que nombra el campo spec de cada fichero de testdata/	0.11

La rama sigue la versión de la especificación: v0.11, hasta que datekeys-go cierre la v0.12. La etapa 5 se sincronizará ya con la v0.12.

Dependencias

• En ejecución: solo package:crypto, para SHA-1, SHA-2 y HMAC. Todo lo demás es código propio: HKDF, PBKDF2, scrypt, ChaCha20-Poly1305, X25519, Ed25519, BLS12-381, ECDSA, RSA, DER, CMS y CBOR. Hoy la librería usa de package:crypto SHA-512, en Ed25519, y SHA-256, en BLS12-381 y tlock. Las primitivas tienen además su propio SHA-256 con HMAC-SHA256, porque PBKDF2 los necesita con los estados de la clave calculados una vez.
• En desarrollo: solo package:test, aprobado el 5 de octubre de 2026. No hay paquete de lints: las reglas del análisis están en analysis_options.yaml.
• pubspec.lock va en el repositorio, para que las pruebas usen siempre las mismas versiones.

Nada nuevo sin aprobación escrita del autor.

Comprobar

dart pub get

tool/check.sh

tool/check.sh es el gate local, como scripts/check.sh en datekeys-go y npm run verify en datekeys-ts. Comprueba:

• el formato;
• dart analyze --fatal-infos;
• dart test;
• dart test -p node: las pruebas que no leen ficheros corren también compiladas a JavaScript, en Node.js, para comprobar que los enteros son exactos en la web. Las que leen ficheros llevan @TestOn('vm'). Por eso el gate necesita Node.js, como datekeys-ts; lo decidió el autor el 5 de octubre de 2026;
• la copia de testdata/ frente al repositorio de Go, que debe estar al lado, en ../datekeys-go.

Datos de prueba

testdata/ es una copia de datekeys-go/testdata en un commit fijo. testdata/SOURCE.json registra el commit y el SHA-256 de cada fichero, igual que en datekeys-ts. La copia actual es la del tag spec-v0.11 (ae33434).

dart run tool/sync_testdata.dart sync --commit spec-v0.11

dart run tool/sync_testdata.dart check --against ../datekeys-go

• sync lee los ficheros con git en ese commit, así que nunca entran cambios sin commit del repositorio de Go.
• Los ficheros de testdata/ no se editan ni se generan aquí.
• En cada dart test, test/testdata_test.dart comprueba la copia, y que cada fichero nombre specVersion.

test/vectors/ tiene los vectores de las primitivas, de age, de BLS12-381, de tlock y de los formatos. Los escribe Go, con las librerías de la caché de módulos que usa datekeys-go (x/crypto, filippo.io/age, kilic/bls12-381, drand/kyber, kyber-bls12381 y tlock) y sus paquetes provider y agewrap; ningún valor esperado se escribe a mano. Los generadores van en tool/, con //go:build ignore, y se ejecutan en el contexto del módulo de datekeys-go, sin cambiar nada en él. Los de BLS12-381 y tlock dan la misma salida con el tag spec-v0.11 y con el borrador v0.12, y leen ficheros congelados de datekeys-ts, cuya carpeta en esta máquina se llama todavía App:

cd ../datekeys-go && go run ../datekeys-dart/tool/gen_primitive_vectors.go -out ../datekeys-dart/test/vectors

cd ../datekeys-go && go run ../datekeys-dart/tool/gen_age_vectors.go -out ../datekeys-dart/test/vectors

cd ../datekeys-go && go run ../datekeys-dart/tool/bls12381_go_vectors.go ../datekeys-ts/src/lib/dkc/testing/bls12381-vectors.json > ../datekeys-dart/test/vectors/bls12381_vectors.json

cd ../datekeys-go && go run ../datekeys-dart/tool/ibe_go_vectors.go ../datekeys-dart/testdata/fixtures ../datekeys-ts/src/lib/dkc/testing/ibe-vectors.json > ../datekeys-dart/test/vectors/ibe_vectors.json

cd ../datekeys-go && go run ../datekeys-dart/tool/tlock_go_vectors.go ../datekeys-ts/src/lib/dkc/testing/tlock-vectors.json > ../datekeys-dart/test/vectors/tlock_vectors.json

cd ../datekeys-go && go run ../datekeys-dart/tool/release_go_vectors.go ../datekeys-dart/testdata > ../datekeys-dart/test/vectors/release_vectors.json

cd ../datekeys-go && go run ../datekeys-dart/tool/formats_go_vectors.go -testdata ../datekeys-dart/testdata -out ../datekeys-dart/test/vectors

Fichero	Contenido
primitives.json	SHA-256, HMAC, HKDF (RFC 5869), PBKDF2 (con el vector del §38.1), scrypt (RFC 7914), ChaCha20, Poly1305 y ChaCha20-Poly1305 (RFC 8439), X25519 (RFC 7748, BoringSSL y los puntos de orden pequeño), Ed25519 (las 64 primeras líneas de sign.input de Go, cuyas tres primeras son las de la RFC 8032, y sus mutaciones), el Base64 de Go y el Bech32 de age
primitives.g.dart	El mismo JSON como constante de Dart, para las pruebas compiladas a JavaScript, que no leen ficheros
age.json	Ficheros con stanzas X25519 y scrypt, sus cortes y manipulaciones, un corpus de cabeceras contra la gramática del §28.1 y el límite de 2 MiB, y las reglas e identities de agewrap, con el texto del error de Go en cada caso
age_fixtures.json	El PAYLOAD_AGE de cada fixture con su payload_identity, y el INNER_ACCESS_AGE de los time_and_key, que Go saca de OUTER_TIME_AGE con el release del fixture
bls12381_vectors.json	Las 157 codificaciones límite congeladas de datekeys-ts con el veredicto de Go calculado otra vez, y, con una semilla fija, decodificaciones (con la clase del fallo de kilic: formato, curva o subgrupo), sumas, múltiplos, emparejamientos, hashes a G1 (también los mensajes del apéndice J.9.1 del RFC 9380), el mapa de un elemento, los excepcionales incluidos, y firmas BLS sobre G1
ibe_vectors.json	GT y H2, H3 con candidatos rechazados, H4, identidades de rondas, el stanza tlock de cada fixture de testdata/ con sus valores intermedios y su file key, los ciphertexts de kyber y los veredictos de DecryptCCAonG2 sobre copias editadas del stanza de time_only
tlock_vectors.json	El cifrado de kyber con sigma fijo, reproducido byte a byte, y los ciphertexts que escribió datekeys-ts y abrió Go
release_vectors.json	Los veredictos, códigos y textos de provider.Verify, de NewTimeIdentity con su Unwrap y de NewTimeRecipient
formats_*.json	El diferencial de los formatos, de datekeys-go en c531e93: el resultado, el código y el texto de Go en unos 6 400 casos, válidos y rotos en cada capa del §69.1, con una semilla fija y sobre los fixtures editados. Las tramas, PUBLIC_HEADER, CONTROL_CBOR de los tres formatos, la .dkk, los perfiles, las extensiones con sus registros, dk1_, el RFC 3339, las rondas, el relleno hasta L_MAX, la comprobación del relleno de capsule.Open, los codificadores, los límites del §57, BODY y, para la precedencia del §69.1, cada fallo de una lista, solo y con cada otro
formats_vectors.g.dart	Uno de cada ocho casos de cada sección de formats_*.json, como constantes de Dart para las pruebas compiladas a JavaScript

• Los fixtures que leen los generadores son los de testdata/ de este repositorio, la copia sincronizada.
• primitives.json, los cuatro ficheros de BLS12-381 y tlock y los de los formatos salen iguales en cada ejecución. Lo aleatorio de tlock, los ciphertexts de kyber con su sigma y los de datekeys-ts, se lee de los ficheros congelados de datekeys-ts en 289fe71, y Go los descifra otra vez. age, en cambio, saca sus claves y nonces de crypto/rand, así que age.json y age_fixtures.json cambian en cada ejecución; las pruebas leen lo que esté en el repositorio.
• Un fichero age de más de un chunk se guarda como su cabecera, su nonce y su file key: la prueba cifra otra vez el texto documentado y comprueba el SHA-256 del fichero entero antes de leerlo. Las cabeceras de megabytes se escriben como partes que se repiten.
• Las pruebas que corren en Node.js no leen ficheros. Los valores de Go que usan están en primitives.g.dart, formats_vectors.g.dart, test/bls12381_constants.dart y test/ibe_constants.dart. Una prueba en la VM compara los tres últimos con los JSON.

Licencia

Apache-2.0 (LICENSE), como datekeys-go y datekeys-ts. La especificación tiene su propia licencia, CC-BY-4.0.