PRÓXIMAMENTE

LA SEGURIDAD NO ES UNA FUNCIÓN. ES LA BASE.

Arquitectura de seguridadVORQYN por dentro.

Desde la contraseña maestra y la jerarquía de claves hasta commits autenticados, recuperación tras fallos y sincronización cifrada de extremo a extremo.

Argon2idHKDF-SHA-256XChaCha20-Poly1305Rust CoreAuthenticated Commits
Contenido ⌄
Diagramas interactivosReferencia técnica

01 / VISUAL SECURITY LAB

Explorar la arquitectura

Explora la derivación de claves, los registros cifrados, las escrituras, la sincronización y sus límites de seguridad mediante diagramas interactivos.

01

INTERACTIVE · SECURITY ENGINEERING

Arquitectura de seguridad

Flutter gestiona la interfaz; el núcleo Rust aplica las reglas criptográficas y valida formatos y estados. El sistema de archivos y los proveedores están separados.
Explicación sencilla

Flutter gestiona la interfaz; el núcleo Rust aplica las reglas criptográficas y valida formatos y estados. El sistema de archivos y los proveedores están separados.

Límite de seguridad

Un cliente comprometido puede exponer datos descifrados durante su uso.

Detalles técnicos

Flutter gestiona la interfaz; el núcleo Rust aplica las reglas criptográficas y valida formatos y estados. El sistema de archivos y los proveedores están separados.

Un cliente comprometido puede exponer datos descifrados durante su uso.

Leer capítulo ↗
02

INTERACTIVE · SECURITY ENGINEERING

Contraseña + Secret Factor

Contraseña maestra
Argon2id v1.3
Secret Factor (256 bits)
CSPRNG → 32 bytes
↓
HKDF-SHA-256
Clave de desbloqueo → sobre → LPRK
Solo se roba el cifrado. Falta el Secret Factor; la contraseña por sí sola no basta.
Explicación sencilla

El Secret Factor es aleatorio e independiente, con 256 bits. Ayuda frente al robo aislado de la bóveda, pero un malware con acceso al mismo usuario podría obtener también el factor.

Límite de seguridad

Un Factor local no equivale automáticamente a MFA independiente.

Detalles técnicos

El Secret Factor es aleatorio e independiente, con 256 bits. Ayuda frente al robo aislado de la bóveda, pero un malware con acceso al mismo usuario podría obtener también el factor.

Un Factor local no equivale automáticamente a MFA independiente.

Leer capítulo ↗
03

INTERACTIVE · SECURITY ENGINEERING

Jerarquía de claves

Contraseña maestra + Secret Factor (256 bits)
Clave de desbloqueo → sobre → LPRK
LPRK
Vault Epoch Key
DEK por registro
Collection Keys
La clave de desbloqueo abre un sobre cifrado que guarda la clave raíz local LPRK, generada de forma independiente. Vault Epoch, DEK por revisión y Collection Keys separan los permisos.
Explicación sencilla

La clave de desbloqueo abre un sobre cifrado que guarda la clave raíz local LPRK, generada de forma independiente. Vault Epoch, DEK por revisión y Collection Keys separan los permisos.

Límite de seguridad

Sin material de recuperación, la pérdida de claves puede ser definitiva.

Detalles técnicos

La clave de desbloqueo abre un sobre cifrado que guarda la clave raíz local LPRK, generada de forma independiente. Vault Epoch, DEK por revisión y Collection Keys separan los permisos.

Sin material de recuperación, la pérdida de claves puede ser definitiva.

Leer capítulo ↗
04

INTERACTIVE · SECURITY ENGINEERING

Cifrado por registro

Login ADEK A1Revision 1
Login BDEK B1Revision 1
Login CDEK C1Revision 1
Login DDEK D1Revision 1
Los demás registros no cambian
Explicación sencilla

Cada cambio crea una revisión inmutable con un nuevo DEK aleatorio de 256 bits y metadatos autenticados. No se sobrescribe el registro anterior.

Límite de seguridad

Las revisiones antiguas pueden conservarse según la política de retención.

