Temps constant : Programmation en temps constant
Cryptographie
Manière d'écrire un code qui manipule des secrets pour que sa durée d'exécution, ses branchements et ses accès mémoire ne dépendent jamais de la valeur de ces secrets. Objectif : qu'un chronomètre, même très précis, n'apprenne rien.
Ce qui trahit : Une comparaison qui s'arrête au premier octet faux, un `if` sur un bit de clé, une table indexée par une valeur secrète : chacun laisse une trace mesurable en durée ou dans le cache. À distance, sur des milliers de requêtes, la statistique fait le reste.
Les techniques : On remplace les branches par des masques binaires et des sélections arithmétiques, on parcourt toujours le tampon entier, on évite les tables indexées par un secret. Les bibliothèques fournissent des primitives dédiées (`CRYPTO_memcmp`, `subtle.ConstantTimeCompare`) qu'il vaut mieux utiliser que réécrire.
Le piège du compilateur : L'optimiseur peut réintroduire une sortie anticipée, et certaines instructions (division, multiplication sur quelques processeurs) ont une latence qui varie selon les opérandes. Le compilateur n'a jamais lu le modèle de menace : il voit une boucle qu'on peut abréger, et il l'abrège avec zèle.
À ne pas confondre : Rien à voir avec le O(1) de l'algorithmique, qui décrit la croissance du coût avec la taille de l'entrée. Ici, on exige la même durée pour toutes les valeurs secrètes, à taille égale.
Ce qui arrive si on s'en passe
Sans code en temps constant, la durée d'une opération devient un canal de fuite. Une comparaison de MAC ou de jeton qui s'arrête au premier octet différent révèle combien d'octets sont corrects : en mesurant les temps de réponse, un attaquant reconstitue la valeur attendue octet par octet au lieu de devoir tout deviner d'un coup. Un branchement qui dépend des bits d'une clé (une exponentiation modulaire naïve, par exemple) trahit ces bits par sa durée. Un accès à une table indexé par un secret laisse aussi une empreinte dans le cache, observable par un autre processus qui partage le même processeur. Le bruit du réseau ne protège pas : en répétant les mesures, les statistiques le filtrent. Ces attaques n'emploient que des requêtes ordinaires, si bien que les journaux et les détecteurs n'y voient rien d'anormal.
Explication de la marmotte
Imagine un gardien qui vérifie un mot de passe lettre par lettre et te renvoie dès la première erreur. Si tu chronomètres sa réponse, tu remarques qu'il met un peu plus longtemps quand ta première lettre est bonne. Tu peux alors deviner le mot de passe lettre après lettre, sans jamais le voir. Travailler « en temps constant », c'est obliger le gardien à toujours tout relire, du début à la fin, et à mettre exactement le même temps, que tu aies juste ou faux. Le chronomètre ne t'apprend plus rien.
Où ce terme est utilisé
- Attaques par canaux auxiliaires et secrets (6 occurrences)
- Non-interférence et contrôle de flux d'information en pratique (6 occurrences)
- Quand l’implémentation parle : temps, cache, fautes et oracles (6 occurrences)
- Choisir, combiner et migrer les algorithmes symétriques (3 occurrences)
- Chiffrer par blocs : de l’héritage DES à AES (2 occurrences)
- Courbes elliptiques : compacité, validation et pièges (2 occurrences)
- Transformer un bloc en chiffrement de message (2 occurrences)
- Chiffrement par flot : état, compteurs et réutilisation interdite (1 occurrence)
- Chiffrer et authentifier en une seule construction (1 occurrence)
- Choisir ECDSA, EdDSA ou RSA pour un certificat TLS (1 occurrence)