Antes de dejar un archivo en la nube, quién puede leer el texto plano y por qué canal debe ir la contraseña

Un paquete de certificados, una hoja de personal exportada o una config que todavía lleva una clave privada acaban, casi siempre, en Drive personal o en una carpeta compartida de la empresa. La página de subida dirá «cifrado en tránsito», «cifrado en reposo» o «bóveda». Esas frases nombran los discos y los tubos del proveedor, no «nadie más que tú puede abrirlo». Otro artículo ya cubrió cómo comprobar en Red que el texto plano no salió: el eslogan no es una prueba. Esta nota es un escenario más estrecho — el archivo está a punto de dejar este ordenador y sentarse en el almacenamiento de otro. Primero parte quién puede leer el texto plano. Luego decide por qué canal debe ir la contraseña.

Esto no es un recuento de funciones de «cifrar archivo online», ni una comparativa de nubes. Solo tres preguntas: antes de que salga nada, ¿el texto plano se convirtió primero en texto cifrado?; después de subir, ¿el proveedor o el siguiente que descargue puede abrir el cuerpo tal cual?; ¿la contraseña viajó en el mismo mensaje que el .lock o el .enc? La caja de archivos de MyPassGen trabaja en ese límite: AES-256-GCM termina en el navegador y luego descargas el resultado. El archivo y la contraseña no se envían como dato de negocio. Todas las herramientas se abren sin cuenta. La tabla y los pasos de abajo se pueden comprobar en el momento.

«Cifrado» suele nombrar la capa del proveedor

HTTPS solo cubre a quien escucha en el camino. Cuando el archivo llega a Drive, Dropbox o OneDrive, el proveedor todavía puede dejarlo en texto plano o como texto cifrado que él mismo puede desenvolver. Muchos productos etiquetan ese cifrado en reposo con claves del proveedor como «tus archivos están cifrados». Para operaciones, ayuda si un disco sale de un centro de datos. Para «no quiero que el lado del almacenamiento abra el escaneo del DNI», no basta.

Cifrar en el cliente primero y subir después es otra capa. El navegador o un programa local deriva una clave a partir de una contraseña que tú tienes. El disco se queda con texto cifrado. Rclone Crypt, algunas herramientas de sincronización y Web Crypto en una pestaña viven en esta capa. Responden «quien almacena no puede usar el cuerpo». No responden una contraseña débil, una contraseña enviada con el archivo o un nombre que ya cuenta el contenido.

El artículo 9 del RGPD trata los datos biométricos usados para identificar de forma unívoca a una persona, y otras categorías especiales, como datos que exigen una base jurídica concreta. Un escaneo de DNI sin cifrar, dejado en Drive personal y reenviado a un grupo, sigue transfiriendo el documento identificativo. Cifrar y luego subir reduce quién puede abrir los bytes. No es anonimización, y no sustituye «¿este archivo debería salir de la máquina?».

Quién puede leer el texto plano

Mete el mismo certs.zip en un disco en la nube y ya puedes partir tres clases. La diferencia no es la frase de marketing. Es quién tiene la clave, y si el texto plano salió del navegador antes.

Solo la tercera clase responde «no quiero que el lado del almacenamiento vea el cuerpo». El cifrado tiene que terminar antes de subir, y la clave no debe entregarse a esa máquina de almacenamiento. El artículo anterior ya lo dijo: la Web Crypto API garantiza que la cuenta puede hacerse en este dispositivo. No prohíbe que una página suba primero y cifre después. «Cifrar en local primero» se comprueba en el tráfico. No se comprueba en un eslogan.

Qué hace AES-256-GCM en este paso

La primera versión de MyPassGen usa solo AES-256-GCM. NIST SP 800-38D define GCM como cifrado autenticado: si el texto cifrado se altera, el descifrado debe fallar. No obtienes un cuerpo ilegible que puedas tratar como documento. RFC 5116 AEAD_AES_256_GCM usa una clave de 32 bytes, un nonce de 12 bytes y una etiqueta de autenticación de 16 bytes. AesGcmParams en MDN también recomienda un IV de 96 bits, y hay que usar un IV nuevo en cada cifrado con la misma clave. El IV no es un secreto. Puede viajar con el texto cifrado.