Detalles técnicos

Cada cambio crea una revisión inmutable con un nuevo DEK aleatorio de 256 bits y metadatos autenticados. No se sobrescribe el registro anterior.

Las revisiones antiguas pueden conservarse según la política de retención.

Leer capítulo ↗
05

INTERACTIVE · SECURITY ENGINEERING

Escritura atómica y recuperación

VALIDATEDEKENCRYPTWRITE TEMPFLUSHPUBLISH RECORDPUBLISH COMMITUPDATE HEAD
El commit anterior sigue siendo válido. Un objeto temporal incompleto no es un estado confirmado.
Explicación sencilla

La escritura valida, genera DEK y revisión, cifra, escribe temporalmente, sincroniza, publica objetos, publica el commit y actualiza el head.

Límite de seguridad

Objetos ausentes y fallos físicos pueden impedir la recuperación.

Detalles técnicos

La escritura valida, genera DEK y revisión, cifra, escribe temporalmente, sincroniza, publica objetos, publica el commit y actualiza el head.

Objetos ausentes y fallos físicos pueden impedir la recuperación.

Leer capítulo ↗
06

INTERACTIVE · SECURITY ENGINEERING

Monolito o almacenamiento de objetos

Monolito ingenuo (esquema)
100 GB VAULT
Δ RECORD
Almacén de objetos
BLOBRECRECBLOBRECRECBLOBRECRECBLOBRECREC
Δ RECORD + INDEX + COMMIT
En una bóveda de 100 GB, cambiar una contraseña debería añadir objetos concretos sin recifrar todo. Las transferencias reales dependen del índice y del proveedor.
Explicación sencilla

En una bóveda de 100 GB, cambiar una contraseña debería añadir objetos concretos sin recifrar todo. Las transferencias reales dependen del índice y del proveedor.

Límite de seguridad

Otras arquitecturas también pueden usar sincronización delta eficiente.

Detalles técnicos

En una bóveda de 100 GB, cambiar una contraseña debería añadir objetos concretos sin recifrar todo. Las transferencias reales dependen del índice y del proveedor.

Otras arquitecturas también pueden usar sincronización delta eficiente.

Leer capítulo ↗
07

INTERACTIVE · SECURITY ENGINEERING

Grafo de commits autenticados

Commit A
Commit B
Commit C · Device 1
Commit D · Device 2
Merge E
Un proveedor malicioso puede ocultar commits auténticos.
Explicación sencilla

Los commits autenticados enlazan padres y objetos activos. Varios dispositivos pueden generar ramas válidas; el reloj no basta para decidir cuál gana.

Límite de seguridad

Un proveedor malicioso puede ocultar commits auténticos.

Detalles técnicos

Los commits autenticados enlazan padres y objetos activos. Varios dispositivos pueden generar ramas válidas; el reloj no basta para decidir cuál gana.

Un proveedor malicioso puede ocultar commits auténticos.

Leer capítulo ↗
08

INTERACTIVE · SECURITY ENGINEERING

Sincronización de extremo a extremo

Dispositivo A
⇆AEAD · CIPHERTEXT
Proveedor
⇆AEAD · CIPHERTEXT
Dispositivo B
Cambios locales sin red, sincronización posterior.
Explicación sencilla

Los clientes cifran localmente y solo comparten objetos cifrados. Los datos se publican antes del commit; las modificaciones sin conexión pueden generar ramas.

Límite de seguridad

El proveedor puede eliminar, retrasar o repetir objetos cifrados.

Detalles técnicos

Los clientes cifran localmente y solo comparten objetos cifrados. Los datos se publican antes del commit; las modificaciones sin conexión pueden generar ramas.

El proveedor puede eliminar, retrasar o repetir objetos cifrados.

Leer capítulo ↗
09

INTERACTIVE · SECURITY ENGINEERING

Integridad ≠ actualidad

Commit C1Auténtico pero antiguoAEAD ✓
←
Commit C2Commit reciente confirmadoAEAD ✓
AEAD confirma autenticidad, pero no actualidad.
Explicación sencilla

