Cómo funciona el cifrado de las solicitudes

Los archivos se cifran con tus claves antes de salir del dispositivo de tu cliente. Esto es exactamente lo que ocurre, lo que el servidor puede y no puede ver, y dónde están los límites.

Qué se cifra, y para quién

Cuando creas tu primera solicitud, tu navegador deriva una identidad de larga duración —un híbrido de ML-KEM-1024 y X25519, combinados con HKDF-SHA-256— a partir de tu cuenta desbloqueada. La mitad pública viaja con el enlace de la solicitud; la privada se envuelve con la clave de tu cuenta y se guarda para que solo tú puedas recuperarla.

Cuando un cliente sube un archivo, su navegador lo cifra para esa identidad pública con el núcleo de código abierto @shieldfive/crypto. Los archivos grandes se cifran con una clave de contenido efímera que a su vez se cifra para tu identidad, así que las subidas grandes siguen troceadas y solo tú puedes abrirlas. A ShieldFive solo llega texto cifrado. La mitad post-cuántica (ML-KEM) está siempre activa: no es un extra de pago.

Qué puede ver el servidor

Somos claros sobre los límites de cualquier herramienta alojada que se entrega por navegador. El servidor ve: el tamaño de cada texto cifrado; cuándo se creó la solicitud, cuándo se abrió y cuándo se subió algo; y la dirección IP que conectó (con hash para prevenir abusos, nunca en claro). También guarda un verificador del PIN de la solicitud —nunca el PIN— y los metadatos cifrados (título, etiquetas de la lista, nombres de archivo), que no puede leer. Y entrega el JavaScript que ejecuta el cifrado.

Lo que el servidor no puede ver: el contenido de los archivos, sus nombres, el texto de tu lista ni tus claves privadas. Eso se queda en el dispositivo de tu cliente y en el tuyo.

El techo de entregar JavaScript

Como el código de cifrado —y la clave pública para la que cifran tus clientes— los servimos nosotros en cada carga de la página, un compromiso de ShieldFive podría, en principio, servir código malicioso o una clave sustituida. Reducimos ese riesgo con una Content-Security-Policy estricta y sin scripts de terceros en las páginas de subida y de bandeja, y el núcleo criptográfico es de código abierto para que cualquiera pueda revisarlo. Este es el techo honesto de cualquier herramienta de extremo a extremo entregada por web. Lo que afirmamos es «cifrado en el navegador y texto cifrado en reposo», no que ningún servidor pueda verse comprometido jamás. Para los casos de máxima garantía, verifica la huella de la clave por otro canal.

Controles de abuso en el enlace de subida

Un enlace de solicitud es una credencial al portador, y se defiende como tal. Cada enlace lleva un PIN (comprobado contra un verificador almacenado, con bloqueo progresivo), límites de número de archivos y de bytes por solicitud aplicados de forma atómica en la base de datos, una caducidad (hasta 7 días en el plan gratuito; 30 o 90 días, o ninguna, con plazas de Despacho) además de la revocación en cualquier momento, y límites de frecuencia por IP y por enlace. Un enlace compartido no se puede romper por fuerza bruta ni convertir en un punto de subida abierto.

Acceso en equipo

Con una plaza de pago, la identidad de descifrado del despacho se cifra para las claves de cada miembro, así que compartís una bandeja sin compartir nunca claves personales. Un límite honesto: quitar a un miembro bloquea el acceso nuevo, pero quien ya tuviera la clave del despacho en caché puede seguir leyendo los documentos recibidos antes de su salida hasta que se rote la identidad del despacho, y rotarla no vuelve a cifrar lo ya recibido.

Dónde viven los datos

El texto cifrado y los metadatos se guardan en la UE, y cada plaza incluye un contrato de encargo del tratamiento conforme al RGPD. No hay seguimiento de terceros en las páginas de subida ni de bandeja. Para la postura de seguridad completa de la empresa, consulta /security.