Codificador esteganográfico

Principio: el mensaje se cifra primero (XChaCha20-Poly1305); después, el texto cifrado se reparte entre los bloques de una cuadrícula de números — el resto es ruido uniforme. La confidencialidad procede del cifrado; la geometría solo oculta dónde se encuentra el texto cifrado. Sin la clave, la cuadrícula es estadísticamente indistinguible del ruido aleatorio: es el χ² mostrado en la pestaña Demo el que lo comprueba, no una afirmación.

Clave maestra: 256 bits, generada aleatoriamente (o derivada de una passphrase, o de una sesión Exchange). Una sola clave, derivada mediante HKDF-SHA256 en una clave de cifrado y una clave de gramática — estos dos usos nunca comparten el mismo material de clave.

Gramática: la clave de gramática asigna a cada bloque de la cuadrícula una función (puro / estructurado / mensaje) y una forma, extraídas del Referente 256 (cruz ansada) o de un referente de 6×6 regenerado para Carter-Random. Los bloques «estructurados» y «mensaje» son estadísticamente indistinguibles entre sí sin la clave — existen precisamente por esa razón, no para portar contenido.

Autenticación: una clave o unos datos incorrectos fallan explícitamente en la autenticación (Poly1305); nunca se devuelven como una lectura falsa verosímil.

Variantes: Carter-256 (referente cruz ansada fijo) y Carter-Random (referente de 6×6 regenerado por clave) están portadas y verificadas en JavaScript frente a los vectores producidos por el código Python. Las demás variantes del mismo sistema (Deniable, Carter-360, Carter-Mix, Carter-18, Carter-Hybrid) existen del lado de Python, pero aún no están portadas al navegador.

Kerckhoffs: el sistema respeta el principio de Kerckhoffs (1883) — el algoritmo es enteramente público; el secreto reside únicamente en las claves y, opcionalmente, en referentes personalizados.

Patente anterior: FR2865054 (2004) — composición automatizada de un motivo simbólico a partir de una relación matemática.

Contacto: anibaledel@gmail.com · anibal-amiot.com · Wikidata Q141191562

1. Exchange (X25519) — intercambio de claves autenticado por triple Diffie-Hellman sobre la curva Curve25519 (nativo en la API Web Crypto de este navegador): efímera × efímera para la forward secrecy, y después efímera × identidad en cada lado, lo que vincula las identidades de largo plazo a la sesión. HKDF-SHA256 sobre el transcript completo — las cuatro claves públicas — deriva la clave de sesión. Un relé que sustituya sus claves efímeras no posee ninguna de las dos identidades privadas y, por tanto, no puede calcular la clave; la autenticación depende de la verificación fuera de banda del fingerprint de identidad anunciado por la offer. La clave privada efímera se destruye tras la derivación. Mismo protocolo que la CLI de Python: una sesión derivada aquí y una sesión derivada con secu-box exchange llegan a la misma clave — verificado mediante derivación cruzada de las dos implementaciones. Solo la identidad en sí no es transportable de un lado a otro: la CLI protege la suya con Argon2id, ausente de Web Crypto, y la del navegador es no extraíble por construcción. Cada lado conserva, pues, la suya.

2. Mensaje / Descifrar — esteganografía geométrica Carter (véase más arriba), que utiliza la clave maestra derivada por la sesión Exchange activa, una passphrase o una clave introducida directamente.

3. Vault — cifrado local de archivos, AES-256-GCM por entrada, manifest cifrado, HMAC-SHA256 global (arquitectura inspirada en vault_lib.py).

4. Cifrado de archivos — SPN geométrica (Ref256+Ref360) como capa de diversificación de clave, AES-256-GCM como capa de cifrado autenticado (véase la pestaña Cifrado).

5. Referentes 256 y 360 — las tablas de formas geométricas (cruz ansada, Jacquard) que alimentan los componentes anteriores.

Nota sobre las sustituciones de cifrado: el componente Mensaje/Descifrar (2) utiliza XChaCha20-Poly1305 en JavaScript puro, idéntico a la referencia Python (stegano/carter.py, stegano/carter_random.py) y verificado frente a sus vectores — aquí ya no hay sustitución. El Vault (3) y el Cifrado de archivos (4) siguen con el AES-256-GCM nativo del navegador, ya que la API Web Crypto no expone XChaCha20-Poly1305 para estos dos componentes; misma clase de garantía (AEAD, 256 bits, estándar auditado). X25519 está implementado de forma nativa e idéntica en ambos lados.

Diferencia conocida — derivación de clave del Vault: desde su versión 1.2, vault_lib.py utiliza Argon2id (memory-hard, resistente a GPU/ASIC) en lugar de PBKDF2 para su derivación de clave interna. Los navegadores no disponen de forma nativa ni de Argon2id ni de scrypt — a diferencia de los casos anteriores, no existe un equivalente en Web Crypto que sustituir sin añadir una dependencia externa. Por tanto, el Vault de esta página sigue con PBKDF2 (300 000 iteraciones) y, en consecuencia, es menos resistente a la fuerza bruta por GPU/ASIC que su homólogo en Python. Para un uso sensible en producción, es preferible la CLI de Python (secu-box vault).

Advertencia general: SecuBox es un sistema experimental basado en construcciones geométricas originales. La capa criptográfica (AES-256-GCM, X25519, HKDF, PBKDF2) es estándar y está auditada. La capa geométrica (La Livrée d'Hermès) está en proceso de evaluación formal — véase la auditoría criptológica externa del 2026-09-10 mencionada en las pestañas Cifrado y Descifrar.