AEAD confirma autenticidad, no actualidad. Para detectar un rollback completo hace falta una referencia independiente y confiable de un estado reciente.

Límite de seguridad

Un rollback completo requiere un anclaje de actualidad independiente.

Detalles técnicos

AEAD confirma autenticidad, no actualidad. Para detectar un rollback completo hace falta una referencia independiente y confiable de un estado reciente.

Un rollback completo requiere un anclaje de actualidad independiente.

Leer capítulo ↗
10

INTERACTIVE · SECURITY ENGINEERING

Permisos Business & Enterprise

ROLE
PRIVATE
FINANCE
DEVELOPMENT
Owner
✓
✓
✓
Finance User
—
✓
—
Developer
—
—
✓
Las claves, no solo los roles de servidor, controlan el acceso
Explicación sencilla

Los roles Owner, Admin, Editor y Viewer no sustituyen los permisos reales de las claves. Cada Collection tiene su ámbito; no puede retirarse un texto ya conocido.

Límite de seguridad

No se puede revocar retroactivamente el texto claro ya conocido.

Detalles técnicos

Los roles Owner, Admin, Editor y Viewer no sustituyen los permisos reales de las claves. Cada Collection tiene su ámbito; no puede retirarse un texto ya conocido.

No se puede revocar retroactivamente el texto claro ya conocido.

Leer capítulo ↗
11

INTERACTIVE · SECURITY ENGINEERING

Modelo de amenazas

Elegir escenario

Bóveda cifrada robada

Detalles técnicos

Argon2id, AEAD y Factor separado

Límite de seguridad

Custodia del Factor y calidad de contraseña

Explicación sencilla

El modelo incluye robo, manipulación, cortes de energía, disco lleno, cloud comprometida, rollback y malware local. Cada medida tiene límites conocidos.

Límite de seguridad

Ninguna medida mitiga todos los escenarios de ataque.

Detalles técnicos

El modelo incluye robo, manipulación, cortes de energía, disco lleno, cloud comprometida, rollback y malware local. Cada medida tiene límites conocidos.

Ninguna medida mitiga todos los escenarios de ataque.

Leer capítulo ↗
12

INTERACTIVE · SECURITY ENGINEERING

Auditoría y pruebas

01   Architecture02   Implementation03   Automated tests04   Platform validation05   Independent audit
La arquitectura fija el modelo de amenazas y reglas de seguridad comprobables.
Explicación sencilla

Una auditoría requiere contratos verificables sobre KDF, AAD, nonce, formatos, commits, errores, persistencia, firmas y binarios publicados.

Límite de seguridad

La verificación relaciona protocolos, código, pruebas reproducibles y validación por plataforma.

Detalles técnicos

Una auditoría requiere contratos verificables sobre KDF, AAD, nonce, formatos, commits, errores, persistencia, firmas y binarios publicados.

La verificación relaciona protocolos, código, pruebas reproducibles y validación por plataforma.

Leer capítulo ↗

02 / TECHNICAL REFERENCE · V1.2

Referencia técnica

La referencia técnica detalla mecanismos criptográficos, formatos, amenazas, fallos y decisiones de diseño. Esta edición ofrece resúmenes técnicos y enlaces a la referencia alemana completa.

01La seguridad es la base+

La seguridad cubre todo el ciclo de vida: creación, uso, cambios, sincronización, recuperación y borrado. Los fallos del sistema forman parte del modelo de amenazas.

Especificación completa (alemán) ↗

02Seis principios de seguridad+

Confidencialidad, integridad, coherencia, recuperación, disponibilidad y soberanía son objetivos diferentes. Un estado auténtico puede estar desactualizado.

Especificación completa (alemán) ↗

03Arquitectura del sistema+

Flutter gestiona la interfaz; el núcleo Rust aplica las reglas criptográficas y valida formatos y estados. El sistema de archivos y los proveedores están separados.

Especificación completa (alemán) ↗

04Primitivas criptográficas+

Argon2id v1.3 (128 MiB, 3 iteraciones, 4 vías, salida de 256 bits), HKDF-SHA-256 y XChaCha20-Poly1305 (clave 256, nonce 192 y etiqueta 128 bits) cumplen funciones distintas.

