LANXAS White, Blind Benchmark v2.0, liasse v2-081 à v2-090

Liasse de consultation : copie conforme, octet pour octet, des exécutions gelées du 21 août 2026. Les pages individuelles test-v2-NNN.html restent la référence opposable, chaque réponse est vérifiable par son SHA-256. Aucune ré-exécution, aucune modification.

Index des 12 liasses · Registre officiel

Copie v2-081

Question (verbatim)

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.

Q081 — Une clé étrangère SQL peut-elle référencer une contrainte UNIQUE plutôt que la PRIMARY KEY ? Préciser les réserves de SGBD.

Réponse intégrale (verbatim, hachée ci-dessus)

Je vous remercie pour cette question précise sur les bases de données relationnelles.

**Réponse**

Oui, une clé étrangère SQL peut référencer une contrainte UNIQUE, et pas seulement la PRIMARY KEY. C'est un comportement standard du langage SQL, défini dans la norme SQL (ISO/IEC 9075).

**Justification**

La règle fondamentale est la suivante : la colonne (ou la combinaison de colonnes) référencée par une clé étrangère doit être soumise à une contrainte d'unicité. Or, une PRIMARY KEY est, par définition, une contrainte UNIQUE particulière (avec en plus la non-nullité). La norme SQL autorise donc explicitement qu'une FOREIGN KEY référence :

- soit la PRIMARY KEY de la table parente ;
- soit toute contrainte UNIQUE déclarée sur la table parente.

La condition essentielle est que les types de données correspondent et que le nombre de colonnes soit identique entre la clé étrangère et la contrainte référencée.

**Réserves selon les SGBD**

La prise en charge est générale, mais quelques nuances existent :

- **PostgreSQL** : supporte pleinement la référence à une contrainte UNIQUE, y compris les contraintes UNIQUE partielles ou avec des index uniques. Il faut simplement que la contrainte UNIQUE existe en tant que telle (ou un index unique).
- **MySQL / MariaDB** : supportent la référence à une clé UNIQUE. Une réserve notable : la colonne référencée doit être indexée, et le moteur InnoDB exige que la contrainte UNIQUE soit déclarée (un simple index unique fonctionne aussi). Les colonnes référencées doivent être non nulles dans les faits, même si la contrainte UNIQUE tolère plusieurs NULL (chaque NULL étant distinct).
- **Oracle** : supporte la référence à une contrainte UNIQUE. Réserve : la contrainte UNIQUE doit être déclarée comme contrainte (pas seulement un index unique), et les colonnes référencées doivent être non nulles.
- **SQL Server** : supporte la référence à une contrainte UNIQUE. Réserve : la contrainte UNIQUE doit être déclarée explicitement (un index unique seul ne suffit pas), et les colonnes référencées doivent être non nulles.
- **SQLite** : supporte la référence à une contrainte UNIQUE, mais avec une réserve importante : par défaut, la vérification des clés étrangères est désactivée (il faut activer la pragma `foreign_keys`). De plus, SQLite exige que la contrainte référencée soit UNIQUE ou PRIMARY KEY.

**Point de vigilance commun**

Une nuance sémantique importante : si la contrainte UNIQUE autorise des valeurs NULL (ce qui est le cas dans la plupart des SGBD, où plusieurs NULL sont admis), alors la clé étrangère référençant cette contrainte peut poser des questions de cohérence. En pratique, la plupart des SGBD exigent que les colonnes référencées soient non nulles pour qu'une clé étrangère puisse les cibler, ou traitent les NULL de manière particulière.

**Confiance** : 96 %. La possibilité de référencer une contrainte UNIQUE est un fait standard bien établi de la norme SQL et des principaux SGBD. Les nuances par SGBD (notamment l'exigence de contrainte déclarée plutôt que simple index chez Oracle et SQL Server, et l'activation des clés étrangères chez SQLite) sont des points techniques que je connais bien, mais dont les détails exacts peuvent varier légèrement selon les versions ; je laisse donc une petite marge.

Je reste à votre disposition pour approfondir un SGBD particulier.

