Capacidades de encriptação do browser: o que os browsers modernos conseguem fazer

Os browsers modernos incluem criptografia nativa que rivaliza com bibliotecas de segurança dedicadas. O Chrome, Firefox, Safari e Edge expõem todos a Web Crypto API (crypto.subtle), implementam TLS 1.3 com mecanismos sucessores do HPKP para fixação de certificados, suportam WebAuthn/passkeys para autenticação resistente a phishing, isolam cada origem com Site Isolation e fornecem armazenamento de chaves suportado por hardware via o Trusted Platform Module no Windows e o Secure Enclave no macOS/iOS. Para programadores que constroem ferramentas de transferência encriptada de ficheiros, isto significa que a encriptação AES-256-GCM, a derivação de chaves PBKDF2 e a autenticação FIDO2 estão disponíveis sem necessidade de biblioteca externa. Aqui está o que cada browser consegue realmente fazer em 2026.

Web Crypto API: a base comum

Os quatro browsers principais suportam a W3C Web Cryptography API com uma superfície quase idêntica. Os algoritmos principais são:

Simétrico: AES-GCM, AES-CBC, AES-CTR, AES-KW (128, 192, 256 bits)
Assimétrico: RSA-OAEP, RSA-PSS, RSASSA-PKCS1-v1_5 (até 4096 bits), ECDSA e ECDH (P-256, P-384, P-521)
Hashing: SHA-1, SHA-256, SHA-384, SHA-512
Derivação de chaves: PBKDF2, HKDF
MAC: HMAC

O que falta: ChaCha20-Poly1305 (sem suporte em nenhum browser), Argon2 (sem suporte em nenhum browser), Ed25519/X25519 (Safari 17+ e Firefox 129+ têm suporte, o Chrome está a incorporar). Para esses ainda são necessárias bibliotecas JavaScript ou WASM como libsodium.js ou @noble/curves.

O Chrome e o Edge partilham a mesma implementação criptográfica (BoringSSL via V8). O Firefox usa NSS. O Safari usa CoreCrypto, a biblioteca FIPS-validada da Apple. O desempenho varia: as iterações PBKDF2 do Firefox correm cerca de 20% mais devagar do que o Chrome em hardware equivalente; o AES-GCM do Safari com aceleração de hardware no Apple Silicon é cerca de 2x mais rápido do que o Chrome no mesmo Mac.

TLS 1.3 e Certificate Transparency

Todos os browsers principais usam por defeito TLS 1.3 em origens suportadas e recuam para 1.2 apenas em servidores legados. O Chrome removeu suporte a TLS 1.0 e 1.1 no Chrome 84 (julho de 2020). O Firefox removeu-os no Firefox 78. O Safari abandonou-os no macOS 11 / iOS 14.

A Certificate Transparency é aplicada: os certificados emitidos após abril de 2018 têm de aparecer em pelo menos dois registos CT ou o Chrome e o Safari rejeitam-nos. Isto detetou ataques ao estilo DigiNotar precocemente ao tornar a emissão incorreta de CA publicamente auditável. O Firefox da Mozilla começou a aplicar CT no Firefox 117 (2023).

A fixação de chaves públicas via cabeçalho HPKP foi descontinuada (o Chrome 79 removeu o suporte) porque permitia ataques de bloqueio. Os cabeçalhos Expect-CT serviam o mesmo propósito de monitorização e estão também a ser eliminados agora que o CT é obrigatório. As empresas que necessitam de fixação ainda a têm via fixação de raiz de confiança em configurações geridas (MDM no macOS, políticas do Chrome Enterprise).

Isolamento de origem e sandboxing

O Site Isolation do Chrome coloca cada origem no seu próprio processo do SO desde 2018 (desktop) e 2019 (Android). O Fission do Firefox consegue o mesmo desde o Firefox 94. O Safari usa o modelo por processo do WebKit. O que isto significa para a encriptação: um script malicioso de origem cruzada não consegue ler o seu ficheiro decifrado da memória de um separador irmão, porque o irmão vive num processo diferente com o seu próprio heap.

O Cross-Origin-Opener-Policy (COOP), o Cross-Origin-Embedder-Policy (COEP) e o Cross-Origin-Resource-Policy (CORP) permitem que as páginas optem por isolamento ainda mais rigoroso. Definir Cross-Origin-Opener-Policy: same-origin e Cross-Origin-Embedder-Policy: require-corp ativa o isolamento de origem cruzada, que por sua vez desbloqueia SharedArrayBuffer e temporizadores de alta resolução. Relevante para criptografia porque os ataques de temporização ao estilo Spectre contra implementações AES são atenuados quando o atacante não consegue abrir um SAB na sua origem.

WebAuthn e Passkeys para autenticação

O FIDO2 WebAuthn é suportado no Chrome 67+, Firefox 60+, Safari 14+ e Edge 18+. Permite que as aplicações autentiquem utilizadores via chaves de hardware (YubiKey, Titan), autenticadores de plataforma (Face ID, Windows Hello, biometria Android) ou passkeys sincronizados nos dispositivos do utilizador via iCloud Keychain, Google Password Manager ou 1Password.

