datekeys-doc/spec_v0.11/llave_palabras.md

Llave de palabras (propuesta para la versión siguiente del spec)

1 de octubre de 2026. Hecho en la página (App, rama v0.10), tal como lo pidió el autor después: las palabras las elige quien crea la cápsula, al menos 6, y PBKDF2 en vez de scrypt, sin dependencias. Falta llevarlo al spec y a la CLI de Go. Pedida por el autor: «nadie va a tener idea de cómo hacer ese tipo de claves» (las de age), «si lo hacemos como un wallet a partir de 6 palabras», y «si quiere el archivo, que lo guarde, y si no, que apunte las palabras». Pendiente de diseño detallado, de spec y de implementación, primero en Go y después en la página.

Qué es

La llave portable de una cápsula time_and_key (§38) se puede guardar de dos formas, y quien la crea elige una o las dos:

• el fichero .dkk, como hoy;
• 6 palabras al azar, apuntadas a mano, como la frase de recuperación de un wallet.

Las dos son la misma llave: el fichero y las palabras abren la misma entrada X25519 de INNER_ACCESS_AGE. El formato de la cápsula no cambia: es una credencial X25519 más (§37, §39).

Cómo funciona

1. Al crear la cápsula, el escritor genera 6 palabras al azar de una lista fija de 2048, con una suma de control que detecte una palabra mal escrita, como BIP-39. No las elige la persona: su entropía es conocida, 66 bits.
2. De las palabras sale I_ACCESS: una derivación lenta, scrypt, de las palabras normalizadas con una sal que incluye el capsule_id, da los 32 bytes de la identidad X25519. Con el capsule_id en la sal, cada cápsula exige su propio ataque.
3. La cápsula guarda la parte pública como una de sus 16 entradas. El .dkk, si se descarga, lleva esa misma identidad.
4. Para abrir, se escriben las 6 palabras. El lector recalcula I_ACCESS con el capsule_id de PUBLIC_HEADER y prueba las entradas, como con un .dkk.

Seguridad

• Antes de la fecha nadie puede probar palabras: las entradas de acceso van dentro de OUTER_TIME_AGE.
• Pasada la fecha, quien tenga el .dkc puede probarlas sin conexión. 66 bits con scrypt hacen inviable recorrerlas. Con 8 o 12 palabras el margen es mayor, a cambio de apuntar más.
• La lista, la normalización (espacios, mayúsculas y acentos), la suma de control, los parámetros de scrypt y la sal quedan fijados en el spec, para que la CLI de Go y la página abran las mismas cápsulas.

Dependencias

scrypt ya está en las dos implementaciones: Go lo tiene en golang.org/x/crypto, que age ya usa, y la página en @noble/hashes. No hace falta ninguna dependencia nueva.

Preguntas para el autor

1. ¿6 palabras, o 8 o 12?
2. ¿La lista española de BIP-39, la inglesa, o una propia? Hay que comprobar la licencia de la que se elija antes de incluirla.
3. ¿La página ofrece las palabras por defecto y el .dkk como opción, o al revés?

Lo implementado en la página (01-10)

• Las palabras las escribe quien crea la cápsula, al menos 6. La página no las genera.
• Normalización: NFD, sin las marcas U+0300 a U+036F, en minúsculas, separadas por espacios y unidas con un espacio.
• Derivación: PBKDF2-HMAC-SHA256, 600.000 vueltas, 32 bytes. La contraseña son las palabras normalizadas. La sal es DateKeys llave de palabras v1|<chain hash en hex>|<ronda>.
• Los 32 bytes son la identidad X25519. Su clave pública entra como una persona de age más, así que el formato no cambia.
• Para que la CLI abra estas cápsulas, Go tiene que hacer exactamente esto. PBKDF2 está en la biblioteca estándar desde Go 1.24 (crypto/pbkdf2).