Copie v2-082

Question (verbatim)

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.

Q082 — Pourquoi un index B-tree est-il peu utile pour certaines requêtes à très faible sélectivité ?

Réponse intégrale (verbatim, hachée ci-dessus)

Je vous remercie pour cette question, qui touche au cœur du fonctionnement des index en base de données.

## Réponse

Un index B-tree est peu utile pour les requêtes à très faible sélectivité, c'est-à-dire celles qui sélectionnent une très grande proportion des lignes de la table (par exemple 50 %, 80 % ou plus), pour une raison essentielle : le coût d'accès par ligne indexée dépasse celui d'un balayage séquentiel.

## Justification

Le B-tree est conçu pour l'accès ponctuel ou par plage étroite. Son avantage vient de ce qu'il permet de ne lire que les pages de données strictement nécessaires. Or, ce bénéfice repose sur la sélectivité : plus la fraction de lignes retournées est faible, plus l'économie de lecture est grande.

Lorsque la sélectivité devient très faible, deux mécanismes se retournent contre l'index.

D'abord, le coût des lectures aléatoires. Chaque ligne satisfaisant le prédicat est localisée via l'index, puis la page de données correspondante est lue. Ces lectures se font en accès aléatoire, bien plus coûteux que la lecture séquentielle. Quand on touche une grande fraction des lignes, on finit par lire presque toutes les pages de la table, mais en ordre dispersé, ce qui est plus lent qu'un simple balayage linéaire.

Ensuite, le coût de traversée de l'index lui-même. L'optimiseur doit parcourir une grande portion de l'arbre pour collecter toutes les entrées correspondantes, puis effectuer les retours à la table. Ce surcoût s'ajoute sans apporter de gain, puisque de toute façon presque toute la table sera lue.

Enfin, le seuil de basculement. Les optimiseurs estiment le coût des deux stratégies et choisissent le balayage séquentiel dès que la fraction estimée dépasse un seuil, souvent de l'ordre de 5 à 10 % des lignes (ce seuil varie selon le moteur, la taille des pages et la présence d'un balayage parallèle). Au-delà, l'index devient contre-productif.

## Cas particuliers à nuancer

Il faut toutefois préciser deux exceptions où un B-tree peut rester utile même à faible sélectivité.

L'index couvrant. Si toutes les colonnes nécessaires à la requête sont dans l'index, on évite le retour à la table : l'index seul suffit, et le coût des lectures aléatoires disparaît. L'index peut alors rester compétitif.

L'ordre de tri. Si la requête exige un tri sur la colonne indexée, le B-tree fournit les lignes déjà triées, ce qui peut économiser une opération de tri coûteuse, même pour une sélectivité faible.

## Confiance

Je situe ma confiance à 90 %. La justification repose sur des principes bien établis de l'optimisation des bases de données relationnelles (coût comparé des accès séquentiels et aléatoires, seuil de basculement de l'optimiseur). La valeur précise du seuil de sélectivité varie selon les moteurs et n'est pas une constante universelle, ce qui explique que je ne puisse pas donner un chiffre exact ; c'est pourquoi je n'ai pas avancé de valeur absolue. Les deux exceptions citées (index couvrant et tri) sont des cas standard documentés.

En résumé, l'index B-tree brille par sa précision chirurgicale ; dès que la requête embrasse une trop grande part de la table, cette précision devient un luxe coûteux, et le balayage séquentiel reprend la main.

Copie v2-083

Question (verbatim)

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.

Q083 — Un index couvrant peut-il éviter l’accès à la table de base ?

Réponse intégrale (verbatim, hachée ci-dessus)

Bonjour,

Oui, un index couvrant peut éviter l'accès à la table de base, mais uniquement pour certaines requêtes. C'est le principe de l'index-only scan.

Un index couvrant est un index qui contient, en plus des colonnes de recherche, toutes les colonnes nécessaires à la requête. Lorsqu'une requête ne sélectionne et ne filtre que des colonnes présentes dans l'index, le moteur de base de données peut répondre entièrement à partir de l'index, sans jamais lire la table de base. C'est ce qu'on appelle un index-only scan (ou covering index scan).

