Cómo funciona el cifrado
SG/Send usa cifrado simétrico AES-256-GCM, realizado íntegramente en tu navegador. El servidor nunca ve tus datos en texto plano, tus nombres de archivo ni tus claves de cifrado. Esta página explica exactamente cómo.
Cifrado simétrico: una clave, dos operaciones
SG/Send usa cifrado simétrico — la misma clave cifra y descifra el archivo. Este es el modelo de cifrado más simple y rápido, y cuando se hace correctamente, el más seguro para transferencia de archivos.
¿Qué es AES-256-GCM?
AES (Advanced Encryption Standard) es el algoritmo de cifrado utilizado por gobiernos, bancos y fuerzas militares en todo el mundo. 256 es el tamaño de la clave en bits — hay 2256 claves posibles, lo que hace que la fuerza bruta sea computacionalmente imposible. GCM (Galois/Counter Mode) añade cifrado autenticado — no solo cifra, sino que también detecta si alguien ha alterado el texto cifrado.
¿Por qué simétrico?
El cifrado simétrico usa una clave tanto para cifrar como para descifrar. Esto es diferente del cifrado asimétrico (como RSA) que usa un par de claves. Para transferencia de archivos, el simétrico es la elección correcta: es rápido, bien entendido, y la Web Crypto API proporciona una implementación probada en cada navegador moderno.
El flujo de cifrado: paso a paso
Esto es exactamente lo que ocurre cuando envías un archivo a través de SG/Send.
Generación de clave
Cuando seleccionas un archivo, tu navegador genera una clave AES aleatoria de 256 bits usando la Web Crypto API (crypto.subtle.generateKey). Esto usa el generador de números aleatorios criptográficamente seguro del sistema operativo. La clave existe solo en la memoria de tu navegador.
Generación de IV
Se genera aleatoriamente un Vector de Inicialización (IV) de 12 bytes (crypto.getRandomValues). El IV asegura que cifrar el mismo archivo dos veces produzca texto cifrado diferente. El IV no es secreto — se antepone a la salida cifrada y se envía con el texto cifrado.
Cifrado
El archivo se cifra en el navegador usando crypto.subtle.encrypt con el algoritmo AES-GCM, la clave generada y el IV. La salida es texto cifrado + una etiqueta de autenticación de 128 bits. La etiqueta de autenticación es la garantía de integridad de GCM — si alguien modifica incluso un bit del texto cifrado, el descifrado fallará.
Subida
Solo la salida cifrada (IV + texto cifrado + etiqueta de autenticación) se sube al servidor. El servidor recibe un blob de bytes que parecen aleatorios. Asigna un Transfer ID (12 caracteres aleatorios) y almacena el texto cifrado. Sin nombre de archivo, sin indicación de tipo de contenido, sin clave — solo bytes cifrados.
Compartir enlace
El remitente obtiene un enlace de descarga. La clave de descifrado se coloca en el fragmento de la URL (la parte después de #). Los fragmentos de URL nunca son enviados al servidor por el navegador — esto está definido en RFC 3986. El remitente comparte este enlace por el canal que prefiera (email, chat, en persona).
Descifrado
El destinatario abre el enlace. Su navegador descarga los bytes cifrados del servidor, extrae la clave del fragmento de la URL, separa el IV del texto cifrado y descifra usando crypto.subtle.decrypt. Si la etiqueta de autenticación no coincide (se detecta manipulación), el descifrado falla. El servidor nunca participa en el descifrado.
Lo que el servidor ve frente a lo que no ve
Esta es la garantía de conocimiento cero. Esto es exactamente lo que existe en el servidor.
El servidor almacena
Transfer ID — 12 caracteres aleatorios
Bytes cifrados — indistinguibles de datos aleatorios
Hash de IP — SHA-256 de IP + sal rotativa diaria
Marca de tiempo — cuándo se creó la transferencia
Tamaño de archivo — tamaño del blob cifrado (bytes)
El servidor nunca ve
Clave de cifrado — permanece en el navegador, se comparte a través del fragmento de URL
Nombre de archivo — nunca se envía al servidor
Tipo de archivo — no se almacena metadata de content-type
Contenido en texto plano — solo se sube texto cifrado
Dirección IP sin procesar — se aplica hash antes de almacenar
Stack tecnológico
Cada capa se elige por simplicidad, seguridad y despliegue sin dependencias.
| Capa | Tecnología | Propósito |
|---|---|---|
| Entorno de ejecución | Python 3.12 / arm64 | Lenguaje del servidor de aplicaciones |
| Framework web | FastAPI vía osbot-fast-api | Enrutamiento HTTP y gestión de peticiones |
| Computación | AWS Lambda + Mangum | Ejecución serverless, pago por uso |
| Almacenamiento | Memory-FS (Storage_FS) | Backend conectable: memoria, disco o S3 |
| Cifrado | Web Crypto API (AES-256-GCM) | Cifrado del lado del cliente en el navegador |
| Sistema de tipos | Type_Safe (osbot-utils) | Definiciones de esquemas sin Pydantic |
| Frontend | Vanilla JS + Web Components | Cero dependencias de frameworks (IFD) |
| Testing | pytest, stack en memoria | Sin mocks, sin patches, implementaciones reales |
| CI/CD | GitHub Actions | Pipeline de test, etiquetado y despliegue |
Arquitectura del sistema
Dos funciones Lambda, una capa de almacenamiento, un CDN. Simple por diseño.
Lambda Usuario (pública)
Función pública que gestiona transferencias de archivos, verificaciones de salud, subidas prefirmadas, bóvedas personales e integración MCP. Se accede a través de Lambda Function URL detrás de CloudFront.
18 endpointsLambda Admin (autenticada)
Función exclusiva para administración: gestión de tokens, analíticas, estadísticas del servidor y herramientas MCP de administración. Requiere autenticación. Lambda separada = frontera de seguridad separada.
55 endpointsMemory-FS (Storage_FS)
Todo el almacenamiento pasa por una capa de abstracción. El código de la aplicación nunca sabe si el backend está en memoria, en disco o en S3. El mismo código base para los 7 objetivos de despliegue.
Backend conectableCloudFront CDN
Recursos estáticos, caché, terminación SSL y WAF. Las Lambda URLs proporcionan los endpoints HTTPS directamente — no se necesita API Gateway.
Red perimetralObjetivos de despliegue
Un código base, siete objetivos de despliegue agrupados en cuatro patrones.
Lambda
Despliegue principal. Dos funciones Lambda detrás de Lambda Function URLs. Endpoints HTTPS directos, sin necesidad de API Gateway.
ProducciónContenedor
Docker, AWS Fargate y GCP Cloud Run. La misma aplicación empaquetada como contenedor.
Docker / Fargate / GCPServidor
Instancias EC2 y builds de AMI. Para equipos que necesitan control total del entorno de ejecución.
EC2 / AMICLI
Interfaz de línea de comandos para transferencias automatizadas, pipelines de CI/CD y usuarios avanzados.
Terminal