Empieza por la conclusión: una contraseña ZIP no demuestra que «la nube no ve los archivos». Solo indica que extraer exige una contraseña. El directorio ZIP es legible por defecto, y el ZipCrypto clásico puede filtrar su clave interna si se conoce un tramo corto de texto en claro. Antes de subir, comprueba dos cosas: si el contenido ya se cerró en este dispositivo con cifrado autenticado, y si esta petición HTTP envió el original o la contraseña.
Responde a la intención de búsqueda en una frase
Poner contraseña a un comprimido antes de subirlo a la nube no es la misma capa que el AES-GCM local. El archivo mete los documentos en un contenedor ZIP y cierra el contenido de esos ficheros. El directorio del propio contenedor —nombres, fechas, tamaños— está pensado para leerse. El AES-256-GCM local usa la Web Crypto API del navegador sobre los bytes; descargas el texto cifrado y luego lo subes. Sin tu contraseña, la nube solo tiene ruido.
Esta nota es para desarrolladores, operaciones y quien quiera separar «le puse contraseña» de «el otro lado no puede leer el contenido» antes de que una copia aterrice en Drive. No sustituye las instrucciones de la caja de cifrado ni recorre los clics que producen un .lock. Lo que te llevas es qué bloquean ZipCrypto y ZIP-AES, quién guarda las claves por defecto de la nube, qué queda en la cabecera de un texto cifrado local, y cómo contrastar Network y un volcado hexadecimal en esta misma pasada.
«Le puse contraseña» no es «la nube no ve el contenido»
El habla cotidiana junta tres trabajos distintos en «este archivo está cifrado». El primero es el cifrado en tránsito: el navegador habla con Drive por HTTPS, así que un observador del camino lo tiene difícil para leer los bytes. El segundo es el cifrado en reposo del proveedor: los bloques en disco van envueltos con claves que gestiona él, y eso ayuda si se llevan un disco. El tercero es el cifrado del lado del cliente con una clave que tú guardas: el contenido ya es texto cifrado antes de subir, así que el proveedor no lo abre sin tu contraseña.
La contraseña ZIP ocupa un cuarto hábito: construyes en este equipo un contenedor cerrado con contraseña y lo subes como un archivo cualquiera. Drive lo trata como cualquier otro .zip: indexa por nombre, calcula un hash para la carga instantánea y, si la política lo pide, analiza malware o contenido sensible. Si el interior sigue siendo ZipCrypto, o el directorio está en claro, un escáner no necesita «adivinar tu contraseña» para leer los nombres; a veces puede hacer más con el contenido.
Así que «le puse contraseña» solo sostiene una afirmación estrecha: quien no extraiga, o no tenga la contraseña, no abrirá los ficheros con facilidad. No sostiene «un empleado de Drive no puede ver esto», «un requerimiento legal no recupera los originales» ni «los nombres nunca entran en su índice». Esas frases se vuelven comprobables solo cuando cambias de capa: cifrado autenticado en este dispositivo y, después, subida del texto cifrado.
Qué no detiene ZipCrypto
El cifrado clásico de ZIP suele llamarse Zip 2.0 o ZipCrypto. La propia ayuda de WinZip es clara: el formato es relativamente débil y no deberías esperar que detenga a alguien con una herramienta de recuperación dedicada; usa AES cuando los archivos importen. Está en las notas de cifrado de WinZip, no en un rumor de foro.
La debilidad es el cifrado, no si tu contraseña es larga. En 1994, Eli Biham y Paul Kocher publicaron un ataque de texto plano conocido contra el cifrado de flujo de PKZIP: con unos doce bytes de texto en claro y su cifrado coincidente, un atacante recupera los tres estados internos de 32 bits y, con ellos, el flujo de clave del resto del archivo. En ese paso la longitud de la contraseña desaparece: se copia el bombín, no se prueban llaves. Herramientas públicas como bkcrack convierten ese artículo en un programa; los archivos almacenados (sin deflate) con ZipCrypto son el caso más directo.
¿De dónde sale el texto en claro conocido? Un PDF empieza por %PDF. Los documentos de Office, muchas imágenes y los ZIP anidados tienen firmas fijas. Si metes un formato conocido en un ZIP ZipCrypto y lo subes, también has entregado el texto cifrado más una muestra de original casi segura. Esto no es una guía del ataque. Es una razón para dejar de tratar «Comprimir y poner contraseña» como AES-256-GCM.
Los comprimidores del sistema, una página de Drive que ofrece «cifrar y comprimir» y scripts de empaquetado antiguos suelen elegir ZipCrypto porque casi cualquier extractor lo abre. Después de empaquetar, lee las propiedades: si dice ZipCrypto o Zip 2.0, no uses ese archivo como plan de copia. Si dice AES, pasa a la siguiente sección: la capa de contenido es más fuerte; el directorio suele seguir en claro.
No experimentes con un contrato real, el escaneo de un DNI o una carpeta de proyecto sin enmascarar. Prepara un archivo pequeño que puedas tirar. Pon un canario de un solo uso en el nombre y en el cuerpo. Estás comprobando el directorio, la cabecera y el tráfico, no volviendo a subir privacidad.
Aunque el ZIP use AES, el directorio sigue en claro
WinZip ofrece AES-128 y AES-256 (AE-1 / AE-2) desde la versión 9.0. La clave sale de la contraseña por PBKDF2, con una sal de 8, 12 o 16 bytes y 1000 iteraciones. Es un salto grande respecto a ZipCrypto, pero sigue sin ser «AES-256-GCM en el navegador». WinZip AES cifra y luego autentica (AES-CTR más HMAC). No es el GCM de NIST. Mil iteraciones también quedan muy por debajo de la derivación de contraseña de orden cien mil que es habitual ahora. WinZip documenta el empaquetado en su página de cifrado AES.
El directorio se pasa por alto con más facilidad. WinZip indica que el cifrado solo aplica al contenido de los ficheros internos. Nombre, fecha, tamaño, atributos y ratio de compresión viven en un directorio sin cifrar. Quien tenga el ZIP los lee sin contraseña. Incluso publicaron una nota sobre «abrir un ZIP cifrado y seguir viendo los nombres», y sugieren un doble ZIP: empaqueta una vez sin cifrar y mete ese archivo dentro de un segundo ZIP cifrado. Véase WinZip sobre la visibilidad de nombres.
El formato .7z de 7-Zip puede marcar «Cifrar nombres de archivo». Es otra línea de producto; no lo mezcles con el comportamiento por defecto de ZIP. «Se requiere contraseña» en el Explorador solo significa que extraer pide contraseña. Abre el mismo archivo en otro extractor y la lista suele aparecer al momento: dni-reverso.jpg, nominas-2026.xlsx, lista-clientes.csv. La carga instantánea, la vista previa y los análisis de política leen esa capa.
«Cifrado en Drive» suele significar que el proveedor guarda las claves
Suelta un ZIP —o el original— en Drive y la página hablará de cifrado en tránsito, cifrado en reposo, AES-256. Esas frases pueden ser ciertas a la vez y aun así no responder quién guarda la clave de unwrap. La ayuda de Drive dice que los archivos subidos o creados en Docs / Sheets / Slides se cifran en tránsito y en reposo con AES-256 por defecto. Si además quieres que Google no pueda descifrar, un administrador de Workspace debe activar el cifrado del lado del cliente, y el usuario debe usar una cuenta de trabajo o de centro educativo y terminar la verificación de identidad. Un archivo personal arrastrado a «Mi unidad» sigue la ruta por defecto, no el cifrado del lado del cliente. Está en la ayuda de archivos cifrados de Drive.
Google Cloud formula el modelo por defecto en reposo con aún más claridad: las claves son de Google y las gestiona Google. Las claves de cifrado de datos (DEK) en disco se envuelven con claves de cifrado de claves (KEK); el unwrap ocurre en el servicio de claves del proveedor. Véase el cifrado en reposo por defecto de Google Cloud. Los documentos de Workspace trazan la misma raya entre «Google gestiona las claves» y «tras el cifrado del lado del cliente, Google no puede leer». Los hashes de carga instantánea, la vista previa de documentos y los análisis de cumplimiento asumen que el servidor puede ver los bytes del archivo —o al menos un hash en claro. Una contraseña ZIP local no convierte esa pila en conocimiento cero.
Así que el candado de la insignia de Drive protege «un disco salió de un centro de datos» y «un observador en el camino». No protege «después de entregar el archivo a esta empresa, ella tampoco lo ve». Esa segunda frase se vuelve una observación solo cuando el original legible ya no existe antes de subir.
Qué capa protege de verdad el AES-256-GCM local
AES-GCM es cifrado autenticado: una sola pasada oculta los bytes y ata la integridad. Si el texto cifrado se altera, se trunca o la contraseña es incorrecta, el descifrado debe fallar de golpe, no emitir «basura que parece texto en claro». NIST SP 800-38D recomienda un IV de 96 bits (12 bytes) para un GCM interoperable; la etiqueta suele ser de 128 bits (16 bytes). Reutilizar un IV con la misma clave tumba a la vez la confidencialidad y la autenticidad.
El camino correcto en un navegador es crypto.subtle.encrypt con el nombre de algoritmo AES-GCM. MDN indica que SubtleCrypto.encrypt solo está disponible en un contexto seguro: HTTPS en producción. Una contraseña no es una clave de 256 bits. Tiene que pasar por una función como PBKDF2 con sal y muchas iteraciones. El RFC 2898 define PBKDF2; el recuento de iteraciones es cuánto tarda un intento. Mil y cien mil no son la misma clase.
Un flujo de archivo se puede escribir como acciones que ves: eliges un archivo local, el script lo lee por bloques, cada bloque recibe un IV aleatorio nuevo y AES-256-GCM, y el navegador descarga el texto cifrado. Esa descarga se arma en este dispositivo. No es un recibo del servidor. Un tope de 5 GB por archivo describe el procesamiento en streaming del navegador. No significa que un host remoto recibiera 5 GB de texto en claro.
La caja de cifrado de FastPwd sigue ese límite: AES-256-GCM en Web Crypto; la contraseña pasa por PBKDF2-HMAC-SHA256, 100000 iteraciones, una sal de 16 bytes y una clave de 256 bits; los bloques por defecto son de 1 MB, cada uno con un IV de 12 bytes, texto cifrado y una etiqueta de 16 bytes; un archivo de hasta 5 GB; salida .lock / .enc con magia CSLK. Todas las herramientas están listas para usar: no hay cuenta ni almacén de contraseñas. Si olvidas la contraseña, no se puede recuperar, porque nunca se subió. Una promesa sigue siendo solo una promesa. La lista de abajo incluye la parte de la cabecera que no está cifrada.
Qué puede demostrar el cifrado, y qué sigue mostrando la cabecera
La conclusión que sostiene el cifrado local es igual de estrecha. Escribirla evita una lectura errónea. Puede sostener: en esta pasada, el contenido del archivo se convirtió bloque a bloque en texto cifrado autenticado; sin la contraseña, el descifrado debe fallar; si Network no encuentra el canario, el original y la contraseña no salieron como el dato de negocio HTTP que observaste.
No puede sostener: la nube no ve ningún metadato, una extensión no leyó el portapapeles, la contraseña es lo bastante fuerte, o quien tenga el texto cifrado nunca hará un intento sin conexión. FastPwd Lock v1 guarda el nombre original y el MIME en claro en la cabecera para que el descifrado restaure el nombre. Sube dni-reverso.lock, o deja dni-reverso.jpg en la cabecera, y Drive —o cualquiera con un visor hexadecimal— puede leer esas palabras. El cifrado cubre los bloques de contenido, no la etiqueta que el contenedor enseña al mundo.
| Lo que ves | Lo que eso sostiene | Lo que eso no sostiene |
|---|---|---|
| Extraer el ZIP pide contraseña | La capa de contenido tiene un cierre | El directorio está oculto; el algoritmo es AES-GCM |
| Puedes listar nombres sin extraer | El directorio ZIP está en claro (el default habitual) | El contenido también se puede abrir |
| Las propiedades dicen ZipCrypto / Zip 2.0 | Cifrado de flujo clásico; aplica un ataque de texto plano conocido | Una contraseña larga detiene una herramienta dedicada |
| Drive muestra «almacenamiento cifrado» | Es probable que haya cifrado en tránsito o en reposo | El proveedor no tiene claves y no ve el original |
Este dispositivo descargó un .lock / .enc |
El navegador produjo un archivo de texto cifrado | El nombre original de la cabecera también está oculto |
| Network no encuentra el canario | Estas peticiones no llevaron esos campos | Las extensiones, el portapapeles y la siguiente versión están limpios |
Contrástalo ahora: Network, la cabecera y sin red
Los eslóganes no son prueba. Prepara un archivo pequeño que puedas tirar. Pon canary-fp-20260904-zip-vs-gcm en el cuerpo y nómbralo canary-fp-20260904.txt. Usa una frase de contraseña larga de un solo uso. No reutilices una real.
- Primero el control: empaqueta el mismo archivo en un ZIP con contraseña. Ábrelo en un extractor sin introducir la contraseña. Anota si se ven los nombres y si las propiedades dicen ZipCrypto o AES. Ese es el rango que cubre de verdad una contraseña ZIP.
- Después cifra en local en el navegador. Abre Network en las herramientas para desarrolladores, marca Preserve log y deja el filtro en All. Cuando termine el cifrado, pega el canario en el cuadro de búsqueda. No debería aparecer en líneas de petición, cuerpos ni analítica.
- Abre el
.lockdescargado en un visor hexadecimal. Los cuatro primeros bytes deberían serCSLK(43 53 4C 4B). Más adelante deberías ver la sal, el tamaño de bloque y el nombre original que dejaste. La zona de contenido no debería seguir mostrando esa frase canario en claro. - Cuando la página ya haya cargado, pon Network en Offline o apaga la red del sistema y cifra otro archivo pequeño desechable. Si un
.lockse sigue descargando, este cifrado/descifrado no necesitó una API en vivo. Sin red tiene que pasar; al reconectar, busca el canario otra vez.
No envíes la contraseña por el mismo canal que el texto cifrado. Deja el .lock en Drive; manda la contraseña por Burn-Link: este navegador cifra con AES-256-GCM, el servidor solo guarda texto cifrado y la clave va en el fragmento # del enlace, con forma s.html?id={id}#{key}. Soltar la dirección completa de quema en la misma carpeta de Drive que el texto cifrado es pegar la llave a la caja.
Renombra el origen a algo sin significado antes de cifrar. La cabecera escribe ese nombre tal cual; la extensión .lock / .enc también aparece en la lista de Drive. Eso solo reduce «el propio nombre filtró». No es esteganografía.
Tres casos que parecen cifrados y no bloquean lo que crees
Primero, «cifrar y comprimir» en una web. Algunos discos empaquetan cuando la subida ya terminó, o envuelven un enlace compartido con un código de extracción. Ese código detiene a quien no pulsa el enlace. No detiene a un servidor que ya guardó el original. La comprobación: ¿el cifrado ocurrió antes de elegir el archivo, o después de que la barra de progreso llegó al final? El segundo caso no es AES-GCM local.
Segundo, una contraseña de apertura de Office o PDF. Eso protege el flujo de apertura del lector correspondiente. El formato del archivo sigue guardando muchos campos estructurados; la vista previa de Drive, la búsqueda de texto completo y los servicios de conversión a menudo rodean el «pide contraseña al abrir». No lo trates como cifrado autenticado de archivo completo.
Tercero, cambiar la extensión. Pasar .xlsx a .bin antes de subir no detiene la carga instantánea ni algunos escáneres, que siguen trabajando con un hash de contenido; la firma de la cabecera sigue ahí. Una extensión no es criptografía. Tras el cifrado local, esos bytes mágicos deberían desaparecer de la zona de contenido. Si un volcado hexadecimal sigue mostrando PK, %PDF o un marcador xlsx en claro, esta pasada no vale.
Preguntas frecuentes
Si pongo AES-256 al ZIP, ¿sigue siendo inseguro subirlo a Drive?
La capa de contenido es más fuerte que ZipCrypto, pero los nombres, fechas y tamaños del directorio ZIP siguen legibles por defecto. Drive y cualquiera que tenga el archivo pueden listar el contenido. Tampoco es AES-256-GCM en el navegador: WinZip AES usa otro empaquetado y PBKDF2 hace 1000 iteraciones. Si quieres que la nube vea solo texto cifrado, cifra primero todo el contenido en local y luego sube.
Si Drive dice cifrado en tránsito y en reposo, ¿basta con eso?
Eso suele ser el cifrado por defecto con claves que guarda el proveedor. TLS cubre el camino; el cifrado en reposo cubre un disco robado. El proveedor, quien opere con acceso a las claves y un requerimiento legal aún pueden recuperar tus bytes originales. Para que Drive convierta en hecho «Google no puede descifrar esto», un administrador de Workspace debe activar el cifrado del lado del cliente. Esa no es la ruta por defecto cuando una cuenta personal arrastra un archivo a Mi unidad.
Tras subir un .lock de FastPwd, ¿la nube sigue viendo el nombre original?
Sí. Ve la extensión y puede leer el nombre original y el MIME en la cabecera. Lo cifrado es el contenido del archivo en bloques de 1 MB, no los metadatos del contenedor. Renombra el origen a algo sin significado antes de cifrar. No pongas la contraseña en el mismo enlace compartido que el texto cifrado.
Al cifrar en FastPwd, ¿se suben el archivo o la contraseña?
Según las notas del producto, el cifrado y el descifrado terminan en la pestaña actual con Web Crypto. El archivo y la contraseña no se envían como dato de negocio ni se escriben en la analítica. La analítica de visitas registra nombres de acción, no el archivo ni la contraseña. Busca el canario en Network: no debería aparecer en líneas de petición ni en cuerpos. Localhost no envía analítica de visitas por defecto; vuelve a probar en el nombre de host real para acercarte al uso cotidiano.
Pasa el mismo archivo desechable por una herramienta lista para usar
Si quieres una página que deja por escrito el límite de cálculo, abre la caja de cifrado de FastPwd. Lista para usar; sin registro. Elige el archivo canario de arriba y una frase de contraseña larga de un solo uso. Si la contraseña se marca como débil, la página te pide confirmar antes de seguir. Descarga el .lock. Mira Network al mismo tiempo: deberías ver recursos estáticos y, quizá, analítica de visitas, no el archivo original ni la contraseña como campos de negocio.
Puedes generar la contraseña en local en el generador de contraseñas. El modo aleatorio es de 6–128 caracteres, 16 por defecto; por debajo de 8 se marca como menos seguro. La generación tampoco se sube. Cuando un compañero tenga que recibir la contraseña, cambia a Burn-Link. No la dejes en un comentario de Drive. No metas un secreto de una línea en un .lock como transporte: la caja de cifrado sirve para copiar y entregar un archivo entero, no un secreto que pertenece a una línea de chat.
Recuerda tres cosas antes de la próxima subida. Primera: una contraseña ZIP bloquea la extracción, no el directorio, y no un ataque de texto plano conocido contra ZipCrypto. Segunda: el cifrado por defecto de la nube suele dejar las claves en el proveedor. Tercera: el AES-256-GCM local protege los bloques de contenido; la cabecera y la extensión aún pueden filtrar, así que mira Network y un volcado hexadecimal tú mismo. Una observación que puedes repetir es la que merece entrar en vuestras notas de copia.
Para seguir leyendo
«Cifrado local, no se sube» no es prueba hasta que buscas un canario en Network: véase Cómo comprobar que el cifrado local del navegador no envió el original. Cuando entregues la contraseña al destinatario por un canal aparte, véase por qué lo que va detrás de la almohadilla no entra en HTTP por defecto en Por qué el hash de una URL puede guardar una clave, y cuándo esa protección falla. Si además necesitas enmascarar números de documento en un ticket antes de que salgan de este equipo, véase Antes de pegar un ticket o un registro en una IA, comprueba qué campos salen de este equipo.