Les conditions pour que cela fonctionne sont les suivantes. D'abord, toutes les colonnes de la clause SELECT doivent être dans l'index. Ensuite, toutes les colonnes utilisées dans les prédicats de filtrage (WHERE), de jointure ou de tri doivent également y figurer. Enfin, le moteur doit pouvoir garantir la visibilité des lignes sans consulter la table, ce qui nécessite généralement un mécanisme de contrôle de version (comme le MVCC) ou une table non modifiée.

Il existe toutefois des limites importantes. Dans PostgreSQL, par exemple, l'index-only scan nécessite la présence d'une colonne de visibilité (visibility map) ; si des lignes ont été récemment modifiées et ne sont pas encore marquées comme visibles, le moteur devra quand même accéder à la table pour vérifier. De même, si la requête demande des colonnes absentes de l'index, l'accès à la table devient inévitable. Enfin, les index couvrants augmentent la taille du stockage et ralentissent les écritures, puisqu'il faut maintenir davantage de données indexées.

En résumé, un index couvrant peut effectivement éviter l'accès à la table de base pour les requêtes dont toutes les colonnes sont couvertes par l'index, à condition que le moteur puisse confirmer la visibilité des lignes sans la table. C'est une technique d'optimisation classique et efficace, mais elle n'est pas universelle.

Confiance : 95 %. La notion d'index couvrant et d'index-only scan est un concept standard et bien documenté des bases de données relationnelles ; je suis très confiant sur le principe général, avec une légère réserve sur les détails d'implémentation propres à chaque moteur.

Cordialement.

Copie v2-084

Question (verbatim)

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.

Q084 — Expliquez le problème lost update et une manière standard de le prévenir.

Réponse intégrale (verbatim, hachée ci-dessus)

Je vous remercie pour cette question, qui porte sur un concept fondamental des systèmes de gestion de bases de données.

Le problème du lost update (mise à jour perdue) survient lorsque deux transactions concurrentes lisent la même donnée, puis la modifient chacune en se basant sur la valeur initiale lue, et écrivent leur résultat. La dernière écriture écrase la première, et la modification de la première transaction est silencieusement perdue, sans qu'aucune erreur ne soit signalée.

Prenons un exemple concret avec un compte bancaire contenant 100 euros. La transaction A souhaite créditer 50 euros, la transaction B souhaite débiter 30 euros. Si elles s'exécutent de manière entrelacée, A lit 100, B lit 100, A écrit 150, B écrit 70. Le résultat final est 70, alors que le résultat correct attendu est 120 (100 plus 50 moins 30). La mise à jour de A a été perdue.

La manière standard de prévenir ce problème est le verrouillage (locking), et plus précisément le verrou exclusif en écriture. Dans le protocole de verrouillage à deux phases (two-phase locking), une transaction qui souhaite modifier une donnée acquiert un verrou exclusif sur celle-ci avant de la lire ou de la modifier, et le conserve jusqu'à la fin de la transaction. Toute autre transaction qui tente d'accéder à cette donnée est alors bloquée jusqu'à la libération du verrou. Dans notre exemple, si A acquiert le verrou exclusif sur le compte, B doit attendre que A ait terminé et libéré le verrou ; B lit alors la valeur mise à jour (150) et écrit 120, ce qui est correct.

Une autre approche standard, alternative au verrouillage, est le contrôle de concurrence optimiste (optimistic concurrency control) avec validation par version ou horodatage : chaque transaction vérifie, au moment de la validation, que la version de la donnée qu'elle a lue n'a pas changé depuis ; si c'est le cas, elle est rejetée et doit être relancée. Cette méthode évite les blocages mais impose de réexécuter les transactions rejetées.

Le verrouillage à deux phases reste la solution la plus classique et la plus largement déployée, car elle garantit la sérialisabilité, c'est-à-dire que le résultat de l'exécution concurrente est équivalent à celui d'une exécution séquentielle.