Para uma aplicação de transferência de ficheiros, o WebAuthn substitui palavras-passe como fator que protege o acesso a uma ligação de partilha armazenada. Crucialmente, o WebAuthn é resistente a phishing: a assinatura está vinculada à origem, pelo que um domínio idêntico não consegue capturar credenciais. O Chrome e o Safari adotaram ambos fluxos com passkeys como padrão em 2023-2024, eliminando o requisito de chave física para a maioria dos usos de consumo.

Armazenamento de chaves suportado por hardware

No Windows, o chip TPM 2.0 (obrigatório no Windows 11) consegue armazenar chaves Web Crypto geradas como não extraíveis via a ponte Windows CNG. No macOS e iOS, o Secure Enclave guarda as chaves usadas para Face ID, Touch ID e passkeys. No Android, o Keystore suportado por StrongBox (hardware) ou TEE (Trusted Execution Environment) fornece proteção semelhante.

O que isto significa na prática: uma chave gerada como extractable: false via Web Crypto num portátil moderno pode residir no TPM ou Secure Enclave, não na memória principal. Mesmo um exploit completo do browser que despeje a memória JavaScript não revelará os bytes brutos da chave. Para ferramentas de transferência de ficheiros, isto é mais útil para chaves de destinatário de longa duração; as chaves AES efémeras por ficheiro não precisam desta proteção.

Content Security Policy como multiplicador de criptografia

A encriptação não tem valor se um script malicioso conseguir ler o texto simples antes de ser encriptado. Os cabeçalhos Content Security Policy permitem que um site declare quais os scripts autorizados a executar. Uma política rigorosa como:

Content-Security-Policy: default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-abc123';

bloqueia scripts inline e código de terceiros, não deixando superfície de ataque para payloads injetados que roubem informação criptográfica. Todos os browsers principais suportam CSP Nível 3. Para aplicações de transferência de ficheiros, combine CSP com Subresource Integrity (SRI) em qualquer script externo para garantir que mesmo o JS de terceiros permitido não foi adulterado.

File System Access e OPFS

A File System Access API (Chrome 86+, Edge 86+, Safari 15.2+ parcial via Origin Private File System) permite que as web apps leiam e escrevam ficheiros locais com permissão do utilizador. O Origin Private File System é particularmente relevante para encriptação: é um sistema de ficheiros privado por origem, gerido pelo browser, usado para preparar payloads encriptados grandes antes do carregamento sem carregar tudo na memória.

O Firefox foi mais lento a adotar o FSA mas suporta OPFS desde o Firefox 111. O Safari suporta OPFS globalmente mas tem comportamento mais restritivo na File System Access API mais ampla.

O que os browsers ainda não fazem bem

Algumas lacunas persistem:

Derivação de chaves Argon2 está ausente da Web Crypto. Use bibliotecas WASM para hashing de palavras-passe acima do PBKDF2.
ChaCha20-Poly1305 não está exposto. O AES-GCM cobre a maioria das necessidades, mas o ChaCha ajudaria em dispositivos sem AES-NI (ARM mais antigo).
Atestação de chaves para chaves suportadas por hardware é limitada. O WebAuthn fornece atestação; a Web Crypto API mais ampla não o faz.
AEAD em streaming ainda não faz parte da especificação. A encriptação de ficheiros grandes exige lógica de fragmentação ou WASM.
Algoritmos pós-quânticos (Kyber, Dilithium) ainda não estão no browser. O Google incorporou o Kyber nos handshakes TLS (Chrome 116+) mas a criptografia pós-quântica exposta a JavaScript ainda é território de biblioteca.

O que usar hoje para transferência de ficheiros

Uma solução de transferência de ficheiros baseada em browser credível em 2026:

AES-256-GCM via crypto.subtle.encrypt para o conteúdo dos ficheiros
PBKDF2-SHA-256 com 600 000 iterações para chaves derivadas de palavras-passe
crypto.getRandomValues() para salts e nonces (nunca Math.random)
Fragmentos de URL (#chave=...) para passar chaves do lado do cliente sem exposição ao servidor
HTTPS com TLS 1.3 no mínimo, HSTS ativado, COOP/COEP para isolamento
CSP strict-dynamic, sem scripts inline
Passkeys WebAuthn para qualquer funcionalidade de conta armazenada
OPFS para preparação de ficheiros grandes no Chrome/Edge/Safari 16+

O HexaTransfer executa essencialmente esta solução. Também o fazem o SwissTransfer, Tresorit Send, Cryptpad e Proton Drive Share. Os primitivos são maduros e consistentes entre browsers.

Testar em todos os browsers

Teste sempre nos quatro. Erros reais: o Firefox lança OperationError em inputs PBKDF2 que o Chrome aceita silenciosamente. O FileReader do Safari é mais lento em ficheiros acima de 2 GB. As escritas OPFS do Chrome são fragmentadas acima de 4 GB em algumas versões. Os pedidos de verificação de utilizador WebAuthn diferem significativamente (Face ID vs Touch ID vs Windows Hello vs biometria Android). Use BrowserStack, Sauce Labs ou uma matriz local de dispositivos físicos para testes antes do lançamento.

Os browsers tornaram-se silenciosamente uma das plataformas criptográficas mais completas disponíveis. Os mesmos primitivos baseados em normas que alimentam aplicações bancárias, gestores de palavras-passe e clientes de mensagens estão a uma chamada JavaScript de distância para qualquer pessoa que construa ferramentas de transferência encriptada de ficheiros.

Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.