TL;DR
SealTask cifra el contenido legible del espacio en tu dispositivo con ChaCha20-Poly1305 antes de sincronizarlo. El servicio no conserva las claves necesarias para descifrar ese contenido, pero sigue procesando metadatos de cuenta, facturación, seguridad, auditoría, servicio y espacio de trabajo. Una clave de respaldo que guardes puede recuperar el acceso una vez tras perder la contraseña. Este diseño favorece la minimización de datos; un uso regulado sigue requiriendo los acuerdos y controles adecuados.
Un término de seguridad debe describir un límite, no adornar una afirmación.
El vocabulario utilizado en las páginas de seguridad, guías, comparativas e incidentes de SealTask. Los términos con una explicación completa enlazan a su página canónica.
Ver todo el centro de aprendizajeNuestro principio fundamental.
El contenido legible del espacio se cifra en tu dispositivo antes de llegar a nuestros servidores. SealTask está diseñado para que la empresa no pueda descifrar el texto legible de tareas, notas, comentarios, listas de control, títulos de listas ni adjuntos. El servicio sigue procesando los metadatos indicados a continuación. Este límite aplicado al contenido se denomina de conocimiento cero.
Lo que hace a SealTask diferente.
Gestores de tareas tradicionales.
Lo que hace la competencia
- • Almacenan tus datos en texto plano en sus servidores
- • Pueden leer cada tarea, comentario y archivo que creas
- • Pueden analizar tu contenido para publicidad, entrenamiento de IA o «funcionalidades»
- • Una brecha o una vía de acceso autorizada puede exponer contenido legible y metadatos
SealTask (conocimiento cero).
Lo que hacemos nosotros
- • Cifra en tu dispositivo antes de enviar a nuestros servidores
- • No podemos descifrar tus tareas, aunque quisiéramos
- • Sin escaneo ni entrenamiento de IA con tu trabajo privado
- • Una brecha de la base puede exponer texto cifrado y metadatos, pero no contenido legible sin las claves que conserva el cliente
Cómo funciona el cifrado de conocimiento cero.
Creas tu cuenta.
Al registrarte, tu contraseña nunca sale del navegador en texto plano. En su lugar:
- Usamos el protocolo OPAQUE PAKE para que nuestros servidores nunca vean tu contraseña en texto plano
- Después de registrarte o iniciar sesión correctamente, OPAQUE entrega al navegador una clave de exportación secreta que nunca recibimos
- Se genera en tu dispositivo una «clave de datos» aleatoria de 32 bytes
- Esa clave de datos se cifra localmente con una clave de envoltura derivada de esa clave de exportación OPAQUE
- La clave de datos cifrada se guarda en nuestros servidores, pero no podemos descifrarla sin el material de desbloqueo del cliente
- Puedes descargar una clave de respaldo de un solo uso. Envuelve la misma clave de datos en tu navegador, y nosotros solo guardamos una envoltura de recuperación cifrada
Punto clave: la clave de desbloqueo y la clave de datos se manejan en tu navegador. Solo almacenamos envolturas cifradas, nunca contraseñas en texto plano ni claves del workspace.
¿Por qué guardar la clave de datos cifrada?
Para que puedas iniciar sesión desde cualquier dispositivo. Cuando cambias de ordenador o usas el móvil, enviamos el blob cifrado, tu navegador lo desbloquea localmente tras el inicio de sesión seguro y listo. Sin guardarlo, tendrías que copiar manualmente una clave de 32 bytes entre dispositivos — UX terrible para la misma seguridad.
Creas una lista de trabajo o una tarea.
El contenido legible del espacio se cifra en tu dispositivo; los metadatos operativos siguen visibles para el servidor:
- Títulos y descripciones de las listas de trabajo
- Títulos, contenidos, checklists y comentarios de las tareas
- El contenido de la plantilla de una tarea recurrente está cifrado; la programación cron, la zona horaria, el estado activo, la iteración y las marcas de tiempo de materialización siguen visibles para el servidor
- Todo se cifra con ChaCha20-Poly1305 AEAD (un cifrado moderno y auditado)
- Cada lista de trabajo tiene su propia clave de cifrado derivada de tu clave de datos
El servidor almacena cargas cifradas del espacio y los metadatos operativos declarados; sin las claves que conserva el cliente, no puede leer el texto legible cifrado.
Invitas a tus compañeros.
Al compartir listas de trabajo con tu equipo:
- Cada miembro recibe su propia copia cifrada de la clave de la lista
- Las claves se intercambian con HPKE (cifrado híbrido de clave pública)
- Las claves públicas de invitación se registran en un log de transparencia Merkle. Un cliente que conserve un punto de control previamente confiable puede detectar una discrepancia al verificarla, pero el cliente actual no falla de forma cerrada ni conserva esa detección: puede descartar el punto de control y reintentar desde el origen
- Retirar a un colaborador revoca su acceso a la lista autorizado por el servidor. El servidor que confirma el cambio avisa a sus flujos activos después del commit; los cambios de otro servidor, masivos o no señalados se vuelven a comprobar en un máximo de 30 segundos. Los datos ya entregados o almacenados en el búfer de transporte no pueden retirarse. La versión actual no rota automáticamente la clave de la lista, no vuelve a cifrarla ni borra contenido o claves obtenidos durante el acceso autorizado. Para establecer un límite criptográfico nuevo, crea una lista nueva solo para los miembros actuales.
El servidor comprueba la coherencia HMAC sin descifrar la carga.
El estado de sesión y pertenencia activa en la base autoriza el acceso. Por separado, el navegador deriva de la clave de lista, mediante HKDF y una constante fija del protocolo, una clave de vinculación de carga propia de la lista; esa misma clave se copia para cada pertenencia y se almacena en el servidor.
El servidor usa esa clave para verificar un HMAC sobre el texto cifrado. La prueba solo demuestra que el HMAC coincide con los bytes de ese texto cifrado, sin descifrarlos.
- Tu navegador deriva la clave de vinculación propia de la lista a partir de la clave de lista mediante HKDF; no es una clave de descifrado del contenido
- El servidor comprueba la sesión autenticada y la pertenencia activa antes de autorizar la solicitud
- El servidor almacena la clave de vinculación copiada y puede verificar o calcular HMAC coincidentes sobre el texto cifrado
- El HMAC no demuestra actualidad, no evita la reproducción, no vincula una entidad o un miembro ni autentica la carga frente al servidor
Lo que nuestros servidores pueden (y no pueden) ver.
NO podemos ver
- × Títulos de tareas legibles
- × Cuerpos de tareas y notas legibles
- × Contenido legible de plantillas de tareas recurrentes
- × Cuerpos de comentarios legibles
- × Contenido legible de listas de control
- × Títulos y descripciones de listas legibles
- × Contenido en claro de adjuntos
- × Contraseñas de cuenta en claro
- × Claves de descifrado del contenido del espacio
Ejemplos no exhaustivos de metadatos visibles del espacio de trabajo
- ✓ Correo de la cuenta (para iniciar sesión)
- ✓ Relaciones de membresía (quién está en cada lista)
- ✓ Estado de la tarea (abierta/cerrada) y prioridad
- ✓ Fechas de vencimiento y marcas temporales
- ✓ Asignaciones de delegación (solo IDs de usuario)
- ✓ Metadatos necesarios para las consultas (IDs, fechas de creación)
- ✓ Sales y pruebas por pertenencia, más la clave de vinculación de carga propia de la lista que almacena el servidor para verificar o calcular HMAC coincidentes; no es una clave de descifrado del contenido
- ✓ Programación de recurrencias, zona horaria, estado activo, iteración y tiempos de materialización
- ✓ Relaciones de archivos adjuntos, identificadores de almacenamiento, tamaño del texto cifrado, estado y marcas temporales
- ✓ Tipos de eventos en tiempo real, identificadores de actores y entidades, nombres de campos modificados, marcas temporales y recuentos de eventos perdidos
Alcance y sensibilidad: La lista mostrada ofrece ejemplos no exhaustivos de metadatos del espacio visibles para el servidor; no es un inventario completo de los modelos de persistencia, las respuestas de API ni los eventos SSE actuales. Tampoco es un inventario completo de datos personales: la autenticación de cuentas, facturación, seguridad y auditoría, prevención de abusos y telemetría del servicio son ámbitos separados descritos de forma no exhaustiva en la política de privacidad. Los metadatos pueden ser sensibles. El tamaño del texto cifrado de un adjunto suele aproximar el tamaño del archivo original.
Garantías de seguridad.
Desbloqueo autenticado por contraseña (solo en el cliente).
Tu contraseña nunca sale del dispositivo en texto plano. Una autenticación OPAQUE correcta entrega al navegador una clave de exportación que desenvuelve localmente tu clave de datos. Esa clave de datos se expande luego con HKDF para derivar claves separadas para cada lista de trabajo.
El servidor no puede descifrar contenidos.
El backend no descifra las cargas cifradas del espacio. Las comprobaciones de sesión y pertenencia en la base autorizan las solicitudes. Con la clave de vinculación propia de la lista que almacena, el servidor puede verificar o calcular un HMAC coincidente con el texto cifrado; eso demuestra coherencia del texto cifrado, no actualidad, protección contra reproducción, vinculación a una entidad o miembro ni autenticidad frente al servidor.
La retirada de acceso es limitada y no retroactiva.
Retirar a un colaborador revoca su acceso a la lista autorizado por el servidor. El servidor que confirma el cambio avisa a sus flujos activos después del commit; los cambios de otro servidor, masivos o no señalados se vuelven a comprobar en un máximo de 30 segundos. Los datos ya entregados o almacenados en el búfer de transporte no pueden retirarse. La versión actual no rota automáticamente la clave de la lista, no vuelve a cifrarla ni borra contenido o claves obtenidos durante el acceso autorizado. Para establecer un límite criptográfico nuevo, crea una lista nueva solo para los miembros actuales.
Transparencia de claves de invitación.
Las claves públicas de invitación se registran en un árbol Merkle de solo anexado. Un punto de control previamente confiable puede hacer aflorar una discrepancia durante la verificación, pero el cliente actual puede borrarlo y reintentar desde el origen; ese reintento y el primer uso siguen siendo límites de confianza, no una prevención incondicional.
Las claves de respaldo siguen siendo de conocimiento cero.
La clave de respaldo se genera en tu navegador y debes guardarla tú. Crea una envoltura cifrada separada para la misma clave de datos; nosotros solo almacenamos el archivo de credenciales de recuperación y la envoltura cifrada, así que no podemos restablecer tu contraseña ni leer tus datos sin esa clave guardada.
Criptografía de código abierto.
Usamos bibliotecas probadas: strong-box (ChaCha20-Poly1305), OPAQUE (autenticación por contraseña), HKDF (derivación de claves), Argon2id (endurecimiento de contraseñas de OPAQUE y migración heredada) y HPKE (intercambio de claves). Todo nuestro código criptográfico es de código abierto y auditable.
Cómo verificamos nuestra seguridad.
Nuestras afirmaciones de seguridad son verificables, no solo marketing. Así garantizamos que nuestra arquitectura de conocimiento cero funciona como prometemos:
- Código criptográfico de código abierto en GitHub para que cualquier investigador de seguridad pueda auditarlo
- Bibliotecas probadas como ChaCha20-Poly1305 (RFC 8439), Argon2id, OPAQUE PAKE (RFC 9807) y HPKE
- La clave de vinculación propia de la lista que almacena el servidor le permite verificar o calcular un HMAC coincidente con el texto cifrado; la sesión y la pertenencia en la base autorizan el acceso, mientras que el HMAC no demuestra actualidad, protección contra reproducción, vinculación a una entidad o miembro ni autenticidad frente al servidor
- Las pruebas Merkle pueden mostrar una discrepancia respecto de un punto de control confiable, pero el cliente actual puede descartarlo y reintentar desde el origen
- El desbloqueo en el cliente desde claves de exportación OPAQUE garantiza que nunca veamos tu contraseña ni tus claves de cifrado
- Las claves de respaldo de un solo uso las genera y conserva el usuario, nunca SealTask
Compromisos del conocimiento cero.
Una clave de respaldo puede restaurar el acceso si pierdes la contraseña.
Guarda una clave de respaldo una vez y mantenla privada. Si pierdes la contraseña, esa clave te permite restablecerla y conservar el acceso a los datos cifrados. Como SealTask no guarda una copia, las cuentas sin una clave de respaldo guardada no se pueden recuperar.
No hay búsqueda en el servidor.
Como el contenido de tus tareas está cifrado, no podemos ofrecer búsqueda completa en el servidor sobre todas tus tareas. La búsqueda ocurre en tu navegador tras el descifrado.
Mitigación: optimizamos la búsqueda en el cliente con búsquedas indexadas y descifrado rápido para mantenerla ágil.
Especificaciones técnicas.
| Cifrado simétrico | ChaCha20-Poly1305 AEAD (mediante la biblioteca strong-box) |
| Desbloqueo de clave de datos | Clave de exportación OPAQUE + HKDF-SHA256 — deriva claves de envoltura locales para la clave de datos cifrada |
| Jerarquía de claves | HKDF-SHA256 — deriva claves de listas y membresías a partir de la clave de datos |
| Autenticación por contraseña | OPAQUE PAKE (curva Ristretto255) |
| Autenticación de dos factores | TOTP de aplicación de autenticación (RFC 6238) con códigos de respaldo de un solo uso; opcional por cuenta |
| Claves de respaldo | Una clave de respaldo activa de un solo uso por usuario; generada en el cliente y guardada por el usuario |
| Intercambio de claves (invitaciones) | HPKE (cifrado híbrido de clave pública) con X25519 |
| Comprobaciones de coherencia de carga | HMAC-SHA256 |
| Serialización | CBOR (Concise Binary Object Representation) |
| Tamaño de clave | 256 bits (32 bytes) para todas las claves simétricas |
Todas las operaciones criptográficas suceden en tu navegador con las API WebCrypto y módulos WASM auditados compilados desde Rust.
Auditorías y transparencia.
Stack criptográfico de código abierto.
Toda nuestra implementación criptográfica es de código abierto y está disponible en GitHub. Invitamos a los investigadores de seguridad a auditar nuestro código.
Ver en GitHubCumplimiento.
Nuestra arquitectura de conocimiento cero respalda la minimización de datos del RGPD y puede ayudar con salvaguardas técnicas. SealTask debe aceptar expresamente por escrito antes de cualquier uso de PHI. Cuando se aplique HIPAA, las partes deben suscribir un BAA conforme con HIPAA antes del uso. El cifrado es solo una salvaguarda; tu programa de cumplimiento debe aportar los controles operativos y la evaluación del proveedor necesarios.
Preguntas frecuentes.
¿Qué pasa si os hackean?
Un atacante con acceso a la base podría obtener texto cifrado y metadatos de cuenta, enrutamiento, auditoría y espacio de trabajo. El contenido almacenado no es legible sin las claves de descifrado que conserva el cliente, sujeto a la seguridad de la criptografía, los clientes y la gestión de claves.
¿Pueden las autoridades obligaros a descifrar mis datos?
Una solicitud legal puede exigirnos texto cifrado y metadatos visibles de cuenta, facturación, seguridad, auditoría, servicio y espacio de trabajo. No conservamos las claves necesarias para descifrar el contenido legible del espacio.
¿Qué pasa si olvido mi contraseña?
Si guardaste una clave de respaldo, puedes usarla una sola vez para restablecer la contraseña y mantener el acceso a tus datos cifrados. Si no guardaste una clave de respaldo, SealTask no puede restaurar los datos por ti.
¿En qué se diferencia del «cifrado en reposo»?
El «cifrado en reposo» significa que los datos están cifrados en los discos del servidor, pero el servidor sigue teniendo las claves para descifrarlos. El cifrado de extremo a extremo significa que solo tú (los extremos) tienes las claves — el servidor nunca tiene acceso al texto plano.
¿Pueden los empleados de SealTask ver mis datos?
El personal de SealTask y los administradores de la base no tienen las claves del cliente necesarias para descifrar las cargas del espacio. Los sistemas y las personas autorizadas sí pueden acceder a los metadatos visibles descritos en esta página.
¿Y si quiero exportar mis datos?
Puedes exportar tus datos descifrados en cualquier momento desde la app. Como el descifrado ocurre en tu navegador, obtendrás archivos JSON/CSV legibles — no bloques cifrados.
¿SealTask admite la autenticación de dos factores?
Sí. Puedes activar en los ajustes de seguridad la autenticación de dos factores con una aplicación de autenticación (RFC 6238 TOTP) y guardar códigos de respaldo de un solo uso. Iniciar sesión requiere entonces tu contraseña y un código vigente. Esto protege el acceso a la cuenta y es independiente del cifrado en el cliente que protege el contenido del espacio de trabajo.
Referencias y estándares.
Nuestras decisiones criptográficas siguen estándares de la industria y especificaciones revisadas por pares.
- 01 RFC 8439: ChaCha20 and Poly1305 for IETF Protocols — Nuestro estándar de cifrado simétrico
- 02 RFC 9807: The OPAQUE Augmented PAKE Protocol — Autenticación por contraseña de conocimiento cero
- 03 RFC 9180: Hybrid Public Key Encryption (HPKE) — Intercambio de claves para invitaciones de equipo
- 04 RFC 9106: Argon2 Memory-Hard Function — Derivación de claves basada en contraseña
- 05 NIST SP 800-175B: Guideline for Using Cryptographic Standards — Guía criptográfica federal
- 06 GDPR Article 32: Security of Processing — Requisitos europeos de protección de datos
- 07 RFC 6238 — TOTP — Autenticación de dos factores
¿Lista para una privacidad real?
Únete a los equipos que confían en SealTask para mantener su trabajo realmente privado. Empieza en Free — sin tarjeta de crédito.
Empezar gratis¿Preguntas de seguridad? Escríbenos a security@sealtask.com