diff --git a/CHANGELOG.md b/CHANGELOG.md index b827339..4118468 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,34 @@ Cambios notables de la librería Dart. El proyecto usa versionado semántico; mi ## Especificación 0.11, en la rama `v0.11` — sin versión +### Etapa 5c: la firma de `alg` 2 y el sello de `seal_type` 2 en los veredictos (06-10-2026) + +- **Los veredictos de la firma con certificados y del sello RFC 3161** (`lib/src/securitycms.dart`), port de `evaluateCMS`, `signerLine` y `evaluateSeal` de `signature2.go` de `datekeys-go` en `c531e93`, el borrador v0.12, sobre el lector de CMS de la 5a, con el mismo orden de comprobaciones: + - `SIGNERS` con su perfil, de 1 a 16 entradas en orden estricto, y después la `SignedData`: un fallo de cualquiera de los dos es F1; + - cada firmante exigido, en el orden de `SIGNERS`, y cada ajeno, en el orden de la codificación, con su resultado: válido, inválido, ausente, no verificable, sin sello, con el sello inválido o con el certificado fuera de validez en t, el instante de su sello, con los dos extremos incluidos; + - F2 si un exigido es inválido, F5 si falta algo o hay una clave 3, y F6 si todos son válidos y están sellados, con el `Detail` de los firmantes; + - el sello sobre `SEAL_SUBJECT`: S2 por la forma, S1 por un algoritmo fuera de la tabla o un `messageImprint` que no es SHA-256, S3 si no verifica, y S4 o S5 con la autoridad y t; + - un `round_time` en el instante cero de Go, 0001-01-01T00:00:00Z, cuenta como ninguno, como `IsZero`, y `Verdicts.sealedAt` no cuenta un sello en ese instante, como `SealedAt`. +- **El evaluador por defecto lo evalúa todo como Go.** `cmsReader` es el `cms` por defecto de `evaluateSecurity`, y con él el de `evaluateSecurityInput` y de la apertura: nada que Go evalúe queda sin evaluar. Con `cms: null`, la firma de `alg` 2 y el sello de `seal_type` 2 siguen quedando sin evaluar. +- **`lib/datekeys.dart`** exporta `encodeSigners` y `maxSigners`, como `EncodeSigners` y `MaxSigners` del paquete `capsule` de Go, y `cmsReader`. `cms.dart` sigue interno. +- **Vectores de Go:** `tool/security_go_vectors.go` escribe además `securitycms_vectors.json`: 760 áreas cuya firma CMS o sello RFC 3161 hace el propio generador, como los hace `internal/cms/cmstest` para las pruebas de la referencia, con los veredictos de `EvaluateSecurityIn`, las líneas, el detalle de cada firmante y del sello y el sello más temprano: + - un firmante exigido de cada resultado junto a ajenos de cada resultado, sin `round_time`, al abrir en el instante de los sellos, en el contexto de otro head y con una clave 3; tres firmantes exigidos, sacados de una semilla; `SIGNERS` de 16 y 17 entradas; + - la validez de un certificado en el instante de su sello, al nanosegundo, de un `UTCTime` a un `GeneralizedTime` y con diez cifras de fracción, y la de la autoridad en el de su token; + - t más la precisión frente a `round_time`, a un nanosegundo de cada lado, con cada forma de la precisión, en el instante cero de Go y en el último segundo de 9999; + - un sello de cada veredicto junto a una firma de cada veredicto, y mutaciones de la `SignedData`, de `SIGNERS` y de los tokens. + + `cmstest` no se puede importar desde fuera del árbol de `datekeys-go`: el generador reescribe la parte que necesita. Las claves salen de etiquetas, ECDSA firma con el nonce del RFC 6979 y RSA con PKCS #1 v1.5, así que el fichero sale igual en cada ejecución, y `security_vectors.json` sale como antes. `securitycms_vectors.g.dart` lleva, para Node.js, una parte de los casos, con cada par de veredictos de cada grupo, y los fixtures `format3_signed_cms` y `format3_sealed`. +- **Pruebas.** Todo se compara con Go: + - los 135 casos de `security_cms.json`, con el resultado de cada firmante, el sello y las líneas, sin ningún carácter de control ni bidireccional; + - los 24 de `security.json`, ya enteros; + - las 56 firmas de `alg` 2 y los 105 sellos de `seal_type` 2 de `security_vectors.json` que la 5b dejaba sin evaluar; + - los 760 casos de `securitycms_vectors.json`, con su detalle y su sello más temprano; + - y los fixtures `format3_signed_cms` y `format3_sealed`: su área frente a su registro, y su apertura con cada credencial de `open_cases.json`. + + En Node.js corren una parte de los vectores y la apertura entera de los dos fixtures. 150 pruebas nuevas en la VM y 10 en Node.js: 1572 y 332 en total. +- **Fallos inyectados**, uno a uno y revertidos: los ocho del encargo, el primero en dos formas, y tres más. Las pruebas los detectan todos, en la VM y en Node.js: un certificado comprobado con el reloj de la apertura, y otro en `round_time`, en lugar de en el instante de su sello; un sello aceptado con t más la precisión después de `round_time`; F6 sin que todos los firmantes sean válidos; más de 16 firmantes aceptados; el aviso de los sellos ausente de las líneas de F6; un nombre de 65 puntos de código mostrado; un `messageImprint` que no es SHA-256 aceptado; el resultado de un firmante ajeno en inglés; los firmantes ajenos en el orden inverso; un sello de la clave 3 comprobado sin el `SIG_PART` de la clave 2; y una clave 3 junto a una firma de `alg` 2 ignorada. Dos se escapaban al principio en Node.js, más de 16 firmantes y el orden de los ajenos, porque sus casos solo los leían las pruebas de la VM: la parte de Node.js lleva ahora `SIGNERS` de 16 y 17 entradas y dos firmantes ajenos. +- **`tool/open_bench.dart`** abre también los dos fixtures y mide, dentro de cada apertura, la evaluación de su área de seguridad: en la VM, una apertura tarda unos 55 ms, de los que el área son 9,4 ms con la firma de dos firmantes sellados y 8,5 ms con la de `alg` 1 y el sello; compilada a JavaScript, unos 0,9 s, de los que el área son 0,13 y 0,05 s. Las cifras, en el README. + ### Etapa 5a: el lector de CMS, ECDSA y RSA (05-10-2026) - **El lector de las firmas CMS y de los sellos RFC 3161** (`lib/src/cms.dart`), port de `internal/cms` de `datekeys-go` en `c531e93`, con el perfil de certificado del borrador v0.12 (§29.7, §29.10, §29.11), el mismo orden de comprobaciones y los textos de Go: diff --git a/README.md b/README.md index 75fc844..20a6fd4 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@ Es la tercera implementación de la especificación, después de la de referenci ## Estado -Están hechas las etapas 0 a 4 del plan (`docs/PLAN_dart.md` del espacio de trabajo) y las partes 5a y 5b de la etapa 5: +Están hechas las etapas 0 a 5 del plan (`docs/PLAN_dart.md` del espacio de trabajo): - 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`; @@ -15,12 +15,14 @@ Están hechas las etapas 0 a 4 del plan (`docs/PLAN_dart.md` del espacio de trab - la 4a, las reglas de rutas y de textos con las tablas de Unicode 18.0.0, y la llave de palabras; - la 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; - la 4c, el head del formato 3, la nota pública, la inspección (pasos 1 a 8) y la apertura (pasos 9 a 18) de los tres formatos; -- la parte 5b de la etapa 5: los compromisos de lo que firma un autor y sella un sello, `SECURITY_CBOR`, la firma de `alg` 1 y los veredictos con sus textos y sus líneas; -- la parte 5a de la etapa 5: el lector de las firmas CMS y de los sellos RFC 3161 con el perfil de certificado del borrador v0.12, ECDSA y RSA. Es interno, y la parte 5c lo une a los veredictos. +- la etapa 5, en tres partes: + - la 5b, los compromisos de lo que firma un autor y sella un sello, `SECURITY_CBOR`, la firma de `alg` 1 y los veredictos con sus textos y sus líneas; + - la 5a, el lector de las firmas CMS y de los sellos RFC 3161 con el perfil de certificado del borrador v0.12, ECDSA y RSA. Es interno; + - la 5c, la firma de `alg` 2 y el sello de `seal_type` 2 en los veredictos, que une el lector de la 5a a la evaluación de la 5b. -La librería ya abre cápsulas reales, de los tres formatos, con todas sus credenciales, y evalúa su área de seguridad como Go: la firma de `alg` 1 y todos los veredictos de su forma. La firma de `alg` 2 y el sello de `seal_type` 2 necesitan el lector de CMS: hasta la parte 5c quedan sin evaluar, nunca con un veredicto supuesto. +La librería ya abre cápsulas reales, de los tres formatos, con todas sus credenciales, y evalúa toda su área de seguridad como Go: la firma de `alg` 1, la de `alg` 2 con certificados, el sello de `seal_type` 2 y todos los veredictos de su forma. -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. Las partes 4a y 4b también: la 4a, en la rama `stage4a`, se integró encima de la 4b el mismo día. La 4c se hizo después, en la rama `v0.11`, y la 5b también, en paralelo con la 5a, el lector de CMS, que se hizo en la rama `stage5a` y se integró encima de la 5b el mismo día. +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. Las partes 4a y 4b también: la 4a, en la rama `stage4a`, se integró encima de la 4b el mismo día. La 4c se hizo después, en la rama `v0.11`, y la 5b también, en paralelo con la 5a, el lector de CMS, que se hizo en la rama `stage5a` y se integró encima de la 5b el mismo día. La 5c, que necesitaba las dos, se hizo después, en la rama `v0.11`. 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: @@ -155,7 +157,7 @@ Notas de la parte 5b: - `evaluateSignature(signers, value, hasSeal, context)` da null, que es F1, o F2, F5 o F6 con el `Detail` de los firmantes, como `evaluateCMS` de Go; - `evaluateSeal(token, signature, context)` da de S1 a S5, y con S4 y S5 la autoridad y t, como `evaluateSeal` de Go. - `evaluateSecurity` lo recibe en `cms`. Sin él, la firma de `alg` 2 y el sello de `seal_type` 2 en un contexto quedan en null, sin evaluar, y la otra parte se evalúa igual: `Verdicts.evaluated` es falso y las líneas son las de la otra parte. Lo que lance el lector, o un veredicto fuera de su rango, es F1 o S2. La 5c lo implementará en `securitycms.dart` y lo pondrá en `evaluateSecurityInput`; `holderText` ya está aquí para ella. + `evaluateSecurity` lo recibe en `cms`. Sin él, la firma de `alg` 2 y el sello de `seal_type` 2 en un contexto quedan en null, sin evaluar, y la otra parte se evalúa igual: `Verdicts.evaluated` es falso y las líneas son las de la otra parte. Lo que lance el lector, o un veredicto fuera de su rango, es F1 o S2. La 5c lo implementa en `securitycms.dart`, `cmsReader`, que es desde entonces el `cms` por defecto; `holderText` estaba ya aquí para ella. - **Las líneas** son las de Go, byte a byte: los nombres de un certificado entre « y », la autoridad de cada sello en las de F6 con su aviso, los resultados en español y t en RFC 3339 con la fracción del sello. Partir cada línea en filas con ` ↳ ` (§29.7) es de la CLI de Go (`cmd/datekeys/present.go`), no del paquete `capsule`: no se porta, y lo hará la app en una salida de texto. - **El contexto de la apertura** es `newSecurityContext` con el `head_digest`: un control cuyo `CONTROL_SIG` no se puede codificar deja `control_commit` a cero, como en Go, y la firma no verifica. - **`authorCode`** toma los bytes del mensaje como Go toma los de un string: un byte que no es UTF-8 se lee como U+FFFD. @@ -179,6 +181,20 @@ Notas de la parte 5a: - **Los vectores** salen de la rama `v0.12` de Go en `c531e93`, en una exportación suya. La 5a se hizo con `testdata/` todavía en `spec-v0.11`, así que toma del `security_cms.json` y de los fixtures del borrador lo que necesita a través de su generador, de la exportación. - **Interno**, como `internal/cms`: `lib/datekeys.dart` no lo exporta. +La parte 5c de la etapa 5 porta `signature2.go` de `datekeys-go` en `c531e93`, el borrador v0.12: une el lector de CMS de la 5a a la evaluación de la 5b, con el mismo orden de comprobaciones, los mismos veredictos, el mismo resultado de cada firmante y el mismo detalle, que las líneas de la 5b escriben como Go: + +| Módulo | Contenido | En Go | +|---|---|---| +| `lib/src/securitycms.dart` | `cmsReader`, el `CmsEvaluator` por defecto: la firma de `alg` 2 (`SIGNERS`, la `SignedData`, la línea de cada firmante exigido y de cada ajeno, y F2, F5 o F6 con su detalle) y el sello de `seal_type` 2 (de S1 a S5, con la autoridad y t); `encodeSigners` y `maxSigners` | `evaluateCMS`, `signerLine`, `evaluateSeal`, `EncodeSigners` y `MaxSigners` de `signature2.go` | + +Notas de la parte 5c: +- **El orden de las comprobaciones** es el de Go y el del §29.10: `SIGNERS`, con su perfil y como mucho 16 entradas, antes que la `SignedData`, y un fallo de cualquiera de los dos es F1. Después, cada firmante exigido, en el orden de `SIGNERS`, y cada ajeno, en el orden de la codificación, con su resultado: no verificable, inválido, sin sello, con el sello inválido, fuera de validez o válido. El sello de un firmante es su token, leído con el perfil del §29.11 sobre el valor de su firma: S2, S1 o S3 es un sello inválido, y su `messageImprint` puede usar cualquier hash de la tabla. F2 va antes que F5, y una clave 3 junto a una firma de `alg` 2 es F5. +- **La validez de un certificado** se comprueba en t, el instante de su sello, con los dos extremos incluidos y al nanosegundo (§29.10, paso 6), como `ValidAt(tok.GenTime)` de Go: ni en `round_time` ni en el reloj de la apertura. La de la autoridad, en `genTime`, la comprueba el lector de la 5a. +- **Antes de la fecha de apertura** quiere decir t más la precisión estrictamente antes de `round_time`. Sin `round_time` ningún sello es anterior, y un `round_time` en el instante cero de Go, 0001-01-01T00:00:00Z, cuenta como ninguno, como `IsZero` en Go. `Verdicts.sealedAt` tampoco cuenta un sello en ese instante, como `SealedAt`; su línea lo muestra igual. +- **Lo que lanza el lector de CMS** con una firma o un token que incumple su perfil, una `CmsException`, es un veredicto: F1, un sello inválido, S2 o S1. Cualquier otra cosa llega a `evaluateSecurity`, que la hace un fallo de su parte, F1 o S2, como Go recupera un panic. +- **El evaluador por defecto.** `cmsReader` es el `cms` por defecto de `evaluateSecurity`, y con él el de `evaluateSecurityInput` y de la apertura: nada que Go evalúe queda sin evaluar. Con `cms: null` la firma de `alg` 2 y el sello de `seal_type` 2 quedan en null, para quien no quiera pagar su coste, por ejemplo en la web (ver «Rendimiento»). +- **Lo que se exporta** es lo del paquete `capsule` de Go: `encodeSigners` y `maxSigners`, y `cmsReader`. `cms.dart` sigue interno. + 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`; @@ -199,7 +215,6 @@ Las etapas siguientes traen el resto del protocolo en este orden: | Etapa | Contenido | |---|---| -| 5 | La parte 5c: la firma de `alg` 2 y el sello de `seal_type` 2 sobre el lector de CMS de la 5a, unidos a los veredictos de la 5b en el evaluador de la apertura | | 6 | Escritor | | 7 | Localizador y claves de autor | @@ -307,10 +322,12 @@ Cada apertura verifica su release: entre dos, la de otro release hace que cada u | Abrir `format2_time_and_key_recipients` con su `.dkk`, 16 stanzas | 73 ms | 0,82 s | | Abrir `format3_single`, un fichero | 52 ms | 0,81 s | | Abrir `format3_time_and_key_portable` con su `.dkk` | 72 ms | 0,82 s | +| Abrir `format3_signed_cms`, una firma de `alg` 2 de dos firmantes, cada uno con su sello | 55 ms, de ellos el área de seguridad 9,4 ms | 0,95 s, de ellos el área 0,13 s | +| Abrir `format3_sealed`, una firma de `alg` 1 y un sello de `seal_type` 2 | 55 ms, de ellos el área 8,5 ms | 0,89 s, de ellos el área 0,05 s | | 64 MiB en el formato 1, en streaming | 1,50 s, 43 MiB/s | 16 MiB: 0,73 s, 22 MiB/s | | 64 MiB en un fichero del formato 3, en streaming | 2,64 s, 24 MiB/s | 16 MiB: 0,92 s, 17 MiB/s | -Una apertura pequeña es casi toda los pasos 10 y 11, la verificación del release y el IBE. En una grande manda ChaCha20-Poly1305, unos 21 ms por MiB en la VM; en el formato 3 se suma el SHA-256 de cada fichero, otros 17 ms por MiB, el de este código como el de `package:crypto`. La memoria no crece con el tamaño: la fuente se lee por tramos de 1 MiB y el texto llega al sink chunk a chunk. +Una apertura pequeña es casi toda los pasos 10 y 11, la verificación del release y el IBE. El área de seguridad de las dos cápsulas con certificados la evalúa el evaluador por defecto, con el lector de CMS, y su tiempo se mide dentro de la apertura; sus dos filas son del 6 de octubre. En `format3_signed_cms` son cuatro verificaciones, la ECDSA de P-256 de Ana, la RSA-2048 de Luis y las ECDSA de P-256 de sus dos sellos; en `format3_sealed`, la de Ed25519 de la firma de `alg` 1 y la de P-256 del sello. En Node.js manda la ECDSA sobre el `BigInt` compilado a JavaScript (ver «ECDSA, RSA y CMS»). En una grande manda ChaCha20-Poly1305, unos 21 ms por MiB en la VM; en el formato 3 se suma el SHA-256 de cada fichero, otros 17 ms por MiB, el de este código como el de `package:crypto`. La memoria no crece con el tamaño: la fuente se lee por tramos de 1 MiB y el texto llega al sink chunk a chunk. ### ECDSA, RSA y CMS @@ -390,7 +407,7 @@ dart run tool/sync_testdata.dart check --against ../datekeys-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, de las reglas de rutas y textos, de la llave de palabras, de los formatos, de la apertura, del área de seguridad y del lector de CMS. 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, como `provider`, `agewrap`, `capsule`, `internal/pathrule`, `internal/testkit` y `wordkey`; 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 las rutas, de la apertura y del lector de CMS, en una exportación suya, y el último, `tool/cms_go_vectors_test.go`, como una prueba de Go. 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`: +`test/vectors/` tiene los vectores de las primitivas, de `age`, de BLS12-381, de tlock, de las reglas de rutas y textos, de la llave de palabras, de los formatos, de la apertura, del área de seguridad, de la firma con certificados y el sello, y del lector de CMS. 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, como `provider`, `agewrap`, `capsule`, `internal/pathrule`, `internal/testkit` y `wordkey`; 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 las rutas, de la apertura y del lector de CMS, en una exportación suya, y el último, `tool/cms_go_vectors_test.go`, como una prueba de Go. 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`: ```bash cd ../datekeys-go && go run ../datekeys-dart/tool/gen_primitive_vectors.go -out ../datekeys-dart/test/vectors @@ -432,7 +449,7 @@ cd ../datekeys-go && go run ../datekeys-dart/tool/mutation_go_texts.go ../dateke cd ../datekeys-go && go run ../datekeys-dart/tool/security_go_vectors.go -testdata ../datekeys-dart/testdata -out ../datekeys-dart/test/vectors ``` -`holderText` no se exporta en el paquete `capsule`: `tool/security_go_vectors.go` llega a él con `go:linkname`, que Go permite con un paquete de fuera de la biblioteca estándar. +`holderText` no se exporta en el paquete `capsule`: `tool/security_go_vectors.go` llega a él con `go:linkname`, que Go permite con un paquete de fuera de la biblioteca estándar. El mismo programa escribe los vectores de la parte 5c, `securitycms_vectors.json`, con firmas CMS y tokens RFC 3161 que hace él mismo como los hace `internal/cms/cmstest` para las pruebas de la referencia: ese paquete no se puede importar desde fuera del árbol de `datekeys-go`, así que el generador reescribe la parte que necesita. Las claves salen de etiquetas, ECDSA firma con el nonce del RFC 6979 y RSA con PKCS #1 v1.5, así que la salida no depende de `crypto/rand`. `internal/pathrule` solo se puede importar desde el árbol de `datekeys-go`, así que el generador de las rutas corre en una exportación suya, hecha con `git archive`, sin tocar el repositorio: @@ -494,6 +511,8 @@ rm -rf "$tmp" | `open_vectors.g.dart` | Siete fixtures pequeños, lo que sus registros dicen de ellos y una parte de los cuatro ficheros `open_*.json`, como constantes de Dart | | `security_vectors.json` | El área de seguridad del paquete `capsule`: los compromisos, también `ControlCommit` del control de cada fixture en cada formato; los codificadores; 1730 evaluaciones con `EvaluateSecurityIn` en 23 contextos y sin contexto, del mapa exterior, de `author-signature` y de `seal` rotos de todas las formas de sus esquemas y en sus límites, de firmas de `alg` 1 válidas e inválidas, guardadas o no, con los casos de «Taming the many EdDSAs» hechos sobre `AUTHOR_MESSAGE`, y de mutaciones de una semilla fija, con los veredictos, las líneas, `alg` y `seal_type` leídos y las partes que solo evalúa el lector de CMS; las líneas y el sello más temprano de veredictos con cada detalle; y `holderText` | | `security_vectors.g.dart` | Todo `security_vectors.json` salvo siete de cada ocho evaluaciones, como constante de Dart | +| `securitycms_vectors.json` | La firma de `alg` 2 y el sello de `seal_type` 2 como los evalúa `EvaluateSecurityIn`: 760 áreas que hace el generador, con los veredictos, las líneas, el detalle de cada firmante y del sello y el sello más temprano. Un firmante exigido de cada resultado junto a ajenos de cada resultado, sin `round_time`, al abrir en el instante de los sellos, en el contexto de otro head y con una clave 3; tres firmantes exigidos sacados de una semilla; `SIGNERS` de 16 y 17 entradas; la validez de un certificado en el instante de su sello, al nanosegundo, de un `UTCTime` a un `GeneralizedTime` y con diez cifras de fracción, y la de la autoridad; t más la precisión frente a `round_time` a un nanosegundo de cada lado, con cada forma de la precisión, en el instante cero de Go y en el último segundo de 9999; un sello de cada veredicto junto a una firma de cada veredicto; y mutaciones de la `SignedData`, de `SIGNERS` y de los tokens. Los certificados, los tokens y los `SignerInfo` que se repiten van una vez, como trozos | +| `securitycms_vectors.g.dart` | Una parte de `securitycms_vectors.json`, con cada par de veredictos de cada grupo, y los fixtures `format3_signed_cms` y `format3_sealed` con lo que dicen sus registros, como constantes de Dart | | `cms_ecdsa.json` | Las curvas de `crypto/elliptic`; puntos que lee o no `ecdsa.ParseUncompressedPublicKey`; y firmas de `ecdsa.VerifyASN1`: válidas, con s por encima de n/2, r o s de n o más, cero, negativas o no mínimas, en otra codificación, sobre otro hash, y con claves de d = 1 y d = n − 1, con u1·G + u2·Q en el infinito | | `cms_rsa.json` | Claves de 2048, 2049, 3072, 4095 y 4096 bits con los exponentes 3, 65 537 y 2³¹ − 1, y firmas de `rsa.VerifyPKCS1v15` y `rsa.VerifyPSS` como las comprueba `internal/cms`: válidas, con un byte más o menos, de n o más, y codificaciones hechas a mano y firmadas con la clave privada, cada una con un defecto de su relleno | | `cms_certs.json` | `cms.ParseCert`, sus campos, `Holder`, `IssuerName` y `ValidAt` alrededor de los dos extremos, en los certificados de las pruebas de `internal/cms`, en identificadores cuyo último arco da la vuelta en 32 o 64 bits, y en certificados editados nodo a nodo y bit a bit | @@ -504,11 +523,11 @@ rm -rf "$tmp" | `cms_vectors.g.dart` | Una parte de cada fichero `cms_*.json`, como constantes de Dart | - 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, `pathrule_vectors.json`, `wordkey_vectors.json`, los de los formatos, `security_vectors.json` y los del lector de CMS salen iguales en cada ejecución, estos últimos con Go 1.26.8. 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. `age.json` no lee `testdata/` y es el congelado de la etapa 2; `age_fixtures.json` se escribió otra vez con el `testdata/` de la v0.12, y fuera de los dos fixtures nuevos y del de `seal_type` 4294967295 sale igual. +- `primitives.json`, los cuatro ficheros de BLS12-381 y tlock, `pathrule_vectors.json`, `wordkey_vectors.json`, los de los formatos, `security_vectors.json`, `securitycms_vectors.json` y los del lector de CMS salen iguales en cada ejecución, estos últimos con Go 1.26.8. 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. `age.json` no lee `testdata/` y es el congelado de la etapa 2; `age_fixtures.json` se escribió otra vez con el `testdata/` de la v0.12, y fuera de los dos fixtures nuevos y del de `seal_type` 4294967295 sale igual. - 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. - Los casos de `open_cases.json` que editan un fixture lo sellan otra vez como el `testkit` de la referencia, con las file keys y los nonces del fixture, así que salen iguales en cada ejecución, y se guardan como ediciones del fixture. -- Los ficheros del lector de CMS escriben una vez por fichero los certificados que se repiten: el DER de un caso es entonces una lista de trozos, el hexadecimal de unos bytes o el índice de un certificado, con el SHA-256 del resultado. -- Las pruebas que corren en Node.js no leen ficheros. Los valores de Go que usan están en `primitives.g.dart`, `pathrule_vectors.g.dart`, `wordkey_vectors.g.dart`, `formats_vectors.g.dart`, `open_vectors.g.dart`, `security_vectors.g.dart`, `cms_vectors.g.dart`, `test/bls12381_constants.dart` y `test/ibe_constants.dart`. Unas pruebas en la VM comparan con los JSON los de las rutas, la llave de palabras, los formatos, la apertura, el área de seguridad, el lector de CMS, BLS12-381 y el IBE. +- Los ficheros del lector de CMS escriben una vez por fichero los certificados que se repiten: el DER de un caso es entonces una lista de trozos, el hexadecimal de unos bytes o el índice de un certificado, con el SHA-256 del resultado. `securitycms_vectors.json` hace lo mismo con los certificados, los tokens y los `SignerInfo`, cada trozo hecho a su vez de los anteriores, y una mutación se guarda como su base, el objetivo de la edición (la `SignedData`, `SIGNERS` o el token) y la edición. +- Las pruebas que corren en Node.js no leen ficheros. Los valores de Go que usan están en `primitives.g.dart`, `pathrule_vectors.g.dart`, `wordkey_vectors.g.dart`, `formats_vectors.g.dart`, `open_vectors.g.dart`, `security_vectors.g.dart`, `securitycms_vectors.g.dart`, `cms_vectors.g.dart`, `test/bls12381_constants.dart` y `test/ibe_constants.dart`. Unas pruebas en la VM comparan con los JSON los de las rutas, la llave de palabras, los formatos, la apertura, el área de seguridad, la firma con certificados y el sello, el lector de CMS, BLS12-381 y el IBE, y con `testdata/` los fixtures que llevan. ## Licencia