Como Funciona a Criptografia
O SG/Send utiliza criptografia simétrica AES-256-GCM, realizada inteiramente no seu navegador. O servidor nunca vê seus dados em texto simples, os nomes dos seus arquivos ou suas chaves de criptografia. Esta página explica exatamente como.
Criptografia Simétrica: Uma Chave, Duas Operações
O SG/Send utiliza criptografia simétrica — a mesma chave criptografa e descriptografa o arquivo. Este é o modelo de criptografia mais simples e rápido e, quando feito corretamente, o mais seguro para transferência de arquivos.
O que é AES-256-GCM?
AES (Advanced Encryption Standard) é o algoritmo de criptografia usado por governos, bancos e forças armadas em todo o mundo. 256 é o tamanho da chave em bits — existem 2256 chaves possíveis, tornando a força bruta computacionalmente impossível. GCM (Galois/Counter Mode) adiciona criptografia autenticada — não apenas criptografa, mas também detecta se alguém adulterou o texto cifrado.
Por Que Simétrica?
A criptografia simétrica utiliza uma chave tanto para criptografia como para descriptografia. Isso é diferente da criptografia assimétrica (como RSA) que utiliza um par de chaves. Para transferência de arquivos, a simétrica é a escolha certa: é rápida, bem compreendida e a Web Crypto API fornece uma implementação testada em combate em todos os navegadores modernos.
O Fluxo de Criptografia: Passo a Passo
Eis exatamente o que acontece quando você envia um arquivo pelo SG/Send.
Geração da Chave
Quando você seleciona um arquivo, seu navegador gera uma chave AES aleatória de 256 bits usando a Web Crypto API (crypto.subtle.generateKey). Isso utiliza o gerador de números aleatórios criptograficamente seguro do sistema operacional. A chave existe apenas na memória do seu navegador.
Geração do IV
Um Vetor de Inicialização (IV) de 12 bytes é gerado aleatoriamente (crypto.getRandomValues). O IV garante que criptografar o mesmo arquivo duas vezes produz texto cifrado diferente. O IV não é secreto — é adicionado ao início do resultado criptografado e enviado com o texto cifrado.
Criptografia
O arquivo é criptografado no navegador usando crypto.subtle.encrypt com o algoritmo AES-GCM, a chave gerada e o IV. O resultado é texto cifrado + uma tag de autenticação de 128 bits. A tag de autenticação é a garantia de integridade do GCM — se alguém modificar mesmo um bit do texto cifrado, a descriptografia falhará.
Envio
Apenas o resultado criptografado (IV + texto cifrado + tag de autenticação) é enviado para o servidor. O servidor recebe um blob de bytes com aparência aleatória. Atribui um Transfer ID (12 caracteres aleatórios) e armazena o texto cifrado. Sem nome de arquivo, sem indicação de tipo de conteúdo, sem chave — apenas bytes criptografados.
Compartilhamento do Link
O remetente recebe um link de download. A chave de descriptografia é colocada no fragmento da URL (a parte após #). Os fragmentos da URL nunca são enviados ao servidor pelo navegador — isso é definido no RFC 3986. O remetente compartilha esse link pelo canal que escolher (email, chat, pessoalmente).
Descriptografia
O destinatário abre o link. O navegador baixa os bytes criptografados do servidor, extrai a chave do fragmento da URL, separa o IV do texto cifrado e descriptografa usando crypto.subtle.decrypt. Se a tag de autenticação não corresponder (adulteração detectada), a descriptografia falha. O servidor nunca participa na descriptografia.
O Que o Servidor Vê vs. O Que Não Vê
Esta é a garantia zero-knowledge. Eis exatamente que dados existem no servidor.
O servidor armazena
Transfer ID — 12 caracteres aleatórios
Bytes criptografados — indistinguíveis de dados aleatórios
Hash do IP — SHA-256 do IP + salt com rotação diária
Timestamp — quando a transferência foi criada
Tamanho do arquivo — tamanho do blob criptografado (bytes)
O servidor nunca vê
Chave de criptografia — permanece no navegador, compartilhada via fragmento da URL
Nome do arquivo — nunca enviado ao servidor
Tipo de arquivo — sem metadados content-type armazenados
Conteúdo em texto simples — apenas texto cifrado é enviado
Endereço IP bruto — hash aplicado antes do armazenamento
Pilha Tecnológica
Cada camada é escolhida pela simplicidade, segurança e implantação sem dependências.
| Camada | Tecnologia | Finalidade |
|---|---|---|
| Runtime | Python 3.12 / arm64 | Linguagem do servidor de aplicação |
| Framework Web | FastAPI via osbot-fast-api | Roteamento HTTP e tratamento de requisições |
| Computação | AWS Lambda + Mangum | Execução serverless, pagamento por uso |
| Armazenamento | Memory-FS (Storage_FS) | Backend modular: memória, disco ou S3 |
| Criptografia | Web Crypto API (AES-256-GCM) | Criptografia do lado do cliente no navegador |
| Sistema de Tipos | Type_Safe (osbot-utils) | Definições de esquemas sem Pydantic |
| Frontend | Vanilla JS + Web Components | Zero dependências de frameworks (IFD) |
| Testes | pytest, stack em memória | Sem mocks, sem patches, implementações reais |
| CI/CD | GitHub Actions | Pipeline de teste, tag e implantação |
Arquitetura do Sistema
Duas funções Lambda, uma camada de armazenamento, um CDN. Simples por design.
Lambda Usuário (Público)
Função pública que gerencia transferências de arquivos, verificações de saúde, envios pré-assinados, cofres pessoais e integração MCP. Acessada via Lambda Function URL atrás do CloudFront.
18 endpointsLambda Admin (Autenticado)
Função apenas para administração para gerenciamento de tokens, analytics, estatísticas do servidor e ferramentas de administração MCP. Requer autenticação. Lambda separado = fronteira de segurança separada.
55 endpointsMemory-FS (Storage_FS)
Todo o armazenamento passa por uma camada de abstração. O código da aplicação nunca sabe se o backend é em memória, em disco ou S3. Mesma base de código em todos os 7 alvos de implantação.
Backend ModularCloudFront CDN
Recursos estáticos, caching, terminação SSL e WAF. Os Lambda URLs fornecem os endpoints HTTPS diretamente — sem necessidade de API Gateway.
Rede EdgeAlvos de Implantação
Uma base de código, sete alvos de implantação agrupados em quatro padrões.
Lambda
Implantação principal. Duas funções Lambda por trás de Lambda Function URLs. Endpoints HTTPS diretos, sem necessidade de API Gateway.
ProduçãoContêiner
Docker, AWS Fargate e GCP Cloud Run. A mesma aplicação empacotada como contêiner.
Docker / Fargate / GCPServidor
Instâncias EC2 e builds AMI. Para equipes que precisam de controle total do ambiente de execução.
EC2 / AMICLI
Interface de linha de comando para transferências por script, pipelines CI/CD e usuários avançados.
Terminal