Una contraseña no es un candado sobre todo el archivo
Es fácil tomar un ZIP protegido con contraseña por un cofre: quien tiene el archivo no ve nada sin la clave. El formato está más fragmentado. Un ZIP es primero un directorio y después una lista de archivos. El indicador de cifrado va en la cabecera local y en la entrada del directorio central de cada archivo. No va en «el .zip entero». Poner una contraseña solo quiere decir que al menos un flujo comprimido quedó envuelto por algún algoritmo. No quiere decir que el directorio sea ilegible, ni que cada entrada haya usado el mismo algoritmo o la misma frase.
Nóminas, escaneos de DNI, claves SSH privadas, volcados de base de datos y hojas de clientes sin enmascarar no deberían salir como pistas en claro fuera de la carpeta en la que trabajas. La pregunta no es «si este compresor es listo». Es «si este paquete ha entregado un nombre en claro, una entrada abierta o un flujo débilmente cifrado que debería haberse quedado en este disco». La nota anterior cubría un caso cercano: un archivo sin cifrar soltado en un Drive aún lo pueden abrir el proveedor, el cliente de sincronización y un hash de contenido. Comprimir primero con contraseña solo mueve la pregunta: ya no es «si la nube ve el archivo», es «qué capa ha cerrado de verdad este contenedor».
Esta nota se atiene al APPNOTE.TXT 6.3.10 de PKWARE (1 de noviembre de 2022), a las especificaciones AES WinZip AE-1 / AE-2 y a la descripción AES-256 del formato 7z de 7-Zip, porque esos textos escriben las capas en un lenguaje que puedes cruzar con un listado local. Una política de empresa, una página web «cifrar zip» y una interfaz vieja pueden añadir otra capa. Cambia de herramienta, relee las opciones de cifrado de esa versión y mira Method otra vez. No pegues las frases de ZipCrypto de abajo sobre un archivo que ya eligió AES-256 o marcó «Cifrar nombres de archivo».
ZipCrypto, el extra AES y el cifrado de nombres son tres capas
Oír «¿el ZIP está cifrado?» como un sí o un no deja fuera al menos tres capas. La primera es el cifrado clásico de PKWARE —el que las interfaces suelen llamar ZipCrypto o Zip 2.0. La sección 6 del APPNOTE acota el alcance: PKZIP cifra el flujo de datos ya comprimido. Cada archivo cifrado empieza por una cabecera de 12 bytes. Tres claves de 32 bits salen de la frase y se actualizan con el mismo CRC-32 que el ZIP ya usa. La extensión sigue siendo .zip. El Explorador o un extractor viejo suelen pedir la contraseña. La compatibilidad es buena. La robustez es otra pregunta.
La segunda capa es el AES que se añadió después dentro del mismo contenedor ZIP. WinZip deja la estructura base y añade una pieza: el método de compresión pasa a ser 99 en decimal, y tanto la cabecera local como el directorio central llevan un campo extra de 11 bytes 0x9901 cuyo identificador de fabricante es el ASCII AE. Los bytes de fuerza 0x01 / 0x02 / 0x03 corresponden a claves de 128, 192 y 256 bits. El método real (el 8 de Deflate, por ejemplo) se mueve a ese campo extra. Un programa viejo que no entiende AES suele avisar «método de compresión 99 no admitido», en lugar de tratar el cifrado como texto en claro. Esta capa protege el contenido. Por defecto no reescribe los nombres del directorio central como cifrado.
La tercera capa es «cubrir también el directorio». El Strong Encryption del ZIP escribe el cifrado del directorio central como una opción y pide indicadores general purpose extra, sobre todo los bits 6 y 13. ZipCrypto clásico no tiene esa capa. El formato 7z toma otro camino. La página de formato de 7-Zip indica AES-256, una derivación de clave a partir de la frase con una función basada en SHA-256, y un número alto de iteraciones para encarecer una búsqueda exhaustiva. La opción de línea de comandos -mhe=on cifra los nombres de archivo. Sin ella, un listado puede seguir mostrando los nombres aunque el contenido esté en AES.
| Capa | Qué suele cerrar | Qué puede seguir visible | Cómo reconocerla |
|---|---|---|---|
| ZipCrypto / PKWARE clásico | El flujo comprimido de ese archivo | Nombres, entradas sin cifrar, estructura del archivo | 7z l -slt: Method contiene ZipCrypto |
| WinZip AES (AE-1 / AE-2) | El contenido de ese archivo (AES + HMAC) | Los nombres; otras entradas sin cifrar en el mismo archivo | Método 99, campo extra 0x9901, Method contiene AES- |
| 7z + cifrado de nombres | El contenido y la cabecera del directorio | Los nombres pueden listarse aún si -mhe=on está apagado |
Casilla «Cifrar nombres de archivo» de 7-Zip, o -mhe=on |
Una ficha de producto o un menú contextual que diga «AES-256» responde al algoritmo del contenido. No dice si los nombres están en una cabecera en claro, ni si algunas entradas no tienen contraseña. Comprueba primero Method y la lista de archivos; después, la longitud de la frase.
ZipCrypto: la especificación misma lo tacha de débil
El cifrado clásico no es un rumor del tipo «se dice que es débil». El dueño del formato ya lo ha rebajado. El APPNOTE 6.0.1 escribe que esta forma se considered weak by today’s standards y la recomienda solo para una necesidad de seguridad baja, o para seguir siendo compatible con programas ZIP antiguos. La misma sección dibuja el esqueleto: las claves parten de los enteros de 32 bits 305419896, 591751049 y 878082192; update_keys aplica un CRC-32 a cada byte de la frase; una cabecera de 12 bytes al inicio de la zona de datos sigue mezclando las claves; el último o los dos últimos bytes de la cabecera se comparan con los bits altos del CRC para decidir si la frase «parece» correcta. Es un cifrado de flujo. No es un modo de bloque autenticado como AES-GCM.
La especificación también dice que la cabecera de 12 bytes existe para «hacer ineficaz un ataque en claro sobre los datos». La investigación pública tomó otro camino. En 1994, Eli Biham y Paul C. Kocher publicaron A Known Plaintext Attack on the PKZIP Stream Cipher: un trozo de texto en claro conocido basta para recuperar el estado interno. La nota de 2002 de Michael Stay, ZIP Attacks with Reduced Known Plaintext, bajó aún más la cantidad de texto en claro necesaria. Los archivos suelen llevar prefijos previsibles —%PDF, una cabecera Office fija, una declaración XML, una firma PNG— porque son formatos de archivo, no secretos. Los pasos de ataque quedan fuera de esta nota. El punto que entra en una conclusión: la debilidad es el algoritmo, no «tu contraseña solo tiene seis caracteres». Alargar la frase no cambia que la especificación tache de débil el cifrado clásico, ni que exista una línea de investigación con texto en claro conocido.
La compatibilidad explica por qué el método sigue ahí. El Explorador de archivos de Windows crea y abre ZIP corrientes, pero no tiene interfaz nativa «poner contraseña a este ZIP». Un asesor independiente en Microsoft Q&A escribió que hace falta una herramienta de terceros como 7-Zip para poner contraseña, y que el Explorador aún puede pedirla en los archivos ZipCrypto que producen esas herramientas. Por eso muchos programas dejan ZipCrypto por defecto: para que el otro lado haga doble clic. Ganas «no tienen que instalar nada». Pagas el cifrado débil que la especificación ya admite. 7-Zip puede escribir un ZIP en AES-256. Tras ese cambio, un extractor del sistema que solo entiende ZipCrypto puede negarse a abrir el archivo. Es un trueque entre compatibilidad y robustez, no «los dos menús dicen cifrado, así que es lo mismo».
Nombres, CRC y entradas sin cifrar: lo que no entra en el flujo queda en claro
Aunque el contenido pase a AES, un ZIP sigue siendo, por defecto, un contenedor que se puede listar. FileName en la cabecera local y en el directorio central es un campo en claro. El bit 0 general purpose solo significa que el flujo de esta entrada está cifrado. El bit 11 significa que el nombre va en UTF-8. No significa que el nombre esté cifrado. En 2004, el análisis de Tadayoshi Kohno sobre el esquema WinZip escribía tres hechos de formato en lenguaje llano: los metadatos de los archivos cifrados se filtran, los nombres no están autenticados, y un mismo archivo puede contener a la vez archivos cifrados y sin cifrar. Son formas permitidas del contenedor, no errores de implementación.
La propia nota AES de WinZip escribe los archivos mixtos como un permiso formal. Nada exige que cada archivo de un ZIP esté cifrado, ni que los cifrados compartan método o frase. Un archivo puede combinar entradas sin cifrar con Zip 2.0, AES-128, AES-192 y AES-256 en cualquier mezcla. Las entradas de carpeta se recomiendan incluso sin cifrar, para ahorrar espacio. Resultado concreto: metes nomina-2026-09.xlsx y readme.txt en el mismo paquete, y solo la hoja puede pedir contraseña. La nota y los nombres de directorio los lee cualquiera que tenga el ZIP. Destinatarios, pasarelas de correo, vistas previas de Drive y clientes de sincronización suelen ver esa lista primero —no las celdas después de una extracción correcta.
Las cabeceras en claro también llevan tamaños y sumas de comprobación. WinZip escribe que AE-1 guarda el CRC del contenido sin cifrar en la cabecera ZIP, mientras que AE-2 pone el CRC a 0 y se apoya en un código de autenticación de 10 bytes para la integridad. La FAQ da el motivo: en un archivo de cuatro bytes o menos, el CRC mismo puede ayudar a inferir el original, da igual el cifrado. A partir de WinZip 11, la mayoría de los archivos vuelven a AE-1 para un control de integridad extra, pero los archivos cuyo tamaño sin comprimir es menor de 20 bytes, y los flujos BZIP2 que ya llevan su propio control, se quedan en AE-2 y no guardan CRC. La derivación de clave es PBKDF2 (RFC 2898) con 1.000 iteraciones; la función seudoaleatoria es HMAC-SHA1. La especificación también apunta que HMAC-SHA1 sale a 160 bits, así que el espacio de búsqueda efectivo de un AES de 192 o 256 bits no se lee como la longitud teórica de la clave. No hace falta un «crack» para comprobar estos números. Ya están en la especificación pública.
Comprobar un ZIP protegido sin extraer el texto en claro
Un eslogan «le puse contraseña, así que está seguro» no se demuestra solo. Parte la comprobación en pasos que puedes terminar en esta máquina. Cada paso responde a una pregunta. No uses una nómina real, un certificado ni una clave privada para el experimento.
No comprimas un escaneo de DNI que sigas usando, una clave de producción o una tabla de personal viva «solo para ver cómo queda». Prepara un canario desechable —por ejemplo un archivo llamado canary-nomina-20260905.txt cuyo cuerpo sea una marca de un solo uso. Estás comprobando el directorio y Method, no volviendo a comprimir el archivo de verdad.
- Escribe un texto canario cuyo nombre tenga a propósito pinta de documento de trabajo, por ejemplo
canary-nomina-20260905.txt. Si te hace falta una frase aleatoria, saca 6 a 128 caracteres del generador de contraseñas (16 por defecto; por debajo de 8 aparece un aviso de fuerza baja). Trata esa cadena solo como contraseña de archivo, no como una contraseña de inicio de sesión nueva. - Monta un ZIP como sueles enviar: algunas herramientas parten de ZipCrypto; otras exigen elegir AES-256. No renombres el archivo para «esconder» el tema. Monta un segundo archivo 7z, una vez con cifrado de nombres y otra sin, para comparar.
- No introduzcas aún la frase. Abre el ZIP en 7-Zip, o lanza
7z l -slt canary.zipen un terminal. Mira si la lista ya muestracanary-nomina-20260905.txt. Luego busca la líneaMethod =:ZipCryptoes el cifrado clásico;AES-256es el AES de contenido. Lees las dos cosas sin extraer el cuerpo, así que no están detrás de «primero hay que teclear la contraseña». - Lista el archivo 7z del mismo modo. Sin cifrado de nombres, el nombre suele aparecer aún. Con
-mhe=on, el nombre canario no debería aparecer hasta que introduzcas la frase. Es una comprobación de la tercera capa, no una afirmación de que «el 7z es automáticamente más misterioso que el ZIP». La diferencia es si la cabecera del directorio está cubierta. - Suelta el archivo canario en el Drive o en el borrador de correo que usas de verdad (no lo envíes a nadie). Mira si la vista previa o la interfaz web lista los nombres internos. La nota anterior cubría la subida instantánea y la vista previa sobre un archivo sin cifrar; aquí, aunque el contenido esté cerrado, los nombres de directorio aún pueden indexarse. Cuando termines, borra el archivo canario y el original, y mira la papelera.
Saber si esta pestaña entregó texto en claro a un servidor es otra pregunta, tratada en Cifrar en el navegador: cómo comprobar que el original no salió de este dispositivo. Un compresor casi siempre tiene que leer el original en esta máquina para empaquetarlo. Esta nota pregunta qué queda después del empaquetado, fuera del flujo cifrado. Si el nombre canario aparece en 7z l -slt o en una vista previa de Drive antes de que teclees una contraseña, la frontera de confianza es más ancha que «el otro no tiene la contraseña». Si Method sigue siendo ZipCrypto, has comprado compatibilidad, no un cifrado fuerte en el sentido de la especificación.
Separar el cifrado de un archivo entero de la contraseña de ZIP
Si lo que quieres es «convertir este archivo en cifrado en este dispositivo y luego decidir si el correo o un Drive lo transporta», no tienes que registrarte y no entregas el archivo a MakePwd. Abre Cifrar archivo. La pestaña cifra por bloques con AES-256-GCM y te deja descargar .lock o .enc. La frase secreta se estira con PBKDF2-HMAC-SHA256 y 100.000 iteraciones; cada archivo tiene su propia sal. Un archivo puede llegar a 5 GB. El archivo, la frase secreta y el texto en claro no salen como datos de negocio. Todas las herramientas se abren sin cuenta, y no hay un almacén de contraseñas que te guarde esa frase.
Cifrar archivo responde a «¿estos bytes se han vuelto cifrado antes de salir del navegador?». No responde a «¿un ZIP cierra los nombres por defecto?». Tú eliges el nombre de la descarga, así que no estás obligado a enviar un nominas-2026.xlsx.zip que anuncia el tema. La cabecera .lock aún puede llevar el nombre original; si es sensible, renómbralo antes de cifrar. El cifrado puede viajar por un Drive o un correo. Envía la frase por otro canal —por ejemplo un enlace de un solo uso: la clave se queda en el fragmento # de la URL, no entra en HTTP, crear y leer son públicos, y el servidor solo guarda cifrado. Cuando te haga falta una frase aleatoria, saca 6 a 128 caracteres del generador de contraseñas y cópiala solo en esa página. Lo que un proveedor aún puede ver después de una subida sin cifrar es la nota anterior. Esta solo traza una línea alrededor de lo que un ZIP protegido con contraseña aún puede dejar detrás.
Preguntas frecuentes
Si un ZIP tiene contraseña, ¿está cifrado el archivo entero?
No. El APPNOTE de PKWARE pone el indicador de cifrado en el bit 0 general purpose de cada archivo. Ese bit cubre el flujo comprimido de esa entrada, no el contenedor. Los nombres están en la cabecera local y en el directorio central. La nota AES de WinZip dice que un mismo ZIP puede mezclar entradas sin cifrar con Zip 2.0, AES-128, AES-192 y AES-256, y que las contraseñas pueden diferir.
¿Qué diferencia hay entre ZipCrypto y un ZIP AES-256?
ZipCrypto es el cifrado clásico de PKWARE de la sección 6 del APPNOTE: tres claves de 32 bits, una cabecera de 12 bytes y actualización de claves con CRC-32. La especificación lo considera débil según los criterios de hoy y lo reserva a necesidades poco sensibles o a programas ZIP antiguos. WinZip AES usa el campo extra 0x9901, el método de compresión 99, una sal, un verificador de contraseña y un código de autenticación HMAC-SHA1. Ambos siguen usando .zip: hay que leer Method, no la extensión.
¿Se puede ver la lista de archivos sin la contraseña?
Casi siempre sí, en un ZIP clásico y en un 7z que no haya cifrado los nombres. 7z l -slt de 7-Zip lista nombres y Method sin extraer el texto en claro. El formato 7z puede cifrar los nombres con -mhe=on; esa es la capa que cubre la cabecera del directorio. El Explorador de archivos de Windows no tiene interfaz nativa para poner contraseña a un ZIP.
¿Un ZIP con contraseña es lo mismo que Cifrar archivo de MakePwd?
No. La contraseña de archivo responde a «qué cifrado ZIP usó este contenedor». Cifrar archivo cifra el archivo entero en esta pestaña con AES-256-GCM, escribe .lock / .enc, limita un archivo a 5 GB, no sube el archivo ni la frase secreta, y se abre sin cuenta. Envía la frase por otro canal, por ejemplo el fragmento # de un enlace de un solo uso.
Tres cosas que recordar antes del próximo archivo
Primero: «le puse contraseña» solo quiere decir que al menos un flujo quedó envuelto por un cifrado ZIP. No quiere decir que el directorio sea ilegible, ni que cada entrada esté cifrada. Segundo: ZipCrypto (la especificación lo tacha de débil; existe una línea de investigación con texto en claro conocido), WinZip AES (más robusto en el contenido; los nombres quedan en claro por defecto) y el cifrado de nombres 7z son tres fronteras distintas. Una extensión .zip o .7z no dice en qué capa estás. Tercero: comprueba Method y los nombres que aparecen antes de la frase con un canario de un solo uso y 7z l -slt. No hagas esa comprobación sobre una hoja real.
Si la siguiente pregunta es qué puede ver aún un proveedor después de que un archivo sin cifrar entre en un Drive, lee Qué puede ver el proveedor, el cliente de sincronización y el hash de contenido si subes un archivo sin cifrar. Cuando el propio paso de cifrado tiene que demostrar que el texto en claro no salió de este dispositivo, lee Cifrar en el navegador: cómo comprobar que el original no salió de este dispositivo. Cuando la frase tiene que viajar aparte y no quieres meterla en el cuerpo de un correo, lee Por qué el fragmento # de una URL encaja para una clave y cuándo esa protección falla. Esta nota solo traza una línea que puedes escribir en una conclusión: después de enviar un ZIP protegido con contraseña, qué pueden dejar aún el cifrado por defecto, los nombres de archivo y las entradas sin cifrar.