Qué puede ver el proveedor, el cliente de sincronización y el hash de contenido si subes un archivo sin cifrar

Arrastrar a Drive no es meterlo en una caja fuerte: entregas el texto en claro al siguiente sistema

El almacenamiento de consumo se trata con facilidad como la caja fuerte de casa: el archivo sigue «en tu cuenta», así que nadie más puede abrirlo. Después del arrastre, esos bytes ya salieron de la carpeta de este disco. Pasan a ser un objeto que el proveedor guarda, sincroniza, deduplica y —a menudo— indexa para la vista previa. Declaraciones, escaneos de DNI, claves privadas SSH, volcados de base de datos y hojas de clientes sin enmascarar son contenido que no debería entrar en claro a un almacén y a un motor de búsqueda de terceros.

HTTPS solo cubre la escucha en el camino. No decide cómo guarda el archivo el otro sistema, quién tiene las claves, qué cachea el cliente de sincronización en esta máquina, ni si un enlace para compartir devuelve cifrado o el texto en claro ya recuperado. La nota anterior cubría otra entrega del mismo tipo: una clave pegada en una sesión de modelo entra en el historial y en la retención. Un archivo sin cifrar arrastrado a Drive es la misma clase de exposición. El destinatario ya no es un proveedor de modelos; es un proveedor de almacenamiento más sus canales de sincronización, vista previa y deduplicación. La pregunta antes de subir no es «si esta nube es lista». Es «si esta copia tiene algo que no debe salir de este dispositivo en claro».

Esta nota se queda con AWS S3, Google Drive / Google Cloud e iCloud porque esos proveedores escriben las capas en un lenguaje público que puedes comprobar. Una nube de consumo rara vez formula «quién guarda las claves» en la misma frase, pero el modelo de ingeniería suele ser el mismo: TLS en el cable, cifrado en reposo con claves del proveedor y, encima, miniaturas, búsqueda de texto completo o subida instantánea. Si cambias de producto, vuelve a recorrer la página de seguridad de esa marca. No pegues SSE-S3 ni «protección de datos estándar» sobre otro nombre.

HTTPS, cifrado en reposo y conocimiento cero no son el mismo candado

Oír «¿la nube está cifrada?» como un sí o un no deja fuera al menos tres capas. La primera es el cifrado en tránsito. El navegador o el cliente de sincronización envía los bytes por TLS. El camino intermedio no ve el texto en claro. Esa capa casi siempre está activa, y es lo único que promete de verdad el candado de la barra de direcciones.

La segunda es el cifrado en reposo: el cifrado del servidor. La definición de AWS del cifrado del servidor de S3 es directa: es el cifrado de los datos en su destino por el servicio que los recibe; S3 los cifra al escribirlos en los discos de los centros de datos de AWS y los descifra cuando accedes al objeto. Desde el 5 de enero de 2023, cada carga nueva usa por defecto SSE-S3 (claves administradas por Amazon S3). El algoritmo es AES-256, cada objeto tiene su propia clave y AWS rota la clave raíz. Siempre que la petición esté autenticada y autorizada, «no existe diferencia alguna en la forma de obtener acceso a objetos cifrados o sin cifrar». Una URL prefirmada funciona igual para ambos. Enumerar objetos tampoco distingue cifrados de no cifrados. En otras palabras: esta capa protege un disco robado. No significa «AWS no puede abrir tu archivo».

La redacción pública de Google para Drive es parecida: los archivos que subes o creas en Documentos, Hojas de cálculo y Presentaciones «se cifran en tránsito y en reposo con el cifrado AES de 256 bits». La confidencialidad extra exige el cifrado del lado del cliente de Workspace, y ese camino necesita una cuenta de trabajo o de centro educativo con un administrador que lo haya activado. Solo después de ese interruptor Google escribe que «Google no puede descifrarlos». La capa predeterminada no lo dice. El cifrado en reposo predeterminado de Google Cloud es más explícito: Google posee y administra las claves del cifrado predeterminado. Si te quedas en esa capa, no tienes esas claves y no controlas la rotación.

