constant-time-analysis

Aperçu du skill constant-time-analysis

constant-time-analysis est un skill d’audit de sécurité conçu pour repérer les risques de canaux auxiliaires temporels dans du code crypto avant qu’ils ne deviennent des bugs exploitables. Il est particulièrement adapté aux ingénieurs, reviewers et agents IA qui doivent vérifier si des calculs dépendants de secrets, des branches, des comparaisons ou des instructions à l’exécution peuvent fuiter des clés, des jetons ou d’autres valeurs sensibles.

L’objectif principal n’est pas de « comprendre la théorie cryptographique », mais de « repérer à quel endroit ce code cesse d’être constant-time ». Le skill constant-time-analysis est donc surtout utile pendant les revues d’implémentation, les contrôles de sécurité avant fusion et les phases de triage d’incident, quand il faut déterminer si une fonction est sûre face aux attaques par temporisation.

Ce qui le distingue d’un prompt générique, c’est qu’il s’appuie sur les artefacts compilés et sur des chemins d’analyse propres à chaque langage, pas seulement sur l’inspection du code source. C’est important, car les problèmes de constant-time apparaissent souvent dans l’assembly, le bytecode ou les instructions de machine virtuelle, même quand le source semble inoffensif.

Quand le skill constant-time-analysis est le plus adapté pour un audit de sécurité

Utilisez ce skill lorsque vous examinez du code qui :

• gère des secrets, de l’authentification ou des primitives cryptographiques
• utilise des divisions, des modulo, des comparaisons ou des branchements sur des valeurs dérivées d’un secret
• doit être validé sur des artefacts compilés, et pas seulement selon l’intention du source
• cible C, C++, Go, Rust, Swift, Java, Kotlin, PHP, JavaScript, TypeScript, Python ou Ruby

Ce qu’il détecte et ce qu’il manque

constant-time-analysis est performant pour les schémas de fuite temporelle comme les divisions à durée variable, les branches dépendantes d’un secret et les comparaisons non sûres. En revanche, il est moins adapté aux erreurs plus larges de conception cryptographique, aux défauts de protocole ou aux fuites dues au réseau, au cache ou au bruit environnemental, sauf si ces problèmes apparaissent dans le chemin de code analysé.

Pourquoi les utilisateurs l’installent

Installez ce skill si vous voulez un workflow de revue répétable, capable de signaler un risque temporel plus tôt qu’un simple survol manuel. Si vous avez seulement besoin d’un avis ponctuel sur un extrait de code, un prompt classique peut suffire ; si vous cherchez une revue de sécurité cohérente et réutilisable, le skill apporte une vraie structure.

Comment utiliser le skill constant-time-analysis

Installez-le et déclenchez-le correctement

Passez par le chemin d’installation constant-time-analysis de votre gestionnaire de skills, puis lancez-le dans un contexte qui inclut le langage cible et la fonction ou le fichier sensible. Un bon prompt de déclenchement mentionne l’objectif crypto, les entrées secrètes et le langage/runtime, afin que le skill choisisse le bon chemin d’analyse.

Exemple de déclenchement :

• “Review src/sign.rs for constant-time risk. Secret input is the private key scalar; focus on division, branches, and comparisons.”
• “Run constant-time-analysis on this PHP password-checking function and tell me whether any opcode-level timing leak is likely.”

Donnez-lui la bonne forme d’entrée

Le skill fonctionne mieux si vous fournissez :

• le fichier ou la fonction à inspecter
• quelles valeurs sont secrètes
• quel comportement observable par un attaquant compte
• la version du langage et du runtime cible, si vous la connaissez

Meilleure entrée :

• “Audit verifyToken() in TypeScript. Token bytes are secret; compare against stored HMAC; check for Div, Mod, and early-exit comparisons.”
• “Analyze this Rust reduce() routine for secret-dependent division across x86_64 and arm64.”

Commencez par ces fichiers

Pour les décisions d’installation et le workflow, commencez par :

