Um benchmark precisa de um aparelho, uma carga de trabalho, um método e uma estimativa de incerteza — não só de um número que pareça rápido.
Não existe um percentual universal de consumo de bateria do ML-KEM-768 no Android que possa ser justificado. O custo depende da implementação, do celular, do estabelecimento das sessões, da frequência de renovação das chaves e do comportamento da rede. Um benchmark criptográfico rápido em um computador de mesa não determina a duração da bateria de um aplicativo completo de mensagens para celular.
Este artigo explica o que pode ser calculado a partir do padrão e o que precisa ser medido. Não foi realizado nenhum benchmark de bateria do Livara no Android para este artigo. O procedimento abaixo é um plano de teste, não uma alegação de resultado obtido.
O que o padrão nos informa
O ML-KEM é um mecanismo de encapsulamento de chaves: ele ajuda a estabelecer um segredo compartilhado que um protocolo pode usar na criptografia simétrica. No FIPS 203, o ML-KEM-768 tem uma chave de encapsulamento de 1184 bytes e um texto cifrado de 1088 bytes. Juntos, esses dois objetos totalizam 2272 bytes.
Esse total não é o tamanho completo da negociação de uma sessão de mensagens, nem necessariamente seu custo adicional de rede. Certificados, assinaturas, material de chaves clássico, enquadramento, codificação, chaves em cache e retransmissões podem alterar a quantidade de bytes efetivamente enviados. O “768” identifica um conjunto de parâmetros, não um segredo compartilhado de 768 bits; esse conjunto tem como alvo a categoria de segurança 3 do NIST.
| Grandeza | Definida pelo algoritmo ou medida? |
|---|---|
| Tamanhos da chave de encapsulamento e do texto cifrado | Definidos pelo conjunto de parâmetros ML-KEM selecionado |
| Tempo de geração de chaves, encapsulamento e desencapsulamento | Medir na implementação e no aparelho reais |
| Bytes do estabelecimento completo da sessão | Medir o protocolo, incluindo enquadramento e novas tentativas |
| Latência de envio de ponta a ponta | Medir o aplicativo e a rede em conjunto |
| Energia por carga de trabalho | Medir em um experimento controlado no nível do aparelho |
O custo ocorre apenas uma vez por sessão?
Não necessariamente. Um protocolo pode usar um KEM no estabelecimento inicial e novamente nas atualizações periódicas de chaves pós-quânticas. Mudanças na composição do grupo, novos aparelhos, sessões com falha e recuperação podem gerar mais trabalho. A unidade correta é o evento do protocolo, não a suposição de que toda conversa executa exatamente uma operação KEM.
A arquitetura LVR1 publicada do Livara descreve épocas periódicas de ML-KEM junto das etapas comuns das cadeias de mensagens. Portanto, um benchmark útil deve abranger tanto a troca de mensagens em regime estável quanto os eventos de renovação de chaves. Ele não deve afirmar que o trabalho pós-quântico nunca se repete.
A contagem de bytes de um texto cifrado armazenado também diz pouco sobre energia por si só. Um pacote extra pode afetar o comportamento do rádio de forma diferente de alguns bytes a mais em uma transferência já ativa.
Um plano reproduzível de medição no Android
1. Registre o ambiente
Anote o modelo do celular, a compilação do Android, a versão do aplicativo, a versão da biblioteca criptográfica, o modo de compilação, o estado da bateria e o estado térmico. Registre o tipo de rede e as condições do sinal. Não publique dados privados de contas nem o conteúdo dos pacotes em um relatório de benchmark.
2. Separe os testes de primitivas dos testes do aplicativo
Um teste de primitiva criptográfica mede isoladamente a geração de chaves, o encapsulamento ou o desencapsulamento. Um teste do aplicativo completo mede a criação de uma sessão, o envio de mensagens e a recuperação após uma interrupção de conexão. Apresente ambos, se estiverem disponíveis; não classifique um como se fosse o outro.
Faça testes repetidos e informe a dispersão, como a mediana e um percentil alto, em vez de selecionar a execução mais rápida. Aquecimento, compilação em tempo de execução e limitação de desempenho por temperatura podem afetar os resultados.
3. Defina cargas de trabalho realistas
- Estabeleça uma nova sessão de mensagens diretas.
- Envie uma quantidade fixa de mensagens de tamanho fixo em uma sessão já estabelecida.
- Teste uma transição documentada de renovação de chaves.
- Adicione ou remova um integrante de um grupo de teste, se houver suporte.
- Envie o mesmo anexo nas mesmas condições.
- Deixe o aplicativo ocioso por um intervalo fixo e meça separadamente o comportamento em segundo plano.
Use conteúdo sintético e contas de teste cujos usuários tenham dado consentimento. Um teste de grupo deve informar a quantidade de integrantes; um resultado com duas pessoas não pode ser extrapolado para um grupo grande sem explicitar isso.
4. Meça energia, além de tempo
O Power Profiler do Android Studio pode correlacionar a atividade com medições das linhas de alimentação em hardware compatível. O Google alerta que essas medições abrangem o aparelho inteiro, portanto outras atividades introduzem ruído. Os métodos de medição disponíveis variam conforme o aparelho.
Controle o brilho da tela, as tarefas em segundo plano, as condições da rede e a duração do teste. Repita a mesma carga de trabalho e compare condições equivalentes. Se o seu método não conseguir isolar a contribuição da criptografia, diga isso em vez de atribuir todo o consumo de bateria ao ML-KEM.
Ilustração de uma configuração de medição, não de resultados registrados de benchmark.
O que uma tabela de resultados útil deve conter?
| Campo do resultado | Exemplo de informação a registrar |
|---|---|
| Carga de trabalho | Nova sessão, troca de mensagens em sessão estabelecida ou renovação de chaves |
| Ambiente | Aparelho exato, compilação do aplicativo e rede |
| Testes | Quantidade e tratamento das execuções de aquecimento |
| Tempo | Mediana, variação e unidades |
| Tráfego | Bytes medidos e condições de retransmissão |
| Energia | Método, intervalo e incerteza |
| Limitações | O que o teste não isolou ou não abrangeu |
Deixe as células não medidas em branco ou marque-as como “não medido”. Um gráfico de barras de energia ilustrativo com proporções relativas inventadas não é evidência.
E quanto a fotos e vídeos?
Anexos grandes geralmente usam criptografia simétrica, e não ML-KEM para cada bloco de conteúdo. O estabelecimento das chaves ainda pode afetar a preparação, enquanto o processamento do arquivo, o armazenamento, a transferência pela rede e a lógica de novas tentativas afetam a operação completa. A contribuição relativa precisa ser medida na carga de trabalho real; “nunca perceptível” não é uma afirmação universal bem fundamentada.
Perguntas frequentes
O ML-KEM-768 é sempre mais lento que o P-256?
Não há uma comparação universal válida para todas as bibliotecas e plataformas de hardware. Compare as mesmas operações nas mesmas condições e, depois, meça separadamente o protocolo híbrido completo.
Uma soma de verificação do APK valida resultados de desempenho?
Ela pode identificar o arquivo exato que foi testado quando comparada com uma referência confiável. Ela não valida o método de teste, a segurança da implementação nem a medição de energia.
Os usuários devem desativar a criptografia para economizar bateria?
Não abra mão de um requisito de segurança com base em uma alegação de desempenho sem comprovação. Primeiro identifique a origem real do consumo de bateria e use configurações ou atualizações compatíveis.