Apple separa lo predeterminado de lo opcional. La información general sobre la seguridad de los datos de iCloud (publicada el 8 de enero de 2026) dice que la protección de datos estándar es la configuración predeterminada de la cuenta: los datos están cifrados y las claves viven en los centros de datos de Apple para que Apple pueda ayudarte a recuperar. Solo algunas categorías van cifradas de punto a punto por defecto. El recuento es concreto: 15 categorías lo están siempre, entre ellas Salud y el Llavero de iCloud. La protección de datos avanzada opcional sube esa cifra a 25 e incluye la copia de seguridad de iCloud, Fotos, Notas e iCloud Drive. Si desactivas la protección avanzada, el dispositivo «cargará de forma segura las claves de encriptación necesarias en los servidores de Apple». Lo predeterminado no es «Apple tampoco puede abrir los archivos de iCloud Drive».

Qué puede seguir haciendo el proveedor cuando tiene las claves

Que el proveedor pueda descifrar no es una frase para asustar. Es la premisa que necesitan las funciones predeterminadas del producto. La vista previa de un PDF, las miniaturas de fotos, el OCR, la búsqueda de texto completo y «ordenar por tipo» exigen que algún servidor vea el contenido, o al menos un índice en claro derivado de él. Google escribe el coste del cifrado del lado del cliente en la misma página de ayuda: los Documentos, Hojas de cálculo y Presentaciones cifrados no se editan en las aplicaciones móviles, no admiten comentarios de Drive, no tienen escritura por voz y pierden varios complementos; los archivos del editor cifrados tienen un tope de 100 MB; el historial de versiones guarda como máximo 100 versiones. Esos límites existen por una razón concreta: el servidor ya no tiene una clave que abra el texto en claro.

AWS escribe la otra cara con la misma claridad. Cuando compartes un objeto con una URL prefirmada, el acceso del destinatario se parece al de un objeto sin cifrar. SSE-S3 no convierte «la persona que abrió el enlace» en «solo cifrado». Detiene «quién se llevó un disco». Una cuenta robada, un enlace filtrado, una extracción de un administrador de empresa y una petición lícita recorren el camino del «acceso autorizado». El cifrado en reposo predeterminado deja pasar ese camino.

Las nubes de consumo añaden otra capa: el cliente de sincronización. El archivo aparece primero en una carpeta local y después se sube. Aunque la nube escriba después cifrado en reposo, este ordenador, otro ya iniciado en casa y las cachés sin conexión del teléfono pueden guardar cada uno una copia en claro. Cerrar la pestaña del navegador no borra un archivo que ya aterrizó en la carpeta de sincronización.

La caché de sincronización, las vistas previas, el hash de contenido y los enlaces para compartir son copias de más

Oír «subida completada» como «solo hay una copia, en la nube» se deja copias en ambos lados. La primera es la copia de trabajo del cliente de sincronización: la cola de subida, la caché de reintentos y los restos de un conflicto de versiones. La segunda es un archivo derivado que el servidor construye para la vista previa: una miniatura, un vídeo transcodificado, texto de OCR. Esos suelen vivir aparte del original. Borrar el original no se lleva el derivado en el mismo instante.

La tercera es un hash de contenido. Muchas nubes calculan el hash del archivo entero, o de cada bloque, y lo usan para la subida instantánea y la deduplicación: el cliente envía primero el hash; si el servidor ya lo tiene, los bytes no vuelven a viajar. Es cómodo para un archivo sin cifrar. También admite que «el mismo texto en claro vive una sola vez en el sistema». Sube un instalador sin cifrar o un PDF público y el servidor puede confirmar que lo tienes solo con el hash. Sube el mismo contrato interno desde varios escritorios y la deduplicación sigue guardando un solo objeto en claro. Si cifras primero en este dispositivo, cada pasada usa un salt y un IV nuevos, el cifrado cambia de hash y la subida instantánea falla. No es un error. Es el resultado directo de «el proveedor no puede ver el contenido».