• SKILL.md pour les déclencheurs, le périmètre et la sélection du langage
• README.md pour les langages pris en charge et les objectifs de sortie
• references/compiled.md pour C/C++, Go et Rust
• references/javascript.md, references/python.md, references/php.md, references/ruby.md, references/swift.md, references/kotlin.md pour les règles spécifiques aux VM

Si vous ne parcourez qu’un seul fichier de référence, choisissez celui qui correspond à votre chemin d’exécution plutôt qu’à l’étiquette du langage source.

Utilisez un workflow de revue, pas une passe unique

Un usage pratique du skill constant-time-analysis suit ce flux :

1. identifier la fonction qui manipule le secret
2. lancer le guide du langage approprié
3. inspecter les divisions, modulo, comparaisons, branches ou appels d’aide suspects
4. relancer après un refactoring ou un changement de compilateur/runtime
5. demander une sortie compatible CI si vous voulez une vérification automatisable

C’est important, car une correction dans le source peut malgré tout être compilée en instructions non sûres, surtout dans les langages compilés.

FAQ sur le skill constant-time-analysis

Le skill constant-time-analysis est-il réservé à la cryptographie ?

Non. Il sert pour tout code où les différences de temps d’exécution sur des données secrètes comptent, mais cela concerne le plus souvent la crypto, l’authentification, la gestion de clés et la vérification de jetons. Si le code ne traite que des données publiques, ce skill est probablement inutile.

Faut-il connaître l’assembly ou le bytecode ?

Pas pour commencer. Le skill est justement utile parce qu’il vous oriente vers le bon artefact d’exécution et la bonne référence propre au langage. Vous n’avez pas besoin de lire chaque instruction, mais vous devez savoir quelle fonction ou quel fichier est sensible du point de vue sécurité.

Le skill constant-time-analysis est-il meilleur qu’un prompt normal ?

Oui, lorsque vous avez besoin d’un comportement de revue de sécurité répétable. Un prompt classique peut repérer les risques évidents, mais constant-time-analysis est plus utile pour le travail sur dépôt parce qu’il s’organise autour du choix du langage, des artefacts compilés et de schémas de fuite concrets.

Quand ne faut-il pas l’utiliser ?

Ne l’utilisez pas pour la logique métier ordinaire, l’interface utilisateur ou les transformations sur des données publiques. Évitez-le aussi lorsque la bibliothèque garantit déjà un comportement constant-time et que vous ne posez qu’une question d’usage d’API de haut niveau sans logique personnalisée dépendante de secrets.

Comment améliorer le skill constant-time-analysis

Concentrez-vous sur le secret et le modèle d’attaquant

Les meilleurs résultats de constant-time-analysis viennent d’une description précise de ce qui doit rester secret et de ce que l’attaquant peut observer. Indiquez si le risque concerne une temporisation à distance, une temporisation locale du processus ou une inspection du code compilé. Sans cela, le skill peut surinterpréter des branches sans danger ou manquer la vraie contrainte.

Fournissez le plus petit chemin de code à risque

Donnez la fonction qui touche réellement les données secrètes, pas tout le dépôt. Si le chemin inclut des helpers, ne les incluez que s’ils influencent les branches, l’arithmétique ou les comparaisons. Cela réduit le bruit et rend le résultat plus exploitable.

Demandez des preuves propres au langage

Pour de meilleurs résultats, demandez au skill de vérifier l’artefact d’exécution pertinent :

• assembly pour C/C++, Go, Rust
• bytecode pour JavaScript, TypeScript, Python, Ruby, PHP
• comportement JVM pour Kotlin

Cela améliore l’usage de constant-time-analysis, parce que les fuites temporelles apparaissent souvent sous le niveau du source.

Relancez après chaque correction

Une erreur fréquente consiste à corriger le source puis à supposer que la fuite a disparu. Re-testez après un changement d’algorithme, de flags du compilateur, de niveau d’optimisation ou de version du runtime. Pour constant-time-analysis pour un audit de sécurité, ce second passage est souvent celui qui permet de confirmer la posture de sécurité réelle.