Segurança

Como garantimos que não conseguimos ler os seus ficheiros

O EmptyFileVault é zero-knowledge por construção. A criptografia acontece no seu browser; o servidor só vê texto cifrado e metadata que foi ela própria encriptada. Esta página documenta como isso funciona, e do que protege — e do que não protege.

Primitivas

  • X25519 para troca de chaves (cada utilizador e cada grupo tem um keypair).
  • crypto_box_seal para wrapping anónimo de chaves de pasta e chaves privadas de grupo.
  • XChaCha20-Poly1305 secretstream para encriptação de ficheiros em streaming, em chunks de 1 MiB.
  • XSalsa20-Poly1305 secretbox para wrapping das DEKs por ficheiro com a chave da pasta.
  • Argon2id para derivar chaves a partir de passwords e mnemónicas de recuperação.

Todas as primitivas vêm do libsodium. O bundle do browser tem implementações funcionais de todas as primitivas listadas acima; não recorremos à WebCrypto standard quando o libsodium tem um equivalente melhor auditado.

O que o servidor vê

Quando crias um ficheiro, o servidor guarda:

  • Um UUID opaco de 16 bytes como chave do objeto no MinIO.
  • Texto cifrado (já encriptado pelo browser).
  • Um nome de ficheiro e metadata encriptados — encriptados com a chave da pasta.
  • Uma DEK wrapped e um header secretstream de 24 bytes.
  • Timestamps, o tamanho do texto cifrado em bytes e HMACs de integridade.

O nome em claro, o tipo MIME, o conteúdo do ficheiro e a chave de encriptação por ficheiro nunca estão nos nossos servidores em forma não encriptada.

Modelo de ameaça — do que está protegido

  • Compromisso passivo do servidor (apenas leitura).
  • Fuga total da base de dados.
  • Fuga total do bucket S3 / MinIO.
  • Um admin ou developer malicioso ou coagido.
  • MITM de rede (TLS + URLs assinados).

Modelo de ameaça — do que honestamente NÃO protege

  • Compromisso ativo do servidor a servir JavaScript malicioso. O maior risco residual de qualquer produto zero-knowledge no browser. Mitigado com CSP estrito e SRI nos assets. Um cliente desktop assinado está no roadmap.
  • Dispositivo do utilizador comprometido. Um keylogger ou malware na sua máquina vê a sua password.
  • A partilha viewer-only não é DRM. Depois de o seu browser decifrar um ficheiro, screenshots são fisicamente possíveis. Acrescentamos marcas de água forenses (visíveis + esteganográficas) e um viewer sem download; não fingimos que isso é igual a um leitor selado.
  • Forward secrecy na revogação. Remover uma concessão impede acesso futuro mediado pelo servidor, mas os bytes já descarregados por quem foi revogado continuam nas mãos dele.
  • Um novo membro de grupo consegue ler ficheiros partilhados anteriormente — por design, já que a chave de grupo é a mesma.

Chave de recuperação

No registo geramos uma chave de recuperação de 32 bytes e mostramo-la como uma mnemónica BIP39 de 24 palavras. Confirma palavras específicas antes de ativar para sabermos que a guardou. Se perder a password mas ainda tiver a mnemónica, pode re-encriptar a sua chave privada com uma nova password. Nunca vemos a chave de recuperação.

Se perder ambas, os ficheiros que partilhou com colaboradores podem ser re-concedidos do lado deles a uma conta nova. Ficheiros a que só você tinha acesso são irrecuperáveis — por design.

Prova ao vivo

Cifre alguma coisa agora — aqui no seu browser

Escreva um texto e uma palavra-passe. A cifragem acontece neste dispositivo, com a mesma biblioteca (libsodium) e o mesmo algoritmo (XChaCha20-Poly1305) que protegem os seus ficheiros. Abra o separador de Rede da consola e confirme: o texto em claro nunca sai daqui.

No seu dispositivo
O que chegaria aos nossos servidores

Bytes opacos. Sem a sua palavra-passe, isto é matematicamente inútil.

Decifrar de volta

Decifrado com sucesso, neste dispositivo:

100% local · libsodium · XChaCha20/XSalsa20-Poly1305 · Argon2id. Nada disto toca a rede.