La contraseña no se usa como clave AES. La caja de archivos de este sitio ejecuta PBKDF2 con 100.000 iteraciones, SHA-256 y una sal de 16 bytes, y luego una clave de 256 bits. La sal vive en la cabecera para que el descifrado pueda recalcular la misma clave. RFC 8018 cita NIST SP 800-132: el número de iteraciones debe ser tan alto como permita una espera aceptable. El consejo actual de OWASP para hashes de contraseña almacenados en un servidor es PBKDF2-HMAC-SHA256 con al menos 600.000 iteraciones. Ese es otro trabajo. La primera línea de defensa de la contraseña de un archivo sigue siendo una cadena larga y aleatoria. El número de iteraciones frena la fuerza bruta sin conexión. No salva un 123456 escrito en un comentario de Drive.

La contraseña no viaja con el cifrado

El fallo habitual no es el algoritmo equivocado. Es enviar backup.lock y «la contraseña es el verano más el número de empleado» en el mismo hilo de Slack o WhatsApp, en el mismo correo o en un readme.txt sentado en la misma carpeta de Drive. El lado del almacenamiento, o cualquiera en ese canal, entonces tiene las dos mitades. El cifrado local no hizo nada.

Una separación más segura: el texto cifrado va por Drive o como adjunto; la contraseña va por otro canal — en persona, por teléfono o con un enlace de un solo uso (la clave se queda detrás de # en la URL; la página de lectura no pide cuenta). No pongas la contraseña en el nombre del archivo, en el comentario de un zip ni en una nota «solo yo la veo» que sigue viviendo bajo la misma cuenta de la nube.

Genera la contraseña en esta máquina con el generador de contraseñas. El modo aleatorio admite de 6 a 128 caracteres, 16 por defecto. Por debajo de 8 debe tratarse como débil. Una contraseña olvidada no se recupera: no hay copia en claro en el servidor ni preguntas de seguridad. Ese es el coste de que el disco no vea el cuerpo. No es una función que falte.

Qué sigue mostrando un .lock

El texto cifrado no es «el archivo entero convertido en ruido ilegible». Una cabecera de contenedor pública suele seguir llevando metadatos. MyPassGen escribe .lock por defecto y también puede escribir .enc — el mismo formato, distinta extensión, para alinearse con otras herramientas. La cabecera empieza con cuatro bytes CSLK, luego una versión, una sal de 16 bytes, un tamaño de bloque y el nombre original y el tipo MIME en texto plano. El cuerpo es AES-GCM en trozos de unos 1 MB. Cada trozo lleva su propio IV de 12 bytes y su etiqueta de 16 bytes.

Así, si cifras dni-escaneo.pdf en dni-escaneo.pdf.lock y lo subes, el listado de Drive y la cabecera siguen diciendo «esto es un documento de identidad». El cifrado protege los bytes del cuerpo, no el nombre. Cuando el nombre es sensible, renombra el original a algo sin significado antes de cifrar. Tampoco le des al .lock subido un título legible.

Un archivo puede llegar a 5 GB. El cifrado corta con Blob.slice en unos 1 MB y entrega cada trozo a crypto.subtle.encrypt. El encrypt() de Web Crypto acepta un BufferSource cada vez. Meter el archivo entero en una sola llamada clava la memoria de una pestaña grande. Cortar evita «darle todo el texto plano a la API de una vez». El resultado se ensambla igual en esta máquina para la descarga. El descifrado, en la implementación actual, lee primero el .lock entero, así que un archivo muy grande cuesta más memoria — eso se ve en el administrador de tareas, no en un eslogan.

Compruébalo en el momento

Los pasos de abajo no dependen de una promesa de marca. Usa un archivo de texto pequeño y desechable. No practiques con un escaneo real de DNI.

1. Crea un probe.txt de unas decenas de bytes y escribe una frase de prueba que solo tú conozcas, por ejemplo orange-lake-7. No uses una contraseña real ni un número de documento.
2. Abre la pestaña Red de las herramientas para desarrolladores y activa «Conservar registro». Abre la página de cifrado de archivos, elige ese archivo, pon una contraseña y empieza a cifrar.
3. Lee cada Fetch / XHR: la línea de la petición y el cuerpo no deberían contener orange-lake-7, ni la contraseña que acabas de escribir. Analytics tampoco debería llevarse el original. Scripts, estilos y estadísticas sin cuerpo de archivo sí están permitidos.
4. Descarga el .lock o el .enc. En un visor hexadecimal, los cuatro primeros bytes de la cabecera deben ser 43 53 4C 4B (ASCII CSLK). Más adelante deberías ver el nombre original probe.txt en texto plano — no la frase de prueba.
5. Suelta ese texto cifrado en la misma página. La contraseña correcta debe restaurar la frase de prueba. Cambia un carácter de la contraseña y el descifrado debe fallar. No deberías obtener un cuerpo ilegible.
6. Solo entonces sube el .lock a Drive o Dropbox. Envía la contraseña en otro mensaje. Abre la vista previa de la nube: sin la contraseña, el original no debería abrirse.

La página Cifrar de MyPassGen trabaja en ese límite: AES-256-GCM, PBKDF2 a 100.000 iteraciones, un archivo de hasta 5 GB, salida .lock / .enc. El cálculo termina en la pestaña actual. No creas una cuenta. Lo que debes creer sigue siendo Red y la cabecera, no las cinco palabras «no subimos nada».

Un secreto corto no debe hacerse archivo

Una clave API, un código de recuperación o la contraseña de una base de datos no necesitan convertirse primero en archivo. El camino del archivo entero encaja con paquetes de certificados, hojas exportadas y trozos de imagen de disco. El texto corto corresponde a un enlace de un solo uso: texto plano de hasta 32 KB, el servidor solo guarda texto cifrado, la clave se queda detrás de # y puedes fijar lecturas y TTL. Crear y leer funcionan sin iniciar sesión.

Las notas que salen hacia fuera son otro trabajo. Una URL con utm_source sigue qué parámetros puedes quitar. Teléfonos y números de DNI en un ticket siguen qué campos debes enmascarar. Cifrar un archivo responde «el lado del almacenamiento no puede abrir el cuerpo». No responde «esta conversación no debería llevar un número completo».

Errores frecuentes

«La nube dice cifrado, así que solo yo puedo leerlo.» Cuando el proveedor tiene o gestiona las claves, operaciones, un requerimiento legal y una cuenta robada siguen viendo un archivo usable. Cifra en local primero y el conjunto de personas que pueden desenvolverlo se reduce a quienes tienen la contraseña.

«HTTPS ya protege todo el viaje.» HTTPS termina en la entrada del proveedor. Cuando el archivo aterriza, el perímetro de protección cambia de manos. Lo que reduces es el texto plano de la copia que se queda en reposo.

«Renombrar a .lock es cifrar.» Un archivo renombrado que nunca pasó por cifrado autenticado sigue buscándose como texto plano en un editor. La cabecera debe tener un número mágico acordado, y el cuerpo no debe abrirse. Cambiar solo la extensión no hace nada.

«Olvidé la contraseña; soporte puede restablecerla.» El almacenamiento de conocimiento cero no tiene copia de la contraseña en el servidor. El pie de página tampoco ofrece un buzón de soporte para «resetear una contraseña de cifrado». La contraseña vive en tu propio gestor, o en otro canal que controles.

Por dónde empezar

Empieza por el archivo que tienes que subir hoy. Haz los seis pasos de arriba con un archivo pequeño desechable. Confirma que Red no tiene el original, que la cabecera es CSLK y que una contraseña incorrecta falla. Luego cifra el archivo real. Si el nombre es sensible, renómbralo primero.

Sube el texto cifrado a Drive o adjúntalo al correo. Di la contraseña en persona, llámala o crea un enlace de un solo uso. No dejes la contraseña en un texto de la misma carpeta. Con esa pasada ya puedes responder el título: el lado del almacenamiento no debería obtener texto plano; la contraseña no debería viajar con el cifrado; la cabecera puede seguir mostrando el nombre original, y ese nombre pide su propio paso.

Preguntas frecuentes

¿En qué se diferencia la «bóveda» del proveedor de cifrar en local primero?

Una bóveda suele seguir teniendo al proveedor con las claves o gestionándolas. Entras en la misma cuenta y abres el archivo. Después de cifrar en local, el lado del almacenamiento no puede desenvolver el cuerpo sin la contraseña. Si roban la cuenta, quien no tenga la contraseña solo puede descargar texto cifrado.

Si olvido la contraseña, ¿puedo descifrar igual?

No. No hay copia en claro ni de la contraseña en el servidor. Usa una contraseña larga y aleatoria y guárdala en tu propio gestor. Ese es el coste simétrico de «el lado del almacenamiento no ve el cuerpo».

¿Qué diferencia hay entre .lock y .enc?

En este sitio son el mismo contenedor con distinta extensión. El descifrado acepta ambos sufijos. No asumas que el .enc de otro programa usa la misma cabecera.

¿Hace falta una cuenta para cifrar? ¿Se sube el archivo?

No hace falta cuenta. El riesgo de registro empieza cuando entregas el original a un sitio que cifra por ti. El tratamiento local deja el archivo y la contraseña en la pestaña actual. Lo que compruebas es si Red envió un cuerpo de archivo o una contraseña, y si todavía puedes buscar la frase de prueba dentro del .lock.