Segurança na LangReply

O que ciframos, o que destruímos e o que honestamente não podemos garantir. Escrito sem jargão de marketing.

1. Cifragem em repouso

Os dados sensíveis (contas de utilizador, históricos de tradução, mensagens OTT, preferências) são cifrados em repouso com AES-256-GCM. A chave-mestra reside fora do repositório Git, num volume de acesso restrito (permissões 600, proprietário dedicado).

Cada registo sensível traz o seu próprio IV (nonce aleatório de 96 bits) e a sua etiqueta de autenticação GCM. Qualquer alteração do texto cifrado é detetada na decifragem (falha criptográfica, sem corrupção silenciosa).

Exceção documentada: o ficheiro languages.json (a lista pública dos idiomas suportados) está explicitamente excluído da cifragem: é um catálogo público, não um dado pessoal.

2. Apagamento irreversível (crypto-shredding)

Princípio

Cada conversa OTT, cada lote de mensagens sensíveis e cada conta de utilizador têm a sua própria DEK (Data Encryption Key) — uma chave AES-256 única, gerada aleatoriamente. Os dados são cifrados com essa DEK; a própria DEK é cifrada pela chave-mestra (KEK).

Para apagar os dados de forma irreversível, destruímos a DEK. Os bytes cifrados podem permanecer na base de dados ou em disco: sem a chave, são indistinguíveis de ruído aleatório.

Garantia matemática

Uma DEK AES-256 tem um espaço de 2256 valores possíveis — cerca de 1,16 × 1077. Recuperar por força bruta uma chave destruída é, no estado atual do conhecimento público em criptografia e da capacidade de cálculo disponível (incluindo a projeção pós-quântica com Grover, que reduz a 2128), inviável.

O que é realmente destruído

  • A DEK em RAM (colocação a zero imediata).
  • A DEK cifrada na base de dados (UPDATE ... SET encrypted_dek = NULL + VACUUM do Postgres quando aplicável).
  • As cópias na cache aplicacional.

3. Mensagens que desaparecem automaticamente

Qualquer conversa OTT pode ativar um temporizador de purga automática: passado esse prazo, as mensagens são destruídas por crypto-shredding da DEK da conversa.

Durações configuráveis

Na ausência de configuração, nenhuma duração predefinida se aplica: as mensagens são conservadas até serem apagadas manualmente.

O prazo começa quando a mensagem é lida pelo destinatário (predefinição) ou quando é enviada (opção). Um varredor do servidor corre a cada 10 minutos e purga o que expirou.

A alteração do prazo fica visível na conversa (mensagem de sistema com data e hora). Nem o remetente nem o destinatário podem «prolongar» uma mensagem já expirada: a chave foi destruída.

4. Purga extrema da conta

No portal do utilizador, o botão «Destruir todas as minhas mensagens» desencadeia a destruição imediata de todas as DEK associadas à sua conta: conversas OTT, histórico de tradução, rascunhos, anexos cifrados.

A operação é:

Uma purga da conta não elimina a conta em si (identificador, e-mail, preferências de faturação): para isso, use a eliminação completa da conta, que é uma ação distinta.

5. Isolamento por conta

Cada conta tem a sua própria DEK. O comprometimento de uma DEK expõe apenas os dados dessa conta, não os das outras. A chave-mestra (KEK) é necessária para decifrar as DEK, mas por si só não permite ler uma conta cuja DEK já não está na base de dados.

Os pedidos à API são delimitados por account_id. Nenhuma rota aceita o identificador de uma conta como parâmetro livre sem verificar a pertença da sessão.

6. Motor de tradução auto-hospedado

A tradução principal usa o NLLB-200 1.3B (202 idiomas) alojado no nosso próprio servidor, num microsserviço interno, não exposto à Internet. O conteúdo não sai da nossa infraestrutura para ser traduzido.

