Liasse v2-081 à v2-090

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 : Oui, une clé étrangère SQL peut référencer une contrainte UNIQUE, et non exclusivement une PRIMARY KEY. Cette possibilité est explicitement autorisée par le standard SQL. Justification : - Fondement normatif : Le standard SQL (ISO/IEC 9075) définit qu'une contrainte de clé étrangère peut référencer soit une PRIMARY KEY, soit une contrainte UNIQUE. La seule exigence structurelle est que les colonnes référencées soient couvertes par un index unique afin de garantir l'efficacité de la vérification d'intégrité référentielle. - Comportement des SGBD majeurs : * PostgreSQL : Accepte pleinement cette pratique. Il utilise automatiquement l'index unique créé par la contrainte UNIQUE. Aucun désavantage fonctionnel n'est observé par rapport à une PRIMARY KEY. * MySQL (Moteur InnoDB) : Prend en charge le référencement de contraintes UNIQUE. Les actions référentielles (ON UPDATE/DELETE) fonctionnent identiquement. La limitation technique réside uniquement dans l'obligation d'utiliser un moteur supportant les clés étrangères (InnoDB, n'exclut pas UNIQUE). * SQL Server : Autorise explicitement le référencement de contraintes UNIQUE ou PRIMARY KEY. Le plan d'exécution et les vérifications d'intégrité sont traités de façon équivalente. * Oracle Database : Suit le standard et permet le référencement de contraintes UNIQUE. * SQLite : Implémente cette caractéristique dans ses versions modernes, en s'appuyant sur l'index unique sous-jacent. - Réserves et nuances techniques : * Exigence d'indexation : Toutes les implémentations requièrent que les colonnes référencées soient couvertes par un index. Une contrainte UNIQUE crée systématiquement un index unique, ce qui satisfait cette condition. Si un index unique est supprimé, la clé étrangère devient invalide et doit être recréée. * Gestion des valeurs NULL : Selon le standard SQL, une clé étrangère peut contenir des NULL, et ces NULL ne sont jamais évalués comme correspondant à une ligne de la table référencée, que celle-ci soit indexée par une PRIMARY KEY ou une UNIQUE. Ce comportement est constant dans tous les SGBD cités. * Cohérence structurelle : La clé étrangère doit correspondre exactement en nombre, en type et en ordre des colonnes par rapport à la contrainte référencée. Une contrainte UNIQUE composée sur plusieurs colonnes ne peut être référencée que par une clé étrangère de même arité. * Performances et optimisation : Bien que fonctionnellement identiques, certains SGBD peuvent accorder une priorité marginale aux PRIMARY KEY dans leurs optimiseurs de requêtes ou dans la génération de plans d'exécution. Cette différence est généralement négligeable, sauf dans des schémas très complexes ou lors de jointures massives. * Moteurs non relationnels ou héritiers : Certains moteurs historiques (comme MyISAM dans MySQL) n'implémentent aucune contrainte de clé étrangère, ce qui rend la question inapplicable indépendamment du type de contrainte référencée. Cette limite relève du moteur et non de la norme SQL. Confiance : 95 %. La réponse s'appuie sur le standard SQL et sur le comportement documenté des principaux SGBD relationnels. Aucune donnée inventée n'est utilisée. Les nuances mentionnées correspondent aux pratiques courantes et aux limites techniques reconnues.

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 :** Un index B-tree est peu utile pour les requêtes à très faible sélectivité car la localisation des lignes via l'index entraîne un nombre élevé d'accès aléatoires, dont le coût dépasse généralement celui d'un parcours séquentiel complet de la table. **Justification :** La sélectivité mesure le rapport entre le nombre de valeurs distinctes d'une colonne et le nombre total de lignes. Une sélectivité très faible signifie qu'un même indexé correspond à une fraction importante du jeu de données. Lorsqu'un moteur utilise un index B-tree, il parcourt d'abord la structure arborescente pour identifier les pointeurs vers les lignes correspondantes. Chaque pointeur nécessite un accès individuel à la table physique. Ces accès sont aléatoires et impliquent souvent des lectures page par page non contiguës, ce qui génère de nombreux défauts de cache et une surcharge d'entrée-sortie. En revanche, un parcours séquentiel lit les pages de la table de manière contiguë, ce qui permet l'utilisation efficace du prefetching et des tampons de lecture. Les optimiseurs de requêtes comparent les coûts estimés : lorsque la sélectivité est très faible, le coût combiné du parcours de l'index et des accès aléatoires aux lignes devient supérieur à celui du scan séquentiel, conduisant le planificateur à ignorer l'index. Cette logique s'appuie sur un modèle de coût où le prix d'un accès aléatoire est nettement plus élevé que celui d'un accès séquentiel sur support physique classique. Le principe est validé par le modèle théorique des bases de données relationnelles et confirmé par la pratique des optimiseurs à coût. Des cas particuliers peuvent atténuer ce phénomène, notamment si la table est suffisamment petite pour tenir en mémoire, si l'index couvre toutes les colonnes requises, ou si le stockage utilise des accès séquentiels virtuels. Dans ces situations, le modèle de coût change et l'index peut rester pertinent. La prémisse de la question est exacte. Le seuil numérique de la faible sélectivité est indéterminable sans connaître la configuration du SGBD et son modèle de coût, mais la règle générale reste valide. **Confiance :** 95 %

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 : Oui. Justification : Un index couvrant est défini comme un index qui contient l'ensemble de toutes les colonnes nécessaires à l'exécution d'une requête. Lorsque le moteur de base de données identifie qu'un index couvre une requête, il peut satisfaire celle-ci exclusivement à partir de la structure d'indexation, sans effectuer de lecture supplémentaire sur la table de base. Cette optimisation, couramment qualifiée de scan index uniquement, est un mécanisme fondamental de l'optimisation des requêtes dans les systèmes relationnels modernes. La prémisse est vraie. Par définition même, un index est dit couvrant lorsqu'il contient toutes les colonnes requises, ce qui rend techniquement impossible un accès à la table de base pour cette requête spécifique. Aucun contre-exemple ne peut invalider cette propriété, car l'absence de table lookup est la caractéristique déterminante de la notion d'index couvrant. Confiance : 100 %

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 :** Le problème de mise à jour perdue est une anomalie de concurrence qui survient lorsque deux ou plusieurs transactions simultanées lisent la même donnée, la modifient chacune de leur côté à partir de cette lecture commune, puis écrivent leur résultat. La seconde écriture écrase la première, rendant la première modification définitivement invisible dans l'état final de la base. Une manière standard de le prévenir consiste à appliquer un mécanisme de verrouillage exclusif couplé à un niveau d'isolation approprié, par exemple via l'instruction SELECT FOR UPDATE ou en garantissant une isolation sérialisable, ce qui empêche toute autre transaction de lire ou modifier la donnée pendant la durée de l'opération. **Justification :** Ce phénomène correspond à un scénario classique de concurrence non contrôlée. Si la transaction T1 et la transaction T2 lisent simultanément une valeur V, que T1 écrit V plus Δ1 et que T2 écrit V plus Δ2, le résultat final devient V plus Δ2, tandis que V plus Δ1 est irrémédiablement effacé. Ce cas illustre une violation de la sérialisabilité, propriété fondamentale des transactions ACID. La prévention standard repose sur le contrôle de concurrence pessimiste. Dès qu'une transaction acquiert un verrou exclusif sur un item de données, le gestionnaire de verrous bloque toute lecture ou écriture ultérieure sur cet item jusqu'à validation ou annulation. L'instruction SELECT FOR UPDATE implémente ce principe en acquérant un verrou exclusif au moment de la lecture. Une alternative, le contrôle optimiste, utilise des versions ou des horodatages pour détecter les conflits avant le commit, mais le verrouillage reste la méthode de référence dans les systèmes relationnels. Une vérification symbolique confirme le mécanisme : sans verrou, la séquence R1(V), R2(V), W1(V+Δ1), W2(V+Δ2) aboutit à V+Δ2. Avec verrou exclusif, la séquence devient R1(V), W1(V+Δ1), R2(V), W2(V+Δ1+Δ2), ce qui préserve la cohérence mathématique et fonctionnelle. Aucune donnée externe n'est requise car ce concept relève des fondamentaux théoriques des bases de données. La prévention absolue dépend du niveau d'isolation configuré et de la stratégie de gestion des conflits du moteur utilisé. **Confiance :** 100 %

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 : Stocker des mots de passe avec MD5 additionné d'un sel reste inadéquat car MD5 est une fonction de hachage conçue pour la rapidité de calcul, non pour la résistance aux attaques par force brute ou par matériel spécialisé. Le sel protège contre les tables arc-en-ciel mais n'ajoute aucune complexité computationnelle ni aucune exigence mémoire. Justification : La sécurité du stockage de mots de passe repose sur la lenteur intentionnelle du hachage afin de limiter le nombre de tentatives réalisables par un attaquant. MD5 génère un résultat en quelques microsecondes sur un processeur moderne, ce qui permet d'effectuer des centaines de millions, voire milliards, de calculs par seconde à l'aide de GPU ou d'ASIC. Le sel, bien qu'indispensable pour garantir l'unicité des hachages et neutraliser les tables précalculées, ne modifie pas la vitesse intrinsèque de MD5 ni son absence de consommation mémoire. Les algorithmes recommandés aujourd'hui, tels qu'Argon2id, bcrypt, scrypt ou PBKDF2, intègrent un facteur de travail ajustable, des itérations multiples et, dans le cas d'Argon2id, une forte exigence mémoire. Ces propriétés rendent les attaques parallélisées économiquement et techniquement prohibitives. Par ailleurs, MD5 souffre de vulnérabilités cryptographiques avérées, notamment des attaques par collision, ce qui confirme son obsolescence dans tout protocole exigeant une garantie d'intégrité. Les directives de sécurité modernes interdisent son usage pour le stockage de secrets et prescrivent systématiquement des fonctions adaptatives à complexité variable. Confiance : 100 %

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** Pour le stockage de mots de passe, Argon2id est la méthode recommandée, bcrypt constitue une solution acceptable mais progressivement dépréciée, et un hash rapide généraliste est totalement inadapté et dangereux. **Justification** La conception d'un fonction de hachage destiné aux mots de passe repose sur trois exigences techniques fondamentales : un coût calculable ajustable, une forte résistance aux attaques par force brute parallélisée, et une protection contre les accélérateurs matériels (GPU, ASIC, FPGA) ainsi que contre les attaques par canaux auxiliaires. Argon2id répond à ces exigences en combinant la résistance aux canaux auxiliaires d'Argon2i et la résistance aux attaques matérielles d'Argon2d. Il est mémoire gourmand, ce qui limite drastiquement l'efficacité des cartes graphiques et des circuits spécialisés. Ses paramètres (taille de la mémoire en mégaoctets, nombre d'itérations, degré de parallélisme) permettent d'ajuster le coût selon les capacités du serveur. Il a remporté le Password Hashing Competition en 2015 et est désormais recommandé par l'OWASP, le NIST (publication SP 800 63B) et la RFC 9106. bcrypt est basé sur un adaptateur de la fonction de chiffrement Blowfish. Il introduit un facteur de coût exponentiel qui rend le hachage progressivement plus lent. Il est largement implémenté, stable et éprouvé, mais il n'est pas mémoire gourmand. Son architecture limite sa résistance aux accélérateurs matériels modernes. De plus, il impose une longueur maximale de 72 octets pour le mot de passe et un facteur de coût plafonné à 31. Bien que sécurisé à condition de choisir un facteur de coût suffisant, il est progressivement remplacé par des algorithmes plus résistants et plus flexibles. Un hash rapide généraliste tel que SHA 256 ou SHA 3 est conçu pour l'intégrité des données et la performance, pas pour la sécurité des mots de passe. Sa vitesse extrême permet à un attaquant de tester des milliards de combinaisons par seconde sur du matériel standard ou spécialisé. Même avec l'ajout d'un sel et d'un étirement par itérations, la faible consommation mémoire et l'absence de conception dédiée rendent ces fonctions vulnérables aux attaques par force brute parallélisée et aux tables arc en iris. Leur usage pour le stockage de mots de passe constitue une erreur de conception documentée. **Vérification des prémisses et contre-exemples** Une prémisse courante mais fausse avance qu'un hash rapide peut devenir sécurisé en augmentant le nombre d'itérations. Cette affirmation est incorrecte pour le stockage de mots de passe. La résistance à la force brute dépend du coût mémoire et de la capacité de parallélisation matérielle, pas uniquement du nombre de cycles CPU. Les accélérateurs exploitent la faible empreinte mémoire des hashs rapides pour maintenir un débit bien supérieur à celui d'Argon2id ou bcrypt, même avec un étirement important. La sécurité pratique reste donc inférieure. **Niveau de confiance** 98 %. La comparaison repose sur des standards cryptographiques publiquement validés, des analyses de sécurité reconnues et des recommandations officielles. Les limites techniques mentionnées (plafonnement de bcrypt, vitesse des hashs rapides, caractéristiques mémoire d'Argon2id) sont des faits vérifiables. Les 2 % restants reflètent la possibilité que des contraintes matérielles ou réglementaires très spécifiques puissent modifier l'ordre de préférence dans un contexte restreint, sans remettre en cause le classement général.

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 : Non. Justification : Un sel cryptographique a pour rôle fonctionnel de garantir que des mots de passe identiques produisent des hachages distincts, d'empêcher les attaques par tables arc-en-ciel et d'obliger un attaquant à reconduire la phase de cracking pour chaque compte. Par définition, un « sel unique » doit varier par utilisateur. Utiliser un même sel pour tous les utilisateurs contredit cette exigence : les hachages restent identiques pour des mots de passe identiques, ce qui permet à un attaquant de casser un mot de passe puis de l'appliquer immédiatement à tous les comptes partageant ce sel. De plus, un sel commun ne force pas la multiplication des calculs par utilisateur, ce qui réduit la charge computationnelle nécessaire lors d'une attaque par dictionnaire ou par force brute. Les principes établis de la cryptographie appliquée aux mots de passe exigent que chaque entrée soit associée à un sel généré de manière indépendante, aléatoire et de longueur suffisante. La prémisse de la question contient une contradiction interne : un sel identique pour tous ne peut pas, par définition ni par effet cryptographique, remplir le rôle d'un sel unique. Confiance : 100 %

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 : Une signature numérique assure l'authenticité, l'intégrité et la non-répudiation. Elle n'assure pas la confidentialité. Justification détaillée : Confidentialité : La prémisse selon laquelle une signature numérique assurerait la confidentialité est fausse. Le mécanisme de signature ne chiffre pas le message. Il applique une fonction de hachage cryptographique au document, puis chiffre le condensé résultant avec la clé privée du signataire. Le corps du message reste accessible en clair ou doit être chiffré par un processus distinct. La confidentialité relève exclusivement du chiffrement symétrique ou asymétrique appliqué au contenu lui-même, ce qui est une fonction orthogonale à la signature. Authenticité : La signature numérique assure l'authenticité. La vérification cryptographique utilise la clé publique du signataire. Une vérification réussie établit avec certitude que le message a été généré par la personne détentrice exclusive de la clé privée correspondante, garantissant ainsi l'identité de l'émetteur. Intégrité : La signature numérique assure l'intégrité. La fonction de hachage sous-jacente est conçue pour être préimage résistante et collision résistante. Toute altération, même d'un bit unique, du message ou du condensé modifie le résultat de hachage. La vérification échoue systématiquement, signalant ainsi une modification non autorisée. Non-répudiation : La signature numérique assure la non-répudiation. La possession exclusive de la clé privée et l'impossibilité de produire une signature valide sans cette clé génèrent une preuve d'origine infalsifiable. Le signataire ne peut nier avoir signé le document, à condition que la clé privée n'ait pas été compromise et que le certificat numérique (le cas échéant) soit valide et émis par une autorité de confiance. Distinction synthétique : L'authenticité et l'intégrité sont des propriétés intrinsèques et immédiates du protocole de signature. La non-répudiation en découle directement dans un environnement de gestion sécurisée des clés et de certification. La confidentialité est une propriété orthogonale qui nécessite un chiffrement explicite et séparé du message. Signature et chiffrement sont des primitives cryptographiques complémentaires mais aux objectifs distincts. Confiance : 100 %.

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 : Oui, AES-GCM fournit un chiffrement authentifié (AEAD). Le nonce doit être strictement unique pour chaque opération de chiffrement sous une même clé, et il est recommandé de le dimensionner à 96 bits. Justification : AES-GCM (Galois/Counter Mode) combine le mode de chiffrement CTR pour la confidentialité et une fonction de hachage polynomial sur un corps fini (GMAC) pour l'intégrité. Le schéma produit simultanément un texte chiffré et un tag d'authentification, ce qui assure à la fois la confidentialité et l'authenticité des données transmises. La sécurité du mécanisme repose entièrement sur l'unicité du nonce. Toute réutilisation d'un nonce avec la même clé provoque une recopie des keystreams CTR, exposant les différences entre les messages clairs, et rend le tag de hachage forgable, annulant ainsi la garantie d'authenticité. Les spécifications techniques de référence exigent un nonce de 96 bits pour des raisons d'efficacité et de compatibilité, tout en interdisant formellement toute duplication sous une même clé. Confiance : 100 %

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 : Une comparaison naïve qui s’arrête au premier octet différent crée une fuite temporelle parce que le temps d’exécution devient fonction du nombre d’octets identiques en début de MAC. Cette dépendance permet à un attaquant de déduire progressivement les valeurs correctes des octets à partir de mesures de latence. Justification : Les routines de comparaison standard, comme `memcmp` ou une boucle itérative classique, interrompent immédiatement le traitement dès qu’un octet ne correspond pas. Lorsqu’un octet initial est correct, la condition de sortie n’est pas satisfaite et le processeur poursuit le traitement jusqu’au prochain octet. La différence de temps entre une comparaison échouant au premier octet et une comparaison échouant au cinquième octet est mesurable, en particulier sur des architectures où les branchements conditionnels, les caches et les accès mémoire introduisent des cycles variables. Un attaquant peut exploiter cette caractéristique en envoyant systématiquement des MAC soumis et en analysant les temps de réponse. Pour chaque position d’octet, il teste les valeurs possibles et retient celle qui allonge le plus la comparaison, ce qui indique une correspondance. En répétant l’opération position par position, il reconstruit le MAC complet sans connaître la clé secrète. Cette vulnérabilité contrevient au principe de temps constant exigé pour les fonctions de vérification d’authentification. La contre-mesure standard consiste à utiliser une comparaison à temps constant, par exemple en accumulant les différences par XOR sur l’intégralité des octets avant d’évaluer le résultat final, sans branchement conditionnel précoce ni retour anticipé. Confiance : 98 %