Argon2id v1.3 · 128 MiB / 3 / 4 · HKDF-SHA-256 · XChaCha20-Poly1305

Especificación completa (alemán) ↗

05Contraseña maestra y Secret Factor+

El Secret Factor es aleatorio e independiente, con 256 bits. Ayuda frente al robo aislado de la bóveda, pero un malware con acceso al mismo usuario podría obtener también el factor.

VQYFACT1 · 32-byte CSPRNG secret · HKDF-SHA-256

Especificación completa (alemán) ↗

06Jerarquía de claves+

La clave de desbloqueo abre un sobre cifrado que guarda la clave raíz local LPRK, generada de forma independiente. Vault Epoch, DEK por revisión y Collection Keys separan los permisos.

Unlock → Envelope → LPRK → VEK → DEK

Especificación completa (alemán) ↗

07Datos asociados autenticados+

Los datos asociados autenticados (AAD) vinculan el texto cifrado a bóveda, objeto, revisión, versión y tipo. Evitan determinadas sustituciones; AAD no es necesariamente secreto.

AAD: vault_id | object_id | revision_id | epoch | version

Especificación completa (alemán) ↗

08Una bóveda lógica, muchos objetos cifrados+

La bóveda lógica contiene registros cifrados, blobs, commits y punteros head. El head ayuda a localizar el estado, pero no es la única autoridad criptográfica.

meta/ · commits/ · records/ · blobs/ · heads/

Especificación completa (alemán) ↗

09Registros inmutables y revisiones+

Cada cambio crea una revisión inmutable con un nuevo DEK aleatorio de 256 bits y metadatos autenticados. No se sobrescribe el registro anterior.

Especificación completa (alemán) ↗

10Grafo de commits autenticados+

Los commits autenticados enlazan padres y objetos activos. Varios dispositivos pueden generar ramas válidas; el reloj no basta para decidir cuál gana.

commit ID · vault ID · parent IDs · record refs

Especificación completa (alemán) ↗

11Transacción completa de escritura+

La escritura valida, genera DEK y revisión, cifra, escribe temporalmente, sincroniza, publica objetos, publica el commit y actualiza el head.

VALIDATE → ENCRYPT → WRITE → FLUSH → PUBLISH RECORD → PUBLISH COMMIT → HEAD

Especificación completa (alemán) ↗

12Corte de energía y recuperación+

Tras un fallo se comprueban commits y referencias. Un único estado válido puede reconstruirse; las ramas ambiguas exigen tratamiento explícito.

Especificación completa (alemán) ↗

13Disco lleno+

El disco puede llenarse después de una comprobación inicial. Cada escritura y flush debe validarse; un objeto incompleto no puede confirmarse con un commit.

Especificación completa (alemán) ↗

14Seguridad del sistema de archivos+

NTFS, Linux, macOS y sistemas móviles tienen distintas garantías. Enlaces simbólicos, carreras TOCTOU y hardware defectuoso requieren controles específicos.

Especificación completa (alemán) ↗

15Adjuntos y fragmentos cifrados+

Los adjuntos se dividen en fragmentos cifrados, por ejemplo hasta 4 MiB cada uno. Se autentican orden, longitud y contexto; la identidad se basa en hashes del ciphertext.

4 MiB chunk profile · SHA-256(ciphertext)

Especificación completa (alemán) ↗

16La bóveda de 100 GB+

En una bóveda de 100 GB, cambiar una contraseña debería añadir objetos concretos sin recifrar todo. Las transferencias reales dependen del índice y del proveedor.

Especificación completa (alemán) ↗

17Manifiestos, índices y escalabilidad+

Índices jerárquicos y manifiestos autenticados permiten actualizar referencias concretas. La cadena de integridad debe mantenerse desde la raíz hasta cada objeto.

Especificación completa (alemán) ↗

18Sincronización cifrada de extremo a extremo+

Los clientes cifran localmente y solo comparten objetos cifrados. Los datos se publican antes del commit; las modificaciones sin conexión pueden generar ramas.

