LANXAS IA Logiciels
LANXAS Meet LANXAS Chat
Étudiant Formation Business Jeux Bibliothèque Boutique Support technique

Société

InvestisseursConfidentialité chez LanxasEmploi

Développeur et IT

Développeur LanxasLanxas Tech CommunityLanxas Power PlatformLanxas Marketplace

Éducation

Calculatrice & solveurAtelier de fichiers Lanxas LearnLanxas MathLanxas pour les étudiantsLanxas Planning

Lanxas Store

Centre de téléchargementSupport technique

Entreprises

Lanxas CashLanxas StockLanxas CareLanxas BuildLanxas TradeLanxas Legal

LANXAS White Benchmark, test v2-090

Prompt

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire.

Q090 — Pourquoi comparer naïvement deux MAC avec une comparaison qui s’arrête au premier octet différent peut-il créer une fuite temporelle ?

Raw response

Je vous remercie pour cette question, qui touche à un point classique et important de la sécurité cryptographique.

## Réponse

Comparer naïvement deux MAC avec une comparaison qui s'arrête au premier octet différent crée une fuite temporelle parce que le temps d'exécution de la comparaison dépend du contenu des données comparées, et donc d'informations secrètes.

## Justification

Une comparaison naïve s'écrit typiquement ainsi, en langage C :

```c
int compare_mac(const unsigned char *a, const unsigned char *b, size_t n) {
    for (size_t i = 0; i < n; i++) {
        if (a[i] != b[i]) {
            return 0;  /* s'arrête dès le premier octet différent */
        }
    }
    return 1;
}
```

Le temps d'exécution de cette fonction est proportionnel au nombre d'octets identiques en tête des deux MAC. Concrètement, si les deux MAC diffèrent dès le premier octet, la fonction retourne presque immédiatement ; s'ils partagent les k premiers octets, elle parcourt k+1 octets avant de s'arrêter.

Or, dans un scénario d'attaque, l'attaquant envoie des messages accompagnés de MAC qu'il devine, et le serveur compare le MAC reçu au MAC authentique (secret). En mesurant précisément le temps de réponse, l'attaquant peut déduire combien d'octets initiaux de son MAC deviné étaient corrects. Il peut alors fixer le premier octet correct, puis deviner le second, et ainsi de suite, octet par octet. C'est une attaque par canal auxiliaire temporel, qui permet de reconstituer le MAC secret en environ 256 × n essais au lieu de 256^n essais pour une recherche exhaustive.

## Contre-mesure

La solution standard est une comparaison à temps constant, qui parcourt toujours la totalité des octets et dont le temps ne dépend pas des valeurs comparées :

```c
int compare_mac_constant(const unsigned char *a, const unsigned char *b, size_t n) {
    unsigned char diff = 0;
    for (size_t i = 0; i < n; i++) {
        diff |= a[i] ^ b[i];
    }
    return diff == 0;
}
```

Ici, le nombre d'itérations est toujours n, indépendamment du contenu, et le résultat est accumulé par un OU binaire. Le temps d'exécution est donc indépendant des données, ce qui supprime la fuite temporelle.

## Confiance

Je suis très confiant sur ce point, car il s'agit d'un résultat standard et bien documenté de la cryptographie appliquée, enseigné dans les références classiques sur les canaux auxiliaires. Je situe ma confiance à environ 97 %.

En résumé, la fuite provient du fait que le temps d'exécution est corrélé au nombre d'octets corrects devinés, ce qui transforme une recherche exponentielle en une recherche linéaire guidée par la mesure du temps. La parade est une comparaison à temps constant, qui découple le temps d'exécution du contenu des données.

Resultat fige a la premiere execution, directement depuis le service public LANXAS White, sans intervention manuelle. Cette page est permanente et peut etre re-consultee pour verification.