Agilidade criptográfica é a capacidade de migrar um protocolo de um conjunto criptográfico para outro sem perder um contrato de segurança claro. Em mensagens, isso significa mais do que adicionar o nome de um novo algoritmo. Clientes antigos, destinatários offline, mensagens armazenadas e dispositivos vinculados precisam se comportar de forma previsível durante a transição.
A RFC 7696 da IETF descreve a agilidade de algoritmos como um problema de migração que envolve identificadores, implementações e mudanças operacionais. Um número de versão ajuda a identificar o que está em uso; por si só, não torna a migração segura.
Três versões fáceis de confundir
Um mensageiro pode ter uma versão do aplicativo, uma versão do protocolo de comunicação e um identificador do conjunto criptográfico. Elas respondem a perguntas diferentes:
| Identificador | O que informa a quem avalia | O que não comprova |
|---|---|---|
| Versão do aplicativo | Qual compilação do software está instalada | Que todas as conversas usam o protocolo mais recente |
| Versão do protocolo | Qual formato de mensagem e quais regras de estado se aplicam | Que a implementação segue essas regras corretamente |
| Identificador do algoritmo ou conjunto | Quais componentes criptográficos foram selecionados | Que a negociação não pode sofrer downgrade |
As notas de versão devem explicitar essa relação. “Nova criptografia disponibilizada” é ambíguo se apenas conversas recém-criadas a utilizam ou se um cliente vinculado mais antigo provoca um retorno a uma opção anterior.
O que uma migração segura precisa especificar
Comece com um cenário concreto: Alice atualiza hoje; Bob permanece offline em um telefone mais antigo. Alice envia uma mensagem e depois adiciona um segundo dispositivo. O que cada dispositivo deve aceitar, armazenar e exibir?
Um projeto que possa ser analisado responde pelo menos a estas perguntas:
- Como cada lado descobre as versões suportadas pelo outro?
- A versão selecionada é autenticada como parte da sessão?
- O que acontece quando não há uma versão aceitável em comum?
- Um retransmissor malicioso pode remover uma capacidade e induzir um modo mais fraco?
- As mensagens antigas continuam legíveis e quais chaves antigas continuam necessárias?
- Restaurar um backup reativa um estado obsoleto do protocolo?
- Quando os algoritmos descontinuados serão desativados, em vez de apenas desaconselhados?
Uma falha visível costuma ser mais segura do que uma transição silenciosa para um modo que o usuário não pretendia usar. Mas o comportamento exato de falha e recuperação deve ser documentado para que as pessoas não contornem o problema mudando para um canal desprotegido.
Uma matriz prática de testes de atualização
Uma atualização de segurança exige mais do que uma conversa bem-sucedida entre duas instalações novas. Teste estes casos com dados não sensíveis:
| Teste | Evidência a registrar |
|---|---|
| Cliente novo para cliente antigo | Protocolo selecionado ou resultado claro de incompatibilidade |
| Destinatário offline durante a atualização | Comportamento de entrega e descriptografia após a reconexão |
| Retorno de um dispositivo vinculado antigo | Se ele pode ler, enviar ou forçar um modo inesperado |
| Grupo adiciona um membro incompatível | Política explícita do grupo e estado visível ao usuário |
| Backup restaurado após a descontinuação | Se o estado não suportado é rejeitado ou migrado |
| Metadados de versão adulterados | Falha de autenticação em vez de um downgrade despercebido |
Estes são critérios de avaliação, não alegações de que um produto específico passou nos testes. Guarde os identificadores das compilações e os resultados observados para distinguir uma regressão posterior de uma mudança na documentação.
Como interpretar os nomes dos protocolos da Livara
A Livara usa LVR1 para conversas diretas e LGS1 para grupos privados em sua documentação de segurança. Esses nomes distinguem responsabilidades; não devem ser interpretados como prova de padronização ou auditoria independente. A página também discute o comportamento de clientes ou grupos que não conseguem atender aos pré-requisitos do modo criptografado.
As próximas evidências úteis seriam uma especificação versionada, vetores de teste, regras de compatibilidade e resultados de análises ligados a uma versão específica. O Proof Lab deixa claro o escopo mais restrito de sua demonstração. Exercitar primitivas em um navegador não é o mesmo que testar todos os caminhos de migração no aplicativo.
O que os usuários devem fazer durante uma atualização de criptografia
Mantenha os clientes suportados atualizados, leia os avisos de segurança sobre compatibilidade de dispositivos e preste atenção a mudanças nos indicadores de identidade ou de estado da criptografia. Não suponha que um novo ícone do aplicativo significa que todos os grupos e backups antigos receberam uma nova proteção. Se o produto não consegue explicar quais dados tiveram sua proteção alterada, pergunte antes de compartilhar material sensível.
Uma boa agilidade criptográfica torna a mudança verificável. Ela identifica o que mudou, como as partes concordam com a mudança, o que pode dar errado e quando o mecanismo antigo deixa de ser aceito.
