El almacenamiento cifrado separa los bytes del archivo de la facultad de descifrarlo, pero destinatarios, metadatos y copias locales siguen en el modelo de amenazas.
Un adjunto cifrado de extremo a extremo puede almacenarse en un servidor sin darle acceso al archivo en claro. Un diseño habitual cifra el archivo en el dispositivo del remitente con una nueva clave de contenido, sube el texto cifrado y envía la clave a los destinatarios previstos dentro de un mensaje cifrado y autenticado.
La separación es útil, pero «almacenamiento de conocimiento cero» no es una especificación completa. Aún hay que preguntar cómo se gestionan las claves, referencias, nombres de archivo, controles de acceso y copias descargadas.
El ciclo de vida de un adjunto
- Preparar el archivo. El remitente selecciona una foto, vídeo o documento. Eliminar metadatos o transcodificar es un paso aparte; el cifrado por sí solo no elimina EXIF ni propiedades del documento.
- Crear el material de cifrado. Una implementación segura genera las claves y los nonces necesarios según el esquema elegido.
- Cifrar antes de subir. El servicio de almacenamiento recibe bytes cifrados en vez del contenido original.
- Entregar una referencia autenticada. El mensaje de chat cifrado transporta lo que necesitan los destinatarios, como un localizador del archivo, la clave de descifrado y los metadatos de integridad pertinentes.
- Obtener y verificar. El cliente receptor recupera el objeto de datos y verifica la autenticación antes de tratar el resultado como contenido válido.
- Gestionar las copias locales. Mostrar, exportar, editar o guardar en una galería puede crear copias fuera del límite original del almacenamiento cifrado.
La clave puede viajar por la infraestructura del mismo proveedor dentro de un sobre cifrado. Llamarlo «fuera de banda» puede confundir: está separada lógicamente del almacenamiento del objeto, pero no necesariamente se entrega por un canal de comunicación independiente.
Qué aporta el cifrado autenticado
Un esquema de cifrado autenticado protege la confidencialidad y detecta cambios no autorizados dentro de su ámbito autenticado. La especificación GCM del NIST define una de estas construcciones y sus requisitos. Es esencial gestionar correctamente las claves y nonces y comprobar el resultado de autenticación; el nombre de un algoritmo reconocido no hace segura cualquier implementación.
La aplicación también debe vincular el archivo al mensaje y la conversación correctos. Un objeto cifrado válido no demuestra por sí mismo que pertenezca a este chat concreto. Los identificadores, el tamaño esperado, el orden de los fragmentos y los metadatos del adjunto requieren un diseño autenticado adecuado.
Qué puede seguir averiguando el servicio de almacenamiento
| Información | ¿La oculta por sí solo el cifrado del contenido? |
|---|---|
| Bytes originales del archivo | Está diseñado para ocultarlos a quienes no tienen la clave |
| Tamaño cifrado aproximado | Normalmente no |
| Momentos de subida y descarga | Normalmente no |
| Qué cuenta solicita un archivo | Depende del diseño de enrutamiento y control de acceso |
| Nombre de archivo y descripción | Solo si el protocolo también los protege |
| Una copia guardada por un destinatario | No; el destinatario ya tiene acceso al texto en claro |
Los controles de acceso siguen siendo importantes aunque los objetos estén cifrados. Pueden limitar descargas no deseadas, abusos y exposición de identificadores. El cifrado no sustituye la autorización, las políticas de retención ni la disponibilidad.
Los archivos grandes requieren más que un eslogan
Un diseño para archivos grandes puede transmitir datos progresivamente o dividirlos en fragmentos autenticados. Esto puede reducir el uso de memoria, pero hay que definir numeración, longitud final, reintentos y manejo de truncamientos. No invente cifras de rendimiento ni afirme que incluir un archivo en un mensaje causa necesariamente un «crecimiento excesivo del estado del ratchet»; esos resultados dependen de la implementación.
Una prueba útil incluye un archivo válido, un byte modificado, una descarga truncada, un fragmento fuera de orden y un intento de acceso no autorizado. Ejecute estas pruebas solo en un entorno de prueba autorizado con archivos no sensibles. Registre si el cliente rechaza los datos inválidos antes de abrirlos.
Qué documenta Livara
La página de seguridad de Livara describe el cifrado antes de subir, una clave aleatoria por archivo transportada dentro de la sesión protegida y la protección de nombres y descripciones en conversaciones con E2EE activo, incluidos los grupos privados compatibles. Los grupos antiguos incompatibles quedan explícitamente fuera de esa cobertura. Distingue las conversaciones protegidas de los canales públicos de difusión. Son afirmaciones documentadas del producto, no una nueva auditoría de implementación realizada en este artículo.
El modelo de amenazas también reconoce que un destinatario o dispositivo comprometido puede exponer contenido legible. Por tanto, el almacenamiento cifrado no puede prometer que una imagen desaparezca de todos los dispositivos al borrar su mensaje de chat.
Preguntas antes de compartir archivos sensibles
Compruebe si el tipo de conversación admite E2EE, si confía en todos los destinatarios previstos y si el propio archivo contiene metadatos identificativos. Revise por separado el guardado automático en la galería y las copias de fotos en la nube. En un documento, considere eliminar comentarios, historial de revisiones o propiedades incrustadas antes de enviarlo.
Por último, entienda la eliminación y la recuperación. Quitar un objeto del servidor puede impedir una descarga futura, pero no retirar una copia que ya tenga un destinatario. Perder la clave necesaria puede volver ilegible un archivo cifrado que siga existiendo. Un buen diseño de adjuntos explica claramente ambos resultados.
