O armazenamento criptografado separa os bytes do arquivo da capacidade de descriptografar, mas destinatários, metadados e cópias locais continuam no modelo de ameaças.
Um anexo criptografado de ponta a ponta pode ser armazenado em um servidor sem lhe fornecer o arquivo em claro. Um projeto comum criptografa o arquivo no dispositivo do remetente com uma nova chave de conteúdo, envia o texto cifrado e entrega a chave aos destinatários pretendidos dentro de uma mensagem criptografada e autenticada.
Essa separação é útil, mas “armazenamento de conhecimento zero” não é uma especificação completa. Ainda é preciso perguntar como são tratados chaves, referências a arquivos, nomes, controles de acesso e cópias baixadas.
O ciclo de vida do anexo
- Preparar o arquivo. O remetente seleciona uma foto, vídeo ou documento. Remover metadados ou transcodificar é uma etapa separada; a criptografia sozinha não elimina EXIF nem propriedades de documentos.
- Criar o material criptográfico. Uma implementação segura gera o material de chave e nonce necessário conforme o esquema escolhido.
- Criptografar antes do envio. O serviço de armazenamento recebe bytes criptografados, não o conteúdo original.
- Entregar uma referência autenticada. A mensagem criptografada da conversa transporta as informações necessárias aos destinatários, como um localizador do arquivo, a chave de descriptografia e os metadados de integridade relevantes.
- Buscar e verificar. O cliente destinatário busca o objeto de dados e verifica a autenticação antes de tratar o resultado como conteúdo válido.
- Gerenciar cópias locais. Exibir, exportar, editar ou salvar na galeria pode criar cópias fora do limite original do armazenamento criptografado.
A chave pode passar pela infraestrutura do mesmo provedor em um envelope criptografado. Chamar isso de “fora de banda” pode induzir a erro: há uma separação lógica do armazenamento do objeto, não necessariamente entrega por um canal de comunicação independente.
O que a criptografia autenticada acrescenta
Um esquema de criptografia autenticada protege a confidencialidade e detecta alterações não autorizadas dentro de seu escopo autenticado. A especificação GCM do NIST define uma dessas construções e seus requisitos. Tratar corretamente chaves e nonces e conferir o resultado da autenticação é essencial; o nome de um algoritmo reconhecido não torna toda implementação segura.
O aplicativo também precisa vincular o arquivo à mensagem e à conversa corretas. Um objeto criptografado válido não prova, por si só, que pertence àquela conversa específica. Identificadores de arquivos, tamanho esperado, ordem dos blocos e metadados dos anexos precisam de um projeto autenticado adequado.
O que o serviço de armazenamento ainda pode descobrir
| Informação | Só a criptografia do conteúdo a esconde? |
|---|---|
| Bytes originais do arquivo | Esse é seu objetivo perante quem não tem a chave |
| Tamanho criptografado aproximado | Geralmente não |
| Horários de envio e download | Geralmente não |
| Qual conta solicita um arquivo | Depende do projeto de roteamento e controle de acesso |
| Nome do arquivo e legenda | Somente se o protocolo também os proteger |
| Uma cópia salva pelo destinatário | Não; o destinatário já tem acesso ao conteúdo em claro |
Controles de acesso continuam importantes mesmo quando os objetos estão criptografados. Podem limitar downloads indesejados, abusos e exposição de identificadores. Criptografia não substitui autorização, políticas de retenção ou disponibilidade.
Arquivos grandes exigem mais que um slogan
Um projeto para arquivos grandes pode transmitir dados em fluxo ou dividi-los em blocos autenticados. Isso pode reduzir o uso de memória, mas a numeração dos blocos, o comprimento final, as novas tentativas e o tratamento de truncamentos precisam ser definidos. Não invente números de desempenho nem afirme que colocar um arquivo em uma mensagem necessariamente causa “inchaço do estado do ratchet”; esses resultados dependem da implementação.
Um teste útil inclui um arquivo válido, um byte alterado, um download truncado, um bloco reordenado e uma tentativa de obtenção não autorizada. Execute esses testes somente em um ambiente de teste autorizado, com arquivos não sensíveis. Registre se o cliente rejeita dados inválidos antes de abri-los.
O que a Livara documenta
A página de segurança da Livara descreve criptografia antes do envio, uma chave aleatória por arquivo transportada dentro da sessão protegida e proteção de nomes de arquivos e legendas em conversas com E2EE ativo, incluindo grupos privados compatíveis. Grupos antigos incompatíveis estão explicitamente fora dessa cobertura. Ela distingue conversas protegidas de canais públicos de transmissão. São declarações documentadas do produto, não uma nova auditoria da implementação feita neste artigo.
O modelo de ameaças também reconhece que um destinatário ou dispositivo comprometido pode expor conteúdo legível. Portanto, o armazenamento criptografado não pode prometer que uma imagem desapareça de todos os dispositivos quando sua mensagem for excluída da conversa.
Perguntas antes de compartilhar arquivos sensíveis
Verifique se o tipo de conversa oferece E2EE, se todos os destinatários pretendidos são confiáveis e se o próprio arquivo contém metadados identificadores. Revise separadamente o salvamento automático na galeria e o backup de fotos na nuvem. Para documentos, considere remover comentários, histórico de revisões ou propriedades incorporadas antes do envio.
Por fim, entenda a exclusão e a recuperação. Remover um objeto do servidor pode impedir um download futuro, mas não recolhe a cópia que o destinatário já possui. Perder a chave necessária pode tornar ilegível um arquivo criptografado restante. Um bom projeto de anexos explica claramente os dois resultados.