Apple publica una versión de esto incluso con la protección de datos avanzada. La misma información general de iCloud dice que parte de los metadatos se queda bajo protección estándar: «las sumas de comprobación de los datos de archivos y fotos se utilizan para ayudar a Apple a deduplicar y optimizar el almacenamiento de iCloud y tu dispositivo». En iCloud Drive eso incluye «las sumas de comprobación de bytes sin procesar del contenido del archivo y el nombre del archivo». El cifrado de punto a punto del cuerpo del archivo no es lo mismo que «Apple nunca ve una huella de los bytes». Trata igual cualquier aviso de «el archivo ya está en la nube» o de subida instantánea: un acierto de hash es una afirmación sobre el contenido, no solo sobre tu cuenta.

La cuarta copia es un enlace para compartir o un espacio de equipo. En cuanto el enlace sale, el modelo habitual es «quien tenga el enlace puede recuperar el archivo». Junto con la sección anterior: el cifrado en reposo predeterminado no reescribe una descarga como «solo cifrado». Lo que se abre en el otro navegador es el texto en claro recuperado. Un «enlace de Drive» en un chat de grupo y adjuntar el archivo tienen superficies distintas. Si el texto en claro salió de tu cuenta, la respuesta suele ser la misma.

Por qué un ZIP con contraseña casi nunca es cifrado del lado del cliente

«Lo comprimo con contraseña y lo subo» suena a cifrado del lado del cliente. Pregunta primero qué cifrado ZIP usaste de verdad. El cifrado clásico de PKWARE (ZipCrypto) es un cifrado de flujo. En 1994, Eli Biham y Paul Kocher escribieron en A Known Plaintext Attack on the PKZIP Stream Cipher que el cifrado es débil y no debería proteger datos valiosos: unos 13 a 40 bytes de texto en claro conocido ya comprimido, o unos 30 a 200 bytes al inicio de un archivo sin comprimir, recuperaban la representación interna de la clave en un ordenador personal de aquella época en cuestión de horas. El código moderno baja el listón. bkcrack documenta la recuperación con al menos 12 bytes de texto en claro conocido (al menos 8 consecutivos), que restaura el estado interno y luego abre el resto del archivo —y otras entradas cifradas con la misma contraseña. La longitud de la contraseña no ayuda en este ataque. El objetivo es el estado del flujo de clave, no adivinar tu frase.

Aunque el compresor pase a AES, un ZIP puede dejar en la cabecera los nombres de archivo, la estructura de carpetas y comentarios de entrada sin cifrar. Las listas de Drive, la búsqueda y los filtros de «tipo» leen esos metadatos. Tratar «el archivo tiene contraseña» como «la nube solo ve ruido» se deja tanto la cabecera como el algoritmo débil.

Un fallo operativo más frecuente: el archivo cifrado y un readme.txt que guarda la contraseña aterrizan en la misma carpeta y se sincronizan juntos. El candado y la llave van al mismo custodio. Ni el cifrado en reposo ni la contraseña del ZIP salvan ese caso.

Qué cambia si cifras en este dispositivo antes de subir

El cifrado del lado del cliente tiene una prueba estrecha: el texto en claro se convierte en cifrado antes de salir del dispositivo; la contraseña que deriva la clave no se envía al proveedor de almacenamiento; el proveedor no puede abrir el archivo en la operación normal. Google describe el cifrado del lado del cliente de Workspace como «de extremo a extremo y entre clientes», y nombra que «Google no puede descifrarlos». Esa es una capa extra que activa un administrador. No es el valor predeterminado de un Drive personal gratuito. Cifrar tú y luego subir recorre el mismo límite. Las claves se quedan en tu contraseña y en tu dispositivo. No dependes de que una nube traiga un interruptor de cifrado del lado del cliente.

