Como Funciona a Encriptação
O SG/Send utiliza encriptação simétrica AES-256-GCM, realizada inteiramente no seu navegador. O servidor nunca vê os seus dados em texto simples, os nomes dos seus ficheiros ou as suas chaves de encriptação. Esta página explica exactamente como.
Encriptação Simétrica: Uma Chave, Duas Operações
O SG/Send utiliza encriptação simétrica — a mesma chave encripta e desencripta o ficheiro. Este é o modelo de encriptação mais simples e rápido e, quando feito correctamente, o mais seguro para transferência de ficheiros.
O que é AES-256-GCM?
AES (Advanced Encryption Standard) é o algoritmo de encriptação utilizado 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 encriptação autenticada — não apenas encripta, mas também detecta se alguém adulterou o texto cifrado.
Porquê Simétrica?
A encriptação simétrica utiliza uma chave tanto para encriptação como para desencriptação. Isto é diferente da encriptação assimétrica (como RSA) que utiliza um par de chaves. Para transferência de ficheiros, 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 Encriptação: Passo a Passo
Eis exactamente o que acontece quando envia um ficheiro pelo SG/Send.
Geração da Chave
Quando selecciona um ficheiro, o seu navegador gera uma chave AES aleatória de 256 bits usando a Web Crypto API (crypto.subtle.generateKey). Isto utiliza o gerador de números aleatórios criptograficamente seguro do sistema operativo. A chave existe apenas na memória do seu navegador.
Geração do IV
Um Vector de Inicialização (IV) de 12 bytes é gerado aleatoriamente (crypto.getRandomValues). O IV garante que encriptar o mesmo ficheiro duas vezes produz texto cifrado diferente. O IV não é secreto — é adicionado ao início do resultado encriptado e enviado com o texto cifrado.
Encriptação
O ficheiro é encriptado no navegador usando crypto.subtle.encrypt com o algoritmo AES-GCM, a chave gerada e o IV. O resultado é texto cifrado + uma etiqueta de autenticação de 128 bits. A etiqueta de autenticação é a garantia de integridade do GCM — se alguém modificar mesmo um bit do texto cifrado, a desencriptação falhará.
Envio
Apenas o resultado encriptado (IV + texto cifrado + etiqueta 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 ficheiro, sem indicação de tipo de conteúdo, sem chave — apenas bytes encriptados.
Partilha do Link
O remetente recebe um link de transferência. A chave de desencriptação é colocada no fragmento do URL (a parte após #). Os fragmentos do URL nunca são enviados ao servidor pelo navegador — isto está definido no RFC 3986. O remetente partilha este link pelo canal que escolher (email, chat, pessoalmente).
Desencriptação
O destinatário abre o link. O navegador descarrega os bytes encriptados do servidor, extrai a chave do fragmento do URL, separa o IV do texto cifrado e desencripta usando crypto.subtle.decrypt. Se a etiqueta de autenticação não corresponder (adulteração detectada), a desencriptação falha. O servidor nunca participa na desencriptação.
O Que o Servidor Vê vs. O Que Não Vê
Esta é a garantia zero-knowledge. Eis exactamente que dados existem no servidor.
O servidor armazena
Transfer ID — 12 caracteres aleatórios
Bytes encriptados — indistinguíveis de dados aleatórios
Hash do IP — SHA-256 do IP + salt com rotação diária
Marca temporal — quando a transferência foi criada
Tamanho do ficheiro — tamanho do blob encriptado (bytes)
O servidor nunca vê
Chave de encriptação — permanece no navegador, partilhada via fragmento do URL
Nome do ficheiro — nunca enviado ao servidor
Tipo de ficheiro — sem metadados content-type armazenados
Conteúdo em texto simples — apenas texto cifrado é enviado
Endereço IP em bruto — hash aplicado antes do armazenamento
Pilha Tecnológica
Cada camada é escolhida pela simplicidade, segurança e implementaçã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 pedidos |
| Computação | AWS Lambda + Mangum | Execução serverless, pagamento por utilização |
| Armazenamento | Memory-FS (Storage_FS) | Backend modular: memória, disco ou S3 |
| Encriptação | Web Crypto API (AES-256-GCM) | Encriptação 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, etiquetagem e implementação |
Arquitectura do Sistema
Duas funções Lambda, uma camada de armazenamento, um CDN. Simples por concepção.
Lambda Utilizador (Público)
Função pública que gere transferências de ficheiros, verificações de saúde, envios pré-assinados, cofres pessoais e integração MCP. Acedida via Lambda Function URL atrás do CloudFront.
18 endpointsLambda Admin (Autenticado)
Função apenas para administração para gestão de tokens, analítica, 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 abstracçã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 directamente — 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
Implementação principal. Duas funções Lambda por trás de Lambda Function URLs. Endpoints HTTPS directos, sem necessidade de API Gateway.
ProduçãoContentor
Docker, AWS Fargate e GCP Cloud Run. A mesma aplicação empacotada como contentor.
Docker / Fargate / GCPServidor
Instâncias EC2 e builds AMI. Para equipas que precisam de controlo total do ambiente de execução.
EC2 / AMICLI
Interface de linha de comandos para transferências por script, pipelines CI/CD e utilizadores avançados.
Terminal