Especificación completa (alemán) ↗

19SFTP, WebDAV y almacenamiento de objetos+

SFTP, WebDAV/HTTPS y almacenamiento tipo S3 tienen garantías diferentes para escritura condicional, renombrado y listados completos. No deben suponerse capacidades inexistentes.

SFTP · WebDAV/HTTPS · S3-like

Especificación completa (alemán) ↗

20Conflictos entre dispositivos+

Dos dispositivos pueden editar la misma entrada desde un ancestro común. Ambas ramas se conservan para resolver el conflicto, sin usar solo la última hora.

Especificación completa (alemán) ↗

21Protección contra rollback+

AEAD confirma autenticidad, no actualidad. Para detectar un rollback completo hace falta una referencia independiente y confiable de un estado reciente.

Especificación completa (alemán) ↗

22Permisos Business y Enterprise+

Los roles Owner, Admin, Editor y Viewer no sustituyen los permisos reales de las claves. Cada Collection tiene su ámbito; no puede retirarse un texto ya conocido.

Owner · Admin · Editor · Viewer

Especificación completa (alemán) ↗

23Rotación de claves+

Cambiar la contraseña maestra puede bastar con actualizar sobres de claves. Una clave de datos comprometida puede exigir recifrar los datos afectados.

Especificación completa (alemán) ↗

24Copias de seguridad y recuperación+

Una copia recuperable incluye metadatos, claves envueltas, commits, registros, fragmentos y material de recuperación. La restauración verifica todo el conjunto.

Especificación completa (alemán) ↗

25Eliminación y tombstones+

Los tombstones representan los borrados. Las versiones previas pueden persistir en backups; no se garantiza borrado físico en todos los SSD y servicios.

Especificación completa (alemán) ↗

26Claves privadas y reautenticación+

Exportar claves privadas SSH exige reautenticación en el núcleo Rust; un diálogo visual no sustituye ese control. Los fallos bloquean la operación.

Especificación completa (alemán) ↗

27Protección en ejecución+

Bloquear la sesión descarta secretos controlados, pero Dart, portapapeles, swap y volcados de memoria pueden conservar copias. No hay garantía ante un dispositivo comprometido.

Especificación completa (alemán) ↗

28Privacidad y conocimiento cero+

El proveedor no necesita las claves de la bóveda, pero tamaños, número de objetos, tiempos, IP y metadatos de transporte siguen siendo observables.

Especificación completa (alemán) ↗

29Cadena de suministro de software+

Las dependencias directas e indirectas, funciones habilitadas, avisos de seguridad, configuraciones y binarios reales forman parte del análisis.

Especificación completa (alemán) ↗

30Modelo de amenazas+

El modelo incluye robo, manipulación, cortes de energía, disco lleno, cloud comprometida, rollback y malware local. Cada medida tiene límites conocidos.

Especificación completa (alemán) ↗

31Auditorías y verificabilidad+

Una auditoría requiere contratos verificables sobre KDF, AAD, nonce, formatos, commits, errores, persistencia, firmas y binarios publicados.

Architecture → Implementation → Tests → Platform → Independent review

Especificación completa (alemán) ↗

32Límites explícitos+

No se promete seguridad total en dispositivos infectados, recuperación sin claves, borrado físico universal ni reconocimiento de rollback sin anclaje externo.

Especificación completa (alemán) ↗

33Preguntas frecuentes+

Las preguntas frecuentes diferencian robo del cifrado, factor secreto, uso sin conexión, sincronización y antigüedad de datos.

Especificación completa (alemán) ↗

34Seguridad por arquitectura+

Argon2id, Secret Factor, HKDF, AEAD, DEK por registro, AAD, objetos inmutables y commits autenticados forman defensas complementarias.

Especificación completa (alemán) ↗

Ingeniería de seguridad

La seguridad es una decisión arquitectónica.

Criptografía transparente, fronteras de confianza explícitas y flujos verificables definen VORQYN, desde la contraseña maestra hasta los commits autenticados.

Volver al inicio ↗