Un camino comprobable en el navegador es AES-GCM de Web Crypto, no un XOR casero. Las notas de MDN sobre AesGcmParams coinciden con NIST SP 800-38D: bajo una misma clave, el IV debe ser único cada vez; la especificación recomienda un IV de 96 bits (12 bytes); el IV no tiene que ser secreto y puede ir en claro junto al cifrado. NIST carga el peso en la unicidad: reutilizar un IV bajo la misma clave puede permitir una falsificación, y ese requisito es casi tan importante como guardar la clave en secreto. La etiqueta de autenticación por defecto es de 128 bits (16 bytes). Una contraseña incorrecta o un cifrado alterado debe fallar en cerrado, no emitir un texto en claro roto.

Cifrar archivo de MakePwd implementa ese límite: AES-256-GCM por bloques en la pestaña actual, una contraseña estirada con PBKDF2-HMAC-SHA256 y 100.000 iteraciones, un salt nuevo de 16 bytes por archivo, un IV nuevo de 12 bytes por bloque, y una salida escrita como IV + cifrado + etiqueta de 16 bytes. Un archivo puede llegar a 5 GB. El bloque predeterminado es de 1 MB para no leer el archivo entero en memoria de una vez. La salida es .lock o .enc, el mismo formato binario. El archivo y la contraseña no se suben. Todas las herramientas se abren sin cuenta, y no hay un almacén de contraseñas que te las guarde. La página responde «¿puede esto convertirse en cifrado antes de salir del navegador?». No sube el archivo a una nube en tu nombre.

Compruébalo aquí: el canario no entra en la cola de subida

Un eslogan que diga «no se sube nada» no puede demostrarse a sí mismo. Parte la comprobación en dos. Primero confirma que el paso de cifrado no envió el texto en claro como dato de negocio. Después confirma que el objeto que entregas a la nube es cifrado.

1. Crea un archivo de texto con una frase que no aparecerá en el trabajo real, por ejemplo canary-cloud-20260902-only-once. El nombre del archivo también puede llevar el canario. Usa una contraseña larga de un solo uso, no una que reutilices.
2. Abre la página de cifrado de archivos en el navegador. Abre las herramientas de desarrollo, ve a Red (Network) y activa Preserve log. Elige el archivo, introduce la contraseña y descarga el .lock. Pega el canario en el filtro: no debe aparecer en una línea de petición, en un cuerpo ni en analytics. La contraseña tampoco debe aparecer.
3. Abre el .lock descargado en un visor hexadecimal o en un editor. La cabecera debe mostrar un número mágico fijo, no la frase canario. Una contraseña incorrecta debe fallar y no debe escribir un archivo en claro roto.
4. Si aún quieres una copia en tu propia nube, sube el .lock, no el original. Cuando termine la subida, busca en la vista previa: no debe aparecer texto legible. No pongas la contraseña en la misma carpeta de sincronización.

La primera mitad —línea de petición, cuerpo, analytics— es la misma comprobación que Cifrar en el navegador: cómo comprobar que el original no salió de este dispositivo. Esta nota añade el cuarto paso: en cuanto el objeto sale del navegador, la capa cambia de «Web Crypto local» a «¿la nube lo tratará como texto en claro?». El canario solo debería existir en el original que guardaste. Si aparece en una vista previa o en un acierto de subida instantánea, seguiste subiendo una copia sin cifrar.

Practica el límite en Cifrar archivo, que se abre sin cuenta

Si lo que quieres es «convertirlo primero en cifrado y luego decidir a dónde va», no hace falta registrarse ni entregar el archivo a MakePwd. Abre Cifrar archivo, elige un archivo pequeño desechable, cífralo con una contraseña larga aleatoria, descarga el .lock y busca en Red como arriba. Cuando una persona tenga que recordar o recibir la contraseña, saca una cadena aleatoria de 6 a 128 caracteres del generador de contraseñas (16 por defecto; por debajo de 8 se marca como más débil) y valora enviarla una vez con un enlace de un solo uso en lugar de meterla en la misma carpeta que el cifrado. La clave del enlace de un solo uso va en el fragmento # de la URL. La página de lectura es pública para el destinatario.

