constant-time-testing

Visão geral da skill constant-time-testing

constant-time-testing é uma skill prática para auditar código criptográfico em busca de side channels de timing. Use a skill constant-time-testing quando você precisar verificar se branches dependentes de segredo, padrões de acesso à memória ou comportamentos microarquiteturais podem vazar chaves, nonces ou outros valores sensíveis.

Quem deve usar a constant-time-testing

Essa skill é mais indicada para auditors de segurança, engenheiros de criptografia e revisores de criptografia em nível de implementação. Ela é especialmente útil quando você já tem código, um test harness ou um hot path suspeito e precisa de um guia focado de constant-time-testing, em vez de uma checklist genérica de secure coding.

Qual problema ela resolve

A tarefa real não é “entender timing attacks na teoria”, e sim “descobrir se este código se comporta de forma diferente quando os segredos mudam”. A constant-time-testing ajuda a transformar essa pergunta em um workflow de revisão repetível: identificar entradas sensíveis, inspecionar os caminhos de código que elas influenciam e desenhar testes que possam expor vazamentos.

O que a torna útil

O principal valor está na especificidade. Uma boa skill de constant-time-testing deve direcionar você para:

• as regiões exatas do código que mais importam,
• os tipos de comparação e lookup que costumam vazar,
• e as evidências necessárias antes de decidir se um achado é real.

Como usar a skill constant-time-testing

Instale e abra os arquivos de origem

Para instalar constant-time-testing, adicione a skill de trailofbits/skills e leia primeiro SKILL.md. Se você estiver usando isso em um fluxo de agente, inspecione também os arquivos adjacentes do repositório que definem comportamento ou convenções antes de escrever seu prompt.

Comece com a forma certa de entrada

A skill funciona melhor quando você fornece um alvo concreto, e não uma solicitação vaga. Boas entradas incluem:

• o repositório ou o caminho do arquivo a revisar,
• os valores secretos ou chamadas de API que precisam permanecer ocultos,
• o threat model, como atacante local, observador remoto de timing ou ruído de benchmark,
• e a linguagem ou plataforma, já que C, Rust, assembly e código de alto nível vazam de formas diferentes.

Um prompt forte se parece com: “Use constant-time-testing em src/crypto.rs para verificar se verify_tag() faz branch com base em bytes secretos. Assuma um atacante remoto e reporte pontos prováveis de vazamento, ideias de teste e falsos positivos.”

Workflow de revisão sugerido

Um padrão prático de uso da constant-time-testing é:

1. Identificar segredos e todos os caminhos de código que eles influenciam.
2. Procurar branches, early returns, table lookups e primitivas de tempo variável.
3. Testar se o comportamento muda com entradas dependentes de segredo.
4. Separar vazamento real de ruído do compilador, do runtime ou da medição.
5. Reportar achados com as entradas exatas, os locais de código e o nível de confiança.

Leia primeiro para obter melhores resultados

Priorize SKILL.md e, depois, qualquer exemplo do repositório com checks de constant-time, scripts de medição ou notas de política. Se o repositório tiver múltiplos alvos de implementação, leia primeiro o mais próximo da sua stack de produção para que o guia de constant-time-testing permaneça alinhado ao seu ambiente.

FAQ da skill constant-time-testing

A constant-time-testing serve só para bibliotecas de criptografia?

Não. Ela serve para qualquer código em que timing dependente de segredo possa importar, incluindo checagens de autenticação, comparação de chaves, parsing de formatos que carregam segredos e lógica de protocolo. O caso de uso de constant-time-testing para Security Audit é mais amplo do que criptografia pura.

Preciso de um ambiente de benchmark antes de usar?

Nem sempre. Você pode começar com revisão estática e testes direcionados, e depois adicionar medições de timing se o caminho de código parecer suspeito. Em muitas auditorias, a primeira etapa é reduzir onde o vazamento pode existir.

Em que isso difere de um prompt normal?

Um prompt normal muitas vezes pede uma explicação genérica sobre timing attacks. constant-time-testing é mais acionável: foi feita para conduzir a revisão de uma base de código específica, de um segredo específico e de um threat model específico, o que normalmente gera uma saída de auditoria melhor.

Quando eu não devo usar?

Não confie nisso se você precisa de infraestrutura completa de análise dinâmica, verificação formal ou certificação específica de hardware. Ela é mais útil como um guia focado de revisão e testes, não como substituto de métodos de assurance mais profundos.

Como melhorar a skill constant-time-testing

Dê à skill os segredos e invariantes

O maior ganho de qualidade vem de nomear o que precisa continuar secreto e o que não pode mudar. Diga ao modelo quais valores são sensíveis, quais operações podem variar e quais caminhos de código são críticos para a segurança. Isso torna a skill constant-time-testing muito mais precisa.

Compartilhe os locais de código e os padrões suspeitos

Se você já suspeita de uma função, branch ou table lookup, aponte isso diretamente. Exemplo: “Inspecione verify(), ct_eq() e o lookup da S-box em src/aes.c.” Isso reduz suposições e ajuda a resposta a focar nos caminhos de vazamento de maior risco.

Peça evidências, não só julgamento

Boas respostas costumam incluir um plano de teste concreto: pares de entrada para comparar, onde instrumentar, o que conta como vazamento e como interpretar medições ruidosas. Peça esses artefatos explicitamente para que a resposta vá além de “parece constant-time” ou “não é constant-time”.

Itere depois da primeira passada

Use o primeiro resultado para refinar o escopo. Se ele sinalizar um branch, peça uma verificação de uso de constant-time-testing mais estreita só naquela função; se parecer limpo, peça análise de helpers adjacentes, efeitos do compilador ou comportamento específico da plataforma que ainda possa vazar.