Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>main
parent
1d737cf6bf
commit
13d7694abc
@ -0,0 +1,69 @@
|
||||
# Plan: la librería Dart (`datekeys-dart`)
|
||||
|
||||
*2 de octubre de 2026. El autor hará la app en Flutter, así que la librería del protocolo hace falta en Dart. Este plan es el esqueleto para discutirlo antes de crear el repo; no hay código todavía.*
|
||||
|
||||
## Qué es
|
||||
|
||||
Un paquete Dart **puro** (sin Flutter, sin plataforma): el mismo protocolo que `datekeys-go` y `datekeys-ts`, para que la app Flutter lo use como dependencia de ruta o de git. Funciona en la VM de Dart, en Flutter móvil y de escritorio, y en la web si no usa `dart:io`. Es la tercera implementación del spec v0.11 y, como la de TypeScript, **no genera datos de prueba propios**: se contrasta con `testdata/` de `datekeys-go`, sincronizado a un commit fijo (`spec-v0.11`, `ae33434`).
|
||||
|
||||
Estado de la máquina: está instalado el SDK de Dart 3.13. No hay Flutter, y la librería no lo necesita; la app sí.
|
||||
|
||||
## Alcance, por etapas
|
||||
|
||||
Cada etapa se cierra con sus pruebas contra los vectores y fixtures de Go, como en TypeScript. El orden sigue la dificultad y lo que desbloquea.
|
||||
|
||||
| Etapa | Contenido | Referencia en TypeScript |
|
||||
|---|---|---|
|
||||
| 0 | Esqueleto del paquete, `dart analyze` y `dart test`, `testdata/` sincronizado con un `SOURCE.json`, licencia Apache-2.0 | `scripts/sync-testdata.mjs` |
|
||||
| 1 | Bytes, errores normativos, CBOR determinista (§58), DER estricto | `bytes.ts`, `errors.ts`, `cbor.ts`, `der.ts` |
|
||||
| 2 | Primitivas: SHA-1/2, HMAC, HKDF, ChaCha20-Poly1305, X25519, Ed25519 estricto; `age` (stanza X25519, STREAM) | `age.ts`, `agefile.ts`, `x25519.ts`, `ed25519strict.ts` |
|
||||
| 3 | BLS12-381 y tlock: emparejamiento, hash a curva, IBE-CCA de drand, verificación de la firma de la ronda | `bls12381.ts`, `ibe.ts`, `tlock.ts`, `release.ts` |
|
||||
| 4 | Formatos: DateKey, perfil, cabecera, control, head, cuerpo, rutas (tablas Unicode 18.0.0), `.dkk`, inspección (pasos 1 a 8) y apertura (9 a 18) | `datekey.ts`, `profile.ts`, `header.ts`, `control.ts`, `head.ts`, `pathrule.ts`, `open.ts`, `open3.ts` |
|
||||
| 5 | Firma y sello: compromisos, `alg` 1 (Ed25519), `alg` 2 (CMS, ECDSA, RSA en `BigInt`) y RFC 3161, y los veredictos | `author.ts`, `cms.ts`, `securitycms.ts`, `security.ts` |
|
||||
| 6 | Escritor: formato 3 con el área de 32 KiB, `time_only` y `time_and_key`, llave de palabras, nota pública | `writer.ts`, `encrypt.ts`, `wordkey.ts`, `note.ts` |
|
||||
| 7 | Localizador y sobre (`datekeys.capsule`), claves de autor `dkauthor1…` | `locator` de Go |
|
||||
|
||||
Fuera del alcance de la librería: la descarga de releases de drand (el cliente HTTP lo pone la app), el almacenamiento y la interfaz. La librería recibe una fuente de releases, como `OpenOptions.Source` en Go.
|
||||
|
||||
## La decisión de dependencias (pendiente del autor)
|
||||
|
||||
Tu regla es evitar dependencias y enmarcar cada una con precisión. En Dart no existe un equivalente de `@noble/*` que ya iba en el bundle de TypeScript, así que hay que elegir. Lo que hace falta y quién puede darlo:
|
||||
|
||||
| Necesidad | Código propio (puerto de TypeScript) | Paquete |
|
||||
|---|---|---|
|
||||
| SHA-1, SHA-2, HMAC | posible | `package:crypto`, oficial de dart-lang |
|
||||
| HKDF, ChaCha20-Poly1305, X25519, Ed25519 | posible, unas 600 líneas | `package:cryptography` o `package:pointycastle` |
|
||||
| Ed25519 estricto (las cuatro condiciones del §29.9) | **propio en cualquier caso**: ningún paquete ofrece el perfil estricto | — |
|
||||
| ECDSA P-256/384/521 y RSA (solo verificar) | propio, con `BigInt` | `package:pointycastle` |
|
||||
| BLS12-381, emparejamiento, hash a curva, IBE de tlock | **propio en cualquier caso**: no hay un paquete Dart mantenido que lo haga | — |
|
||||
| CBOR determinista del §58 | propio, como en las otras dos | — |
|
||||
|
||||
**Mi recomendación: solo `package:crypto`** (oficial, pequeño, mantenido por el equipo de Dart) **y todo lo demás propio**, como hace Go con la biblioteca estándar y TypeScript con tres paquetes de noble. Razones: lo estricto (Ed25519, DER, CBOR) tiene que ser propio de todos modos; un paquete de criptografía general aceptaría cosas que el perfil rechaza y habría que envolverlo; y menos dependencias son menos superficie en una app que guarda secretos. El coste es real: Ed25519, X25519, ChaCha20-Poly1305 y BLS12-381 propios son unas 2 500 líneas que hay que probar a fondo, y una implementación propia no tiene la aceleración nativa que ofrece `cryptography_flutter`.
|
||||
|
||||
Alternativa: `package:crypto` más `package:cryptography` para ChaCha20-Poly1305, X25519 y Ed25519 (con nuestro perfil estricto por encima), y propio solo BLS12-381, ECDSA, RSA, DER, CMS y CBOR. Menos código, una dependencia más y, con `cryptography_flutter`, mejor rendimiento en móvil.
|
||||
|
||||
## Rendimiento
|
||||
|
||||
El único cuello de botella real es BLS12-381: abrir una cápsula hace una verificación de la firma de la ronda y un emparejamiento. Con `BigInt` en la VM de Dart tarda del orden de cientos de milisegundos, y bastante más compilado a JavaScript. La app debe llamarlo en un `Isolate` para no congelar la interfaz; la librería no lo hace por sí misma.
|
||||
|
||||
## Estructura del repo
|
||||
|
||||
`G:\bussines\datekeys\datekeys-dart`, repo independiente, rama `v0.11` para seguir al spec como los otros dos:
|
||||
|
||||
```
|
||||
datekeys-dart/
|
||||
pubspec.yaml # name: datekeys; sin Flutter; entorno de Dart 3.x
|
||||
lib/datekeys.dart # la API pública, como index.ts
|
||||
lib/src/… # un fichero por módulo de la tabla
|
||||
test/… # dart test, contra testdata/
|
||||
testdata/ # sincronizado desde datekeys-go con su SOURCE.json
|
||||
tool/sync_testdata.dart # equivalente de sync-testdata.mjs
|
||||
```
|
||||
|
||||
La app Flutter lo usa con `datekeys: { path: ../datekeys-dart }`, o con una dependencia de git del Gitea cuando haya remoto.
|
||||
|
||||
## Lo que falta decidir
|
||||
|
||||
1. **Dependencias:** `package:crypto` solo (recomendado) o `package:crypto` más `package:cryptography`.
|
||||
2. **Nombre del paquete:** `datekeys`, sin publicar en pub.dev.
|
||||
3. **Si las etapas 1 a 5 (lectura y verificación) van antes que el escritor**, como hicimos en TypeScript. Es lo que propongo: una app que abre y verifica cápsulas ya es útil, y el escritor se prueba contra los mismos fixtures.
|
||||
Loading…
Reference in new issue