constant-time-analysis

Visão geral da skill constant-time-analysis

A skill constant-time-analysis é uma skill de auditoria de segurança para encontrar riscos de side-channel por tempo em código de criptografia antes que virem bugs exploráveis. Ela é ideal para engenheiros, revisores e agentes de IA que precisam verificar se operações, branches, comparações ou instruções em runtime dependentes de segredo podem vazar chaves, tokens ou outros valores sensíveis.

A tarefa principal aqui não é “entender teoria de criptografia”, e sim “identificar onde este código deixa de ser constant-time”. Por isso, a skill constant-time-analysis é mais útil em revisões de implementação, checagens de segurança pré-merge e triagem de incidentes, quando alguém quer saber se uma função está segura contra timing attacks.

O que a diferencia de um prompt genérico é que ela foi construída em torno de saída compilada e caminhos de análise específicos por linguagem, e não apenas de varredura do código-fonte. Isso importa porque problemas de constant-time muitas vezes aparecem em assembly, bytecode ou instruções de VM, mesmo quando o source parece inofensivo.

Melhor encaixe da constant-time-analysis para auditoria de segurança

Use esta skill quando estiver revisando código que:

• lida com segredos, autenticação ou primitivas criptográficas
• usa divisão, módulo, comparação ou branching em valores derivados de segredo
• precisa de validação nos artefatos compilados, e não só da intenção no source
• tem como alvo C, C++, Go, Rust, Swift, Java, Kotlin, PHP, JavaScript, TypeScript, Python ou Ruby

O que ela detecta e o que ela não detecta

A constant-time-analysis é forte para padrões de vazamento por tempo, como divisão de tempo variável, branches dependentes de segredo e comparações inseguras. Ela é mais fraca para erros mais amplos de design criptográfico, falhas de protocolo ou vazamentos causados por rede, cache ou ruído do ambiente, a menos que esses problemas apareçam no caminho de código analisado.

Por que as pessoas instalam esta skill

Instale esta skill quando você quiser um fluxo de revisão repetível que consiga sinalizar risco de timing mais cedo do que uma leitura manual rápida. Se você só precisa de uma opinião pontual sobre um único trecho, um prompt comum pode bastar; se precisa de comportamento consistente de revisão de segurança, a skill adiciona estrutura.

Como usar a skill constant-time-analysis

Instale e acione do jeito certo

Use o caminho de instalação da constant-time-analysis no seu gerenciador de skills e execute-a em um contexto que inclua a linguagem alvo e a função ou arquivo sensível. Um bom prompt de acionamento nomeia o objetivo criptográfico, as entradas secretas e a linguagem/runtime, para a skill escolher o caminho de análise correto.

Exemplo de acionamento:

• “Revise src/sign.rs para risco de constant-time. A entrada secreta é o escalar da chave privada; foque em divisão, branches e comparações.”
• “Execute constant-time-analysis nesta função PHP de verificação de senha e diga se há probabilidade de vazamento de tempo em nível de opcode.”

Forneça a entrada no formato certo

A skill funciona melhor quando você informa:

• o arquivo ou função a inspecionar
• quais valores são secretos
• qual comportamento observável pelo atacante importa
• a linguagem e a versão do runtime, se souber

Entrada melhor:

• “Audite verifyToken() em TypeScript. Os bytes do token são secretos; compare com o HMAC armazenado; verifique Div, Mod e comparações com early exit.”
• “Analise esta rotina reduce() em Rust para divisão dependente de segredo em x86_64 e arm64.”

Leia estes arquivos primeiro

Para decisão de instalação e fluxo de trabalho, comece por:

• SKILL.md para triggers, escopo e seleção de linguagem
• README.md para linguagens suportadas e objetivos de saída
• references/compiled.md para C/C++, Go e Rust
• references/javascript.md, references/python.md, references/php.md, references/ruby.md, references/swift.md, references/kotlin.md para regras específicas de VM

Se você for ler só um arquivo de referência, escolha o que corresponde ao caminho do runtime, e não apenas ao rótulo da linguagem de origem.

Use um fluxo de revisão, não uma única passada

Um fluxo prático de uso da constant-time-analysis é:

1. identificar a função que carrega o segredo
2. executar o guia correto da linguagem
3. inspecionar qualquer divisão, módulo, comparação, branch ou chamada auxiliar suspeita
4. rodar de novo depois de refatorações ou mudanças no compilador/runtime
5. pedir saída amigável para CI, se quiser validar o resultado de forma automática

Isso importa porque uma correção no source ainda pode ser compilada em instruções inseguras, especialmente em linguagens compiladas.

Perguntas frequentes sobre a skill constant-time-analysis

A constant-time-analysis é só para criptografia?

Não. Ela serve para qualquer código em que diferenças de tempo sobre dados secretos sejam relevantes, mas isso normalmente inclui crypto, autenticação, tratamento de chaves e verificação de tokens. Se o código processa apenas dados públicos, a skill provavelmente é desnecessária.

Preciso entender assembly ou bytecode?

Não para começar. A skill é útil justamente porque aponta para o artefato de runtime certo e para a referência específica da linguagem. Você não precisa ler todas as instruções, mas precisa saber qual função ou arquivo é sensível do ponto de vista de segurança.

A constant-time-analysis é melhor do que um prompt normal?

Sim, quando você precisa de um comportamento repetível de revisão de segurança. Um prompt comum pode identificar riscos óbvios, mas a constant-time-analysis é mais útil para trabalho em repositórios porque é organizada por seleção de linguagem, saída compilada e padrões concretos de vazamento.

Quando não devo usar?

Não use para lógica de negócio comum, UI ou transformações sobre dados públicos. Também vale pular quando a biblioteca já garante comportamento constant-time e você só quer perguntar sobre o uso da API em alto nível, sem lógica customizada dependente de segredo.

Como melhorar a skill constant-time-analysis

Foque no segredo e no modelo de atacante

Os melhores resultados da constant-time-analysis vêm de dizer exatamente o que precisa continuar secreto e o que o atacante pode observar. Informe se o risco é timing remoto, timing local do processo ou inspeção do código compilado. Sem isso, a skill pode supervalorizar branches inofensivos ou deixar passar a restrição real.

Envie o menor caminho de código arriscado possível

Passe a função que realmente toca dados secretos, não o repositório inteiro. Se o caminho incluir helpers, traga-os apenas quando influenciam branching, aritmética ou comparações. Isso reduz ruído e facilita agir sobre a saída.

Peça evidência específica da linguagem

Para melhores resultados, peça que a skill verifique o artefato de runtime relevante:

• assembly para C/C++, Go, Rust
• bytecode para JavaScript, TypeScript, Python, Ruby, PHP
• comportamento da JVM para Kotlin

Isso melhora o uso da constant-time-analysis porque vazamentos de tempo muitas vezes surgem abaixo do nível do source.

Execute novamente após cada correção

Um modo comum de falha é corrigir o código-fonte e assumir que o vazamento sumiu. Refaça o teste depois de mudar o algoritmo, as flags do compilador, o nível de otimização ou a versão do runtime. Para constant-time-analysis para auditoria de segurança, essa segunda passada costuma ser a etapa em que você confirma a postura real de segurança.