Ma confiance dans cette réponse est de 95 pour cent, car il s'agit d'un concept standard et bien établi des bases de données relationnelles, que je restitue de mémoire avec une certitude élevée mais non absolue.

Copie v2-085

Question (verbatim)

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.

Q085 — Pourquoi stocker des mots de passe avec MD5+sel reste-t-il inadéquat ?

Réponse intégrale (verbatim, hachée ci-dessus)

Je vous remercie pour cette question, qui touche à un point fondamental de la sécurité informatique.

**Réponse**

Stocker des mots de passe avec MD5 et un sel reste inadéquat pour plusieurs raisons convergentes, qui tiennent à la fois à l'algorithme de hachage lui-même et à la conception générale du schéma.

**La faiblesse intrinsèque de MD5**

MD5 est un algorithme de hachage cryptographique conçu en 1991, dont la sécurité est aujourd'hui largement compromise. Dès 2004, des collisions ont été démontrées (deux messages différents produisant le même condensat), et la recherche a depuis produit des attaques de plus en plus efficaces. Or, pour le stockage de mots de passe, ce qui importe avant tout n'est pas tant la résistance aux collisions que la résistance à la préimage et à la seconde préimage : la capacité de retrouver un mot de passe à partir de son condensat. Si MD5 n'est pas complètement cassé sur ce plan, sa rapidité d'exécution le rend vulnérable à des attaques massives par force brute et par dictionnaire.

**La vitesse, ennemi du stockage de mots de passe**

C'est là le point décisif. Un bon algorithme de dérivation de clé pour mots de passe doit être volontairement lent et gourmand en mémoire, afin de rendre chaque tentative de devinette coûteuse pour l'attaquant. Or MD5 est extrêmement rapide : il peut calculer des centaines de millions de condensats par seconde sur du matériel moderne, et des milliards avec des GPU ou des circuits spécialisés. Un attaquant disposant d'une base de condensats peut donc tester des milliards de mots de passe par seconde. Le sel, qui sert à empêcher les attaques par tables précalculées (tables arc-en-ciel), ne ralentit en rien cette vitesse de devinette : il ne fait que forcer l'attaquant à recalculer pour chaque sel, ce qui est trivialement compensé par la rapidité de MD5.

**Le rôle limité du sel**

Le sel a une fonction précise : empêcher que deux utilisateurs ayant le même mot de passe produisent le même condensat, et neutraliser les tables précalculées. C'est une bonne pratique, mais elle ne corrige en rien la faiblesse fondamentale de l'algorithme. Un sel ajouté à MD5 reste un MD5 : rapide, donc attaquable par force brute à grande échelle.

**Les bonnes pratiques actuelles**