Recurso alternativo: em caso de indisponibilidade, um mecanismo automático pode recorrer apenas ao Claude (Anthropic). Pode ser desativado por conta em utilizações sensíveis; quando é acionado, o conteúdo é transmitido à Anthropic e assinalamo-lo na resposta da API.

O recurso MyMemory foi retirado a 28 de julho de 2026: transmitia o conteúdo em claro dentro do URL, sem contrato de subcontratação. Não existe um terceiro recurso: se nenhum motor estiver disponível, a tradução falha em vez de ser entregue a um terceiro sem contrato.

7. Autenticação

Palavras-passe com hash scrypt (N=16384, r=8, p=1). Sessões através de cookie HttpOnly assinado com HMAC. 2FA disponível: TOTP (Google Authenticator, Aegis, 1Password) e OTP por SMS (Twilio, mensagens no idioma do destinatário).

Limitação de débito nos endpoints de autenticação (429 após tentativas repetidas). Nenhuma palavra-passe é enviada por e-mail; as reposições usam uma ligação de utilização única.

8. Cópias de segurança

Cópias cifradas diárias do volume de dados. Retenção: 14 dias deslizantes, seguidos de eliminação.

Uma cópia cifrada fora do local (AES-256) é conservada no GitHub e na Backblaze (Estados Unidos). As mensagens OTT/SMS e as respetivas chaves estão excluídas e nunca saem da União Europeia.

9. Os seus direitos (RGPD / Lei 25 / CCPA)

Direito de acesso, retificação, apagamento, portabilidade e oposição. Os pedidos são feitos por e-mail para privacy@langreply.com e tratados em 30 dias. O apagamento usa a purga por crypto-shredding descrita acima.

10. Certificações — com honestidade

Hoje não temos certificação SOC 2, ISO 27001 nem HIPAA. Não afirmaremos o contrário enquanto não for verdade. As medidas aqui descritas estão realmente implementadas; as auditorias externas correspondentes ainda não.

11. O que honestamente não garantimos

Preferimos dizer a verdade a vender uma ilusão. Eis o que o crypto-shredding não faz:

  • Cópias de segurança: as nossas cópias excluem as tabelas de mensagens e de chaves — uma reposição não pode reexpor uma mensagem destruída. Contrapartida assumida: se a base de dados se perder, o histórico OTT/SMS não é recuperável.
  • Capturas de ecrã do destinatário: se enviar uma mensagem que desaparece, essa pessoa pode fotografar o ecrã com outro aparelho. Nenhum software no mundo o impede. O Signal também não.
  • WAL, registos, réplicas: o Postgres escreve registos de transações (WAL). Um byte cifrado pode ter passado por lá antes de ser apagado. Esses registos rodam, mas não instantaneamente.
  • SSD e wear-levelling: os discos SSD distribuem fisicamente as escritas. Um DELETE lógico não sobrescreve necessariamente o setor físico. É precisamente por isso que o crypto-shredding é mais fiável do que um apagamento físico — mas o byte cifrado pode subsistir fisicamente durante algum tempo. Sem a chave, permanece ilegível.
  • Metadados de auditoria: conservamos metadados mínimos (data/hora de uma purga, IP) para auditoria e combate ao abuso. Não contêm o conteúdo destruído.
  • Cifragem ponta a ponta: a mensageria OTT é cifrada em repouso do lado do servidor, mas não é E2EE no sentido do Signal (em que nem o servidor consegue ler). Tecnicamente, a LangReply consegue decifrar uma mensagem enquanto a sua DEK existir. Não o fazemos — mas não podemos afirmar o contrário.

12. Reportar um problema de segurança

Divulgação coordenada para security@langreply.com com o assunto [SECURITY]. Acusamos a receção em 72 h e publicamos uma correção ou mitigação num prazo razoável consoante a gravidade. Ainda não existe um programa formal de bug bounty; mencionamos quem o desejar.

Última atualização: 6 de agosto de 2026.