Recuperar a identidade criptográfica, entrar novamente na conta e recuperar o histórico de conversas são três tarefas diferentes. Segundo a documentação de segurança do Livara, o formato v7 é usado para recuperar a identidade criptográfica; o próprio formato não recupera o histórico de conversas.
Essa arquitetura também não deve ser descrita como “sem nenhum backup na nuvem”. O documento atual afirma que o material de identidade é criptografado no dispositivo e depois enviado como backup criptografado. A diferença importante é entre armazenar uma chave legível no servidor e armazenar uma cópia criptografada que exige uma chave de recuperação para ser aberta.
Três portas que não usam a mesma chave
| Operação | Objetivo | Por que não basta? |
|---|---|---|
| Login na conta | Comprovar o direito de acesso à conta do serviço | Não fornece necessariamente a chave para descriptografar mensagens anteriores |
| Recuperação de identidade | Recuperar o acesso ao material de identidade criptográfica | Por si só, não comprova a existência nem a recuperação de todas as mensagens |
| Recuperação do histórico | Restaurar as mensagens e os anexos necessários | Além da chave, exige os próprios dados e um método de recuperação compatível |
Essa distinção evita um erro caro: apagar o telefone antigo acreditando que saber a senha de login basta para restaurar todas as conversas.
O que exatamente diz a documentação v7?
A página de segurança do Livara explica que as chaves P-256 de acordo de chaves e assinatura, assim como a semente ML-KEM, são criptografadas no dispositivo sob uma chave de recuperação aleatória de 256 bits. Na descrição do formato v7, o conjunto de algoritmos, a época da identidade e a geração também são autenticados. Essa é uma documentação do fabricante e não constitui, por si só, uma auditoria independente da implementação.
O modelo de ameaças do Livara considera a frase de recuperação necessária para abrir o backup de chaves. Não se deve deduzir dessa descrição o algoritmo exato de conversão da frase em chave nem a reconstrução direta de todas as chaves. Os detalhes práticos devem ser conferidos com a versão do aplicativo e o guia dessa mesma versão.
Por que uma função de derivação não torna forte uma frase fraca?
O comprimento da saída de uma função não é a mesma coisa que a imprevisibilidade da entrada. O RFC 5869 afirma expressamente que o HKDF concentra a entropia existente, mas não a aumenta. Portanto, não se pode afirmar que qualquer frase escolhida livremente adquire automaticamente segurança completa de 256 bits ao passar pelo HKDF.
Não encurte, reescreva nem substitua por uma sentença previsível, por conta própria, a frase gerada no fluxo oficial do aplicativo. Não a envie a nenhuma pessoa, bot de suporte ou formulário desconhecido.
Antes de trocar ou apagar o telefone
- Confirme no aplicativo o que foi incluído no backup: identidade, histórico ou ambos por métodos separados.
- Guarde a frase de recuperação em um local seguro, independente desse telefone; considere o acesso de outras pessoas um risco grave.
- Leia o guia de recuperação da versão atual. A simples mensagem “Login realizado com sucesso” não significa recuperação completa.
- Se houver um método compatível para testar a recuperação, experimente-o primeiro com dados não sensíveis e sem apagar a única cópia existente.
- Após a transferência, confira as conversas e os arquivos necessários; só então decida se vai desativar o dispositivo antigo.
E se eu não tiver a frase de recuperação?
Se ainda tiver um dispositivo autorizado, verifique apenas os caminhos oficiais disponíveis no próprio aplicativo; não presuma que é possível criar um novo backup sem conferir a versão. Se o dispositivo e a frase foram perdidos, a documentação do Livara não promete recuperar a chave. Não trate nenhum serviço de “descriptografia garantida” como uma forma de superar esse limite.
Comece o plano de transferência da conta perguntando “Quais dados serão restaurados, com qual chave e de qual backup?”, e não supondo que entrar novamente significa recuperar todas as conversas.