Les recommandations modernes (notamment de l'ANSSI et du NIST) préconisent des fonctions de dérivation de clé spécifiquement conçues pour être lentes et résistantes au matériel spécialisé, comme bcrypt, scrypt, Argon2 (le lauréat du concours Password Hashing Competition de 2015), ou PBKDF2. Ces fonctions intègrent un facteur de coût réglable et, pour certaines, une exigence de mémoire importante, rendant l'attaque par force brute des millions de fois plus coûteuse qu'avec MD5.

**En résumé**

Le schéma MD5+sel est inadéquat non pas parce que le sel est inutile, mais parce que l'algorithme de hachage est à la fois obsolète sur le plan cryptographique et, surtout, beaucoup trop rapide pour servir au stockage de mots de passe. Il faut lui substituer une fonction de dérivation de clé lente et coûteuse en mémoire, comme Argon2, bcrypt ou scrypt.

**Confiance : 95 %.** Cette analyse repose sur des faits établis et largement documentés de la cryptographie appliquée (compromission de MD5, exigences de lenteur pour le hachage de mots de passe, recommandations des organismes de normalisation). La petite marge d'incertitude tient au fait que je récite ces éléments de mémoire, sans pouvoir ici consulter les documents sources.

Je reste à votre disposition pour approfondir tel ou tel aspect, par exemple la comparaison chiffrée des vitesses d'attaque entre MD5 et Argon2.

Copie v2-086

Question (verbatim)

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.

Q086 — Comparer Argon2id, bcrypt et un hash rapide généraliste pour le stockage de mots de passe.

Réponse intégrale (verbatim, hachée ci-dessus)

Je vous remercie pour cette question, qui porte sur un sujet de sécurité fondamental. Voici une comparaison rigoureuse de ces trois approches pour le stockage de mots de passe.

Comparaison des trois approches

Argon2id est aujourd'hui la référence recommandée. C'est un algorithme de dérivation de clé conçu spécifiquement pour les mots de passe, vainqueur de la compétition Password Hashing Competition en 2015. Il combine la résistance contre les attaques par GPU et ASIC grâce à sa mémoire-dureté, et contre les attaques par canaux auxiliaires de cache grâce à sa partie identifiée par le suffixe id. Il permet de paramétrer trois facteurs : la mémoire, le temps et le parallélisme. C'est l'algorithme recommandé par l'OWASP et par l'ANSSI.

bcrypt est un algorithme plus ancien, datant de 1999, basé sur le chiffrement Blowfish. Il est résistant aux attaques par GPU grâce à son coût en mémoire, mais sa mémoire est fixe et relativement faible, de l'ordre de 4 Ko, ce qui le rend vulnérable aux attaques par FPGA et ASIC spécialisés. Son principal défaut est la limite de 72 octets sur la longueur du mot de passe, et son paramètre de coût ne peut qu'augmenter, jamais diminuer, ce qui complique les migrations. Il reste néanmoins une option acceptable si Argon2 n'est pas disponible.

Un hash rapide généraliste, comme SHA-256, MD5 ou SHA-1, est conçu pour la vitesse et l'intégrité des données, pas pour la protection des mots de passe. Ces fonctions sont extrêmement rapides, ce qui permet à un attaquant de tester des milliards de combinaisons par seconde. Elles ne comportent ni sel intégré, ni facteur de travail, ni exigence de mémoire. Les utiliser pour des mots de passe est une erreur grave de sécurité.

Tableau comparatif

Pour le critère de conception, Argon2id est un KDF mémoire-dur, bcrypt est un KDF basé sur Blowfish, et le hash rapide est une fonction de hachage généraliste. Pour le sel intégré, Argon2id en inclut un, bcrypt également, tandis que le hash rapide n'en inclut pas et exige de l'ajouter manuellement. Pour le paramètre mémoire, Argon2id le permet avec le facteur m, bcrypt ne le permet pas avec une mémoire fixe de 4 Ko, et le hash rapide ne le permet pas. Pour le paramètre temps, Argon2id le permet avec le facteur t, bcrypt le permet avec son coût, et le hash rapide ne le permet pas. Pour la résistance GPU et ASIC, Argon2id est excellente, bcrypt est bonne, et le hash rapide est très faible. Pour la longueur maximale du mot de passe, Argon2id est illimitée, bcrypt est limitée à 72 octets, et le hash rapide est illimitée. Pour la recommandation actuelle, Argon2id est recommandé par l'OWASP et l'ANSSI, bcrypt est acceptable, et le hash rapide ne l'est pas.

Recommandation pratique

Pour le stockage de mots de passe, la hiérarchie est claire : Argon2id en premier choix, bcrypt en solution de repli acceptable, et jamais un hash rapide généraliste. Si vous utilisez un hash rapide, il faut au minimum ajouter un sel unique par utilisateur et appliquer de nombreuses itérations, selon une approche de type PBKDF2, mais cela reste inférieur à Argon2id.

Un point important : quel que soit l'algorithme, le sel doit être unique et aléatoire pour chaque mot de passe, et le paramétrage doit être choisi pour viser un temps de calcul d'environ 100 à 300 millisecondes sur le matériel de référence, afin de ralentir l'attaquant sans pénaliser l'utilisateur.

Confiance

Ma confiance dans cette comparaison est de 92 %. Les recommandations de l'OWASP et de l'ANSSI en faveur d'Argon2id sont bien établies, et les caractéristiques techniques de bcrypt, notamment la limite de 72 octets et la mémoire fixe, ainsi que celles des hash rapides, sont des faits documentés. La petite marge d'incertitude tient au fait que les recommandations évoluent avec le temps et que je ne peux pas vérifier ici la version la plus récente des guides officiels.

Je reste à votre disposition pour approfondir le paramétrage concret d'Argon2id ou les stratégies de migration depuis bcrypt.

Copie v2-087

Question (verbatim)

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.

Q087 — Un sel identique pour tous les utilisateurs remplit-il correctement le rôle d’un sel unique ?

Réponse intégrale (verbatim, hachée ci-dessus)

Je vous remercie pour cette question, qui touche à un point fondamental de la cryptographie.

**Réponse :** Non, un sel identique pour tous les utilisateurs ne remplit pas correctement le rôle d'un sel unique.

**Justification :**

Le sel cryptographique a deux fonctions essentielles, et un sel partagé par tous les utilisateurs échoue sur les deux.

D'abord, le sel sert à empêcher les attaques par tables précalculées, telles que les tables arc-en-ciel ou les tables de hachage. Un sel unique par utilisateur force l'attaquant à recalculer une table distincte pour chaque sel, ce qui rend l'attaque économiquement irréalisable. Si tous les utilisateurs partagent le même sel, l'attaquant ne construit qu'une seule table pour ce sel, et celle-ci couvre alors tous les comptes du système. La protection contre les tables précalculées est donc entièrement perdue.

Ensuite, le sel sert à rendre les hachages distincts pour des mots de passe identiques. Deux utilisateurs qui choisissent le même mot de passe produisent, avec des sels différents, deux hachages différents ; l'attaquant ne peut pas deviner qu'ils partagent le même secret. Avec un sel commun, deux mots de passe identiques donnent deux hachages identiques, ce qui révèle immédiatement les comptes partageant le même mot de passe et permet des attaques groupées.

Par ailleurs, un sel commun est souvent une constante codée en dur dans le logiciel. S'il est découvert, par exemple par rétro-ingénierie, il est compromis pour l'ensemble du système, alors qu'un sel unique compromis ne l'est que pour un seul compte.

Enfin, la norme de référence en la matière, la recommandation NIST SP 800-63B, exige explicitement que le sel soit unique par mot de passe, et non seulement par utilisateur, c'est-à-dire régénéré à chaque changement de mot de passe. Un sel global contredit directement cette exigence.

**Confiance :** 97 %. La conclusion est une conséquence directe et bien établie des principes de la cryptographie des mots de passe ; je laisse une petite marge par prudence sur la formulation exacte des recommandations normatives, que je cite de mémoire.

Copie v2-088

Question (verbatim)

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.

Q088 — Une signature numérique assure-t-elle confidentialité, authenticité, intégrité, non-répudiation ? Distinguer.

Réponse intégrale (verbatim, hachée ci-dessus)

La signature numérique n'assure pas la confidentialité. Elle garantit en revanche l'authenticité, l'intégrité et la non-répudiation. Il faut donc distinguer nettement ces quatre propriétés.

**Justification**

Une signature numérique repose sur un schéma de signature asymétrique : le signataire utilise sa clé privée pour produire la signature, et quiconque possède sa clé publique peut la vérifier. Cette architecture détermine précisément ce qu'elle peut et ne peut pas garantir.

D'abord, la confidentialité n'est pas assurée. La signature est apposée sur le message, mais le message lui-même circule en clair, lisible par tout intermédiaire. La clé publique, nécessaire à la vérification, est par définition publique. Rien dans le mécanisme ne chiffre le contenu. Pour obtenir la confidentialité, il faut recourir à un chiffrement (par exemple un chiffrement asymétrique ou hybride), qui est une opération distincte et complémentaire. C'est pourquoi les protocoles qui exigent les deux propriétés combinent signature et chiffrement, par exemple en signant puis en chiffrant, ou en utilisant un schéma de chiffrement signé.

Ensuite, l'authenticité est assurée : la vérification avec la clé publique du signataire établit que la signature a bien été produite par le détenteur de la clé privée correspondante, donc que le message provient bien de lui.

L'intégrité est également assurée : toute modification du message, même d'un seul bit, invalide la signature lors de la vérification. Le lien cryptographique entre le message et la signature rend toute altération détectable.

Enfin, la non-répudiation est assurée dans la mesure où le signataire ne peut pas raisonnablement nier avoir signé : seul le détenteur de la clé privée pouvait produire cette signature vérifiable par sa clé publique. Cette propriété suppose toutefois que la clé privée n'ait pas été compromise et que l'infrastructure de gestion des clés (autorité de certification, horodatage) soit fiable.

**Récapitulatif**

La confidentialité est la seule des quatre propriétés que la signature numérique ne fournit pas. Elle doit être obtenue par un mécanisme de chiffrement séparé.

**Confiance : 96 %.** Cette distinction est un résultat standard de cryptographie, que je connais avec une grande fiabilité ; la marge restante tient à la formulation des conditions d'application (gestion des clés, horodatage) qui relèvent de la pratique plutôt que du principe mathématique.

Copie v2-089

Question (verbatim)

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.

Q089 — AES-GCM fournit-il chiffrement authentifié ? Quelles propriétés exige-t-il du nonce ?

Réponse intégrale (verbatim, hachée ci-dessus)

AES-GCM fournit bien un chiffrement authentifié. Il s'agit d'un mode de chiffrement authentifié (AEAD, Authenticated Encryption with Associated Data) qui combine le chiffrement par blocs AES en mode CTR pour la confidentialité et une authentification par GHASH, une fonction de hachage polynomiale sur le corps de Galois GF(2^128), pour l'intégrité et l'authenticité. Il produit donc un tag d'authentification qui couvre à la fois le texte chiffré et les données associées (AAD), permettant de détecter toute modification.

Les propriétés exigées du nonce sont strictes et critiques pour la sécurité.

D'abord, l'unicité absolue. Le nonce doit être unique pour chaque chiffrement effectué avec une même clé. C'est la propriété la plus importante : si un même couple (clé, nonce) est réutilisé pour deux messages distincts, la sécurité s'effondre. En effet, le flux de chiffrement étant identique, un attaquant peut récupérer le XOR des deux messages en clair, et l'authentification GHASH devient également vulnérable à des attaques de forgery. C'est une faiblesse documentée et exploitée en pratique.

Ensuite, la longueur. Le nonce standard fait 96 bits (12 octets). C'est la taille recommandée et la plus efficace. GCM accepte des nonces d'autres longueurs, mais pour toute longueur différente de 96 bits, le nonce est d'abord traité par une fonction de hachage (GHASH) pour produire une valeur de 128 bits, ce qui introduit une probabilité de collision non nulle et est déconseillé. La recommandation est donc d'utiliser exclusivement des nonces de 96 bits.

Enfin, la prédictibilité. Le nonce n'a pas besoin d'être imprévisible ou aléatoire ; il peut être un simple compteur incrémental, à condition qu'il ne soit jamais réutilisé. C'est d'ailleurs l'usage recommandé par le NIST. Un nonce aléatoire de 96 bits est acceptable si la source aléatoire est de bonne qualité, mais la probabilité de collision devient alors non négligeable au-delà d'environ 2^32 messages (par le paradoxe des anniversaires), ce qui limite le volume de données chiffrées.

En résumé, AES-GCM offre chiffrement authentifié, et la seule exigence absolue sur le nonce est son unicité par clé, avec une préférence forte pour des nonces de 96 bits, de préférence générés par compteur.

Confiance : 96 %. Ces propriétés sont des faits techniques bien établis de la cryptographie (spécification NIST SP 800-38D), que je connais avec une grande fiabilité, mais je les énonce de mémoire sans vérification externe ici.

Copie v2-090

Question (verbatim)

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 ?

Réponse intégrale (verbatim, hachée ci-dessus)

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.