Cifrar archivo no sustituye el interruptor de cifrado del lado del cliente de una nube, y no promete cómo el otro producto escaneará el cifrado en busca de malware o inspeccionará nombres de archivo. La cabecera del .lock lleva el nombre original, así que la nube aún puede ver el nombre. Si el nombre mismo debe quedar oculto, cámbialo a algo sin sentido antes de cifrar. Una contraseña olvidada no se recupera desde el cifrado. Guárdala en un sitio que controles.

Preguntas frecuentes

Si Drive dice que está cifrado, ¿el proveedor puede abrir mis archivos?

Con el cifrado en reposo predeterminado, casi siempre sí. AWS escribe que el cifrado del servidor cifra al escribir en disco y descifra cuando accedes; una petición autorizada trata igual un objeto cifrado y uno sin cifrar. Google guarda las claves del cifrado predeterminado. La protección de datos estándar de Apple deja la mayoría de las claves en sus centros de datos para poder ayudarte a recuperar. Eso no es la misma capa que «el proveedor no puede descifrar».

¿Basta un ZIP con contraseña antes de subir?

El ZipCrypto clásico no. En 1994 Biham y Kocher demostraron que unos doce bytes de texto en claro conocido recuperan el estado interno de la clave; la longitud de la contraseña no ayuda. Incluso un ZIP con AES puede dejar nombres de archivo y la estructura de carpetas a la vista. Si la nube debe ver solo cifrado, termina el cifrado autenticado en este dispositivo primero.

Si cifro primero, ¿siguen funcionando la subida instantánea y la vista previa?

Suele fallar contra los bytes originales. La subida instantánea compara un hash de contenido; el mismo texto en claro cifrado con un salt y un IV nuevos produce otro hash. La vista previa, las miniaturas y el OCR necesitan el texto en claro. Es el coste esperado: si el proveedor no ve el contenido, tampoco puede construir una vista previa por ti.

¿Puedo guardar la contraseña en la misma carpeta de la nube que el .lock?

No. El cifrado y la contraseña en la misma cuenta y la misma carpeta de sincronización entregan el candado y la llave al mismo custodio. Guarda la contraseña en un gestor, o envíala una vez con un enlace de un solo uso. Una contraseña olvidada no se recupera desde el .lock. Ese es el límite de una copia de conocimiento cero, no un defecto.

Tres cosas que recordar antes de la próxima subida

Primero: el candado de la barra de direcciones y una etiqueta que dice «cifrado» cubren el camino y un disco robado. No cubren al proveedor, a un administrador ni a quien tenga un enlace para compartir. Segundo: la caché de sincronización, los derivados de vista previa, los hashes de contenido y los enlaces para compartir pueden guardar cada uno una copia; una subida sin cifrar pone el texto en claro en esos caminos. Tercero: si la nube debe ver solo bytes opacos, cifra en este dispositivo con AES-256-GCM a .lock / .enc, envía la contraseña por otro canal y busca el canario en Red y en la vista previa de la nube.

Si la siguiente pregunta es si el paso de cifrado envió el texto en claro como dato de negocio, lee Cifrar en el navegador: cómo comprobar que el original no salió de este dispositivo. Cuando una persona tiene que recibir la contraseña que abre el cifrado, lee Por qué el fragmento # de una URL encaja para una clave y cuándo esa protección falla y Qué queda en el servidor después de leer una vez un enlace de un solo uso. Esta nota solo traza una línea que puedes escribir en una conclusión: qué puede quedar después de que un archivo sin cifrar entre en una nube de consumo.