$course$/QCM de NSI/Terminale/Sécurisation des communications Chiffrement symétrique (clé secrète) et asymétrique (clés
publique/privée), fonctions de hachage cryptographiques,
signature numérique, certificats, protocole TLS, principes
fondamentaux de la cryptographie moderne.

]]> Sécurisation des communications — Q01 : Définition du chiffrement Que désigne précisément le chiffrement d'un message ?

]]> Cryptologie = cryptographie (chiffrement, signature) +
cryptanalyse (cassage des codes). Le terme « cryptage »
est un anglicisme à éviter en français : on dit
« chiffrement ».

]]> 1.0 0.0 0 true true abc La compression d'un fichier pour gagner de la place

]]> Erreur : la compression et le chiffrement sont des
opérations distinctes. La compression réduit la
taille, le chiffrement protège la confidentialité.

]]> La transformation du message clair en un message illisible sans la clé de déchiffrement

]]> Bonne réponse : le chiffrement protège la
confidentialité. Le message « clair » devient un
« chiffré » ou « cryptogramme ». Seul le détenteur
de la clé peut le déchiffrer.

]]> La signature d'un document

]]> Erreur : la signature numérique est une autre
opération cryptographique, qui garantit l'authenticité
(qui ?) et l'intégrité (a-t-il été modifié ?), pas la
confidentialité.

]]> La transformation du message en chiffres uniquement

]]> Erreur : confusion possible avec le mot « chiffres ».
Le chiffrement transforme un message en une forme
illisible sans la bonne clé, mais pas spécifiquement
en chiffres.

]]> Sécurisation des communications — Q02 : Chiffrement symétrique Qu'est-ce qu'un chiffrement symétrique ?

]]> AES (Advanced Encryption Standard) est aujourd'hui le
chiffrement symétrique le plus utilisé. Il chiffre par
blocs de $128$ bits avec des clés de $128$, $192$ ou
$256$ bits.

]]> 1.0 0.0 0 true true abc Un chiffrement où l'on utilise deux clés différentes : une publique et une privée

]]> Erreur : c'est la définition du chiffrement
asymétrique, pas symétrique.

]]> Un chiffrement où la même clé sert au chiffrement et au déchiffrement

]]> Bonne réponse : par exemple, AES, ChaCha20. La clé
doit être partagée entre l'expéditeur et le
destinataire avant l'échange. C'est rapide mais pose
le problème de la distribution de la clé.

]]> Un chiffrement qui ne nécessite aucune clé

]]> Erreur : un chiffrement sans clé serait facilement
déchiffrable par toute personne connaissant
l'algorithme. Ce serait un encodage, pas un
chiffrement.

]]> Un chiffrement qui inverse l'ordre des caractères

]]> Erreur : c'est une simple transposition, qui n'est
pas un chiffrement moderne (et ne nécessite pas de
clé).

]]> Sécurisation des communications — Q03 : Chiffrement asymétrique Quel est le principe du chiffrement asymétrique ?

]]> Le chiffrement asymétrique résout le problème de la
distribution des clés : pour qu'Alice envoie un message
chiffré à Bob, elle utilise simplement la clé publique
de Bob, qu'il a déjà publiée. Pas besoin d'échange
préalable secret.

]]> 1.0 0.0 0 true true abc Le message est chiffré et déchiffré avec la même clé

]]> Erreur : c'est la définition du chiffrement
symétrique.

]]> Deux algorithmes de chiffrement différents sont utilisés

]]> Erreur : « asymétrique » fait référence à
l'asymétrie des clés (publique vs privée), pas des
algorithmes.

]]> On utilise deux algorithmes simultanément pour plus de sécurité

]]> Erreur : aucun rapport. L'asymétrie concerne les clés.

]]> Une clé publique chiffre, une clé privée déchiffre, les deux sont mathématiquement liées

]]> Bonne réponse : on génère un couple (clé publique,
clé privée). La clé publique peut être diffusée
librement ; tout le monde peut chiffrer pour vous.
Seul le détenteur de la clé privée peut déchiffrer.

]]> Sécurisation des communications — Q04 : RSA Sur quelle difficulté mathématique repose la sécurité de
l'algorithme RSA ?

]]> RSA (Rivest-Shamir-Adleman, $1977$) est l'algorithme
asymétrique le plus connu. La sécurité dépend de la
taille de $N$ : aujourd'hui, on recommande au moins
$2048$ bits.

]]> 1.0 0.0 0 true true abc La difficulté de factoriser un grand nombre en ses facteurs premiers

]]> Bonne réponse : la clé publique contient le produit
$N = p \cdot q$ de deux grands nombres premiers. Si
on savait factoriser $N$ rapidement, on pourrait
retrouver la clé privée. Pour des $N$ de plusieurs
milliers de bits, c'est encore impossible avec les
ordinateurs classiques.

]]> La difficulté de calculer la racine carrée

]]> Erreur : la racine carrée se calcule en temps
polynomial. RSA repose sur d'autres problèmes.

]]> La difficulté de trier de grandes listes

]]> Erreur : le tri n'a aucun rapport avec RSA. Le tri
est un problème facile.

]]> La difficulté de calculer le produit de deux nombres

]]> Erreur : la multiplication est facile (polynomial),
c'est l'opération inverse qui est difficile.

]]> Sécurisation des communications — Q05 : Fonction de hachage Qu'est-ce qu'une fonction de hachage cryptographique ?

]]> Trois propriétés clés d'une fonction de hachage
cryptographique : (1) résistance à la pré-image
(inversion difficile), (2) résistance à la seconde
pré-image (trouver une autre entrée avec même
empreinte est dur), (3) résistance aux collisions
(trouver deux entrées avec même empreinte est dur).

]]> 1.0 0.0 0 true true abc Une fonction qui produit une empreinte de taille fixe à partir d'une entrée de taille quelconque, et qui est très difficile à inverser

]]> Bonne réponse : par exemple, SHA-$256$ produit toujours
une empreinte de $256$ bits. Deux entrées différentes
donnent (presque toujours) des empreintes différentes,
et il est computationnellement infaisable de
retrouver l'entrée à partir de l'empreinte.

]]> Une fonction réversible qui transforme tout texte en un texte de même taille

]]> Erreur : une fonction de hachage est précisément
non réversible, et la sortie a une taille fixe
quelle que soit l'entrée.

]]> Une fonction qui compresse un fichier sans perte

]]> Erreur : le hachage produit une empreinte, on ne
peut pas reconstituer le fichier d'origine. Ce n'est
donc pas une compression.

]]> Un type de chiffrement particulier

]]> Erreur : le hachage n'est pas un chiffrement (pas de
clé, pas de réversibilité). Ce sont deux primitives
différentes.

]]> Sécurisation des communications — Q06 : Signature numérique Quel rôle joue la signature numérique d'un document ?

]]> La signature numérique = empreinte du document chiffrée
avec la clé privée du signataire. Pour vérifier : on
déchiffre la signature avec la clé publique, on calcule
l'empreinte du document, et on compare. Si les deux
coïncident, signature valide.

]]> 1.0 0.0 0 true true abc Elle remplace le mot de passe

]]> Erreur : aucun rapport avec l'authentification par
mot de passe.

]]> Elle chiffre le document

]]> Erreur : la signature ne cache pas le contenu, elle
atteste de son origine et de son intégrité. Le
document peut être en clair tout en étant signé.

]]> Elle compresse le document

]]> Erreur : la signature ajoute des données (la
signature elle-même), elle n'en réduit pas.

]]> Elle prouve l'authenticité (qui a signé) et l'intégrité (le document n'a pas été modifié) du document

]]> Bonne réponse : la signature numérique fonctionne
avec la cryptographie asymétrique : on signe avec
sa clé privée, et n'importe qui peut vérifier
avec la clé publique correspondante. Toute
modification du document invalide la signature.

]]> Sécurisation des communications — Q07 : Rôle du TLS À quoi sert le protocole TLS sur le web ?

]]> TLS combine chiffrement symétrique (rapide pour le
gros des données), asymétrique (pour échanger la clé
symétrique), hachage et signatures. Versions modernes :
TLS $1.2$ et TLS $1.3$ ; les anciennes (SSL, TLS $1.0$,
TLS $1.1$) sont obsolètes et déconseillées.

]]> 1.0 0.0 0 true true abc À accélérer le chargement des pages

]]> Erreur : TLS introduit au contraire un léger
surcoût initial (établissement de la connexion).

]]> À rendre le site web compatible avec tous les navigateurs

]]> Erreur : TLS n'a pas de rôle de compatibilité. Son
rôle est la sécurité.

]]> À traduire les noms de domaines en adresses IP

]]> Erreur : c'est le rôle du DNS, pas de TLS.

]]> À sécuriser la communication entre un navigateur et un serveur web (chiffrement, authenticité)

]]> Bonne réponse : TLS (Transport Layer Security)
chiffre les données échangées en HTTPS et
authentifie le serveur via son certificat. Il
succède à SSL.

]]> Sécurisation des communications — Q08 : Certificat numérique Qu'est-ce qu'un certificat numérique (au sens de
X.$509$) ?

]]> Sans certificats, on aurait du mal à savoir si la clé
publique reçue appartient bien au site qu'on croit
visiter. Le système des autorités de certification (CA)
crée une chaîne de confiance : votre navigateur fait
confiance à quelques racines, qui signent les
certificats des sites.

]]> 1.0 0.0 0 true true abc Un système de paiement en ligne

]]> Erreur : aucun rapport avec le paiement.

]]> Un mot de passe long et compliqué

]]> Erreur : aucun rapport avec un mot de passe.

]]> Un fichier qui contient les empreintes de tous les utilisateurs

]]> Erreur : les certificats sont individuels, ils ne
contiennent pas de listes d'utilisateurs.

]]> Un document signé par une autorité de confiance qui associe une clé publique à une identité

]]> Bonne réponse : un certificat lie de manière vérifiable
une clé publique (par exemple celle d'un site web) à
une identité (example.com). La signature de
l'autorité de certification (CA) garantit l'authenticité
du lien.

]]> Sécurisation des communications — Q09 : Exemple historique de chiffrement symétrique Lequel des chiffrements suivants est un chiffrement
symétrique ?

]]> Autres chiffrements symétriques : ChaCha$20$, Twofish,
Serpent. Tous ont en commun l'utilisation d'une seule
clé secrète partagée entre les parties.

]]> 1.0 0.0 0 true true abc RSA

]]> Erreur : RSA est asymétrique (clé publique/clé
privée).

]]> ECDSA

]]> Erreur : ECDSA est un algorithme de signature
(asymétrique, à courbes elliptiques), pas de
chiffrement symétrique.

]]> Diffie-Hellman

]]> Erreur : Diffie-Hellman est un protocole d'échange
de clés, pas un chiffrement symétrique en lui-même.

]]> AES (Advanced Encryption Standard)

]]> Bonne réponse : AES est le standard moderne du
chiffrement symétrique. Il a remplacé DES et 3DES
en $2001$. Toujours largement utilisé en $2026$.

]]> Sécurisation des communications — Q10 : Exemple de chiffrement asymétrique Lequel des éléments suivants est un algorithme
asymétrique ?

]]> Autres asymétriques : ECC (cryptographie sur courbes
elliptiques), DSA, ElGamal. Le chiffrement asymétrique
est plus lent que le symétrique : on l'utilise donc
souvent uniquement pour échanger une clé symétrique,
qui sert ensuite au gros du chiffrement.

]]> 1.0 0.0 0 true true abc SHA-$256$

]]> Erreur : SHA-$256$ est une fonction de hachage,
pas un algorithme de chiffrement (et donc pas
asymétrique).

]]> AES

]]> Erreur : AES est un chiffrement symétrique (clé
unique partagée).

]]> RSA

]]> Bonne réponse : RSA est l'archétype des algorithmes
asymétriques. Sa clé publique chiffre, sa clé privée
déchiffre. Il sert aussi pour les signatures
numériques.

]]> ChaCha$20$

]]> Erreur : ChaCha$20$ est un chiffrement symétrique
moderne.

]]> Sécurisation des communications — Q11 : Chiffrement hybride Pourquoi TLS combine-t-il un chiffrement asymétrique et
un chiffrement symétrique (chiffrement « hybride ») ?

]]> AES sur $128$ bits offre un niveau de sécurité
équivalent à RSA sur environ $3000$ bits, mais bien
plus vite. C'est pour cela qu'on échange juste une clé
AES via RSA, puis qu'on chiffre les données avec AES.

]]> 1.0 0.0 0 true true abc Le chiffrement asymétrique est lent ; on l'utilise donc juste pour échanger une clé symétrique, puis on chiffre les vraies données en symétrique (rapide)

]]> Bonne réponse : on prend le meilleur des deux
mondes. L'asymétrique résout l'échange initial
(sans secret partagé préalable), le symétrique fait
le gros du chiffrement avec efficacité.

]]> Parce que le chiffrement symétrique est moins sûr

]]> Erreur : les deux sont sûrs avec des clés
adéquates. Le chiffrement symétrique est même plus
rapide à clés équivalentes.

]]> Pour respecter une réglementation européenne

]]> Erreur : c'est un choix purement technique, pas
réglementaire.

]]> Pour la beauté technique

]]> Erreur : c'est un choix d'ingénierie pour combiner
les avantages des deux approches.

]]> Sécurisation des communications — Q12 : Signature et hachage Pour signer un long document, on ne signe généralement
pas le document lui-même. Que signe-t-on à sa place ?

]]> Cette technique permet de signer rapidement même un
gros fichier (vidéo, ISO système). Les fonctions de
hachage modernes (SHA-$256$, SHA-$3$) calculent
l'empreinte d'un fichier de plusieurs gigaoctets en
quelques secondes.

]]> 1.0 0.0 0 true true abc L'empreinte (hash) du document, calculée par une fonction de hachage cryptographique

]]> Bonne réponse : on hache le document (par exemple
avec SHA-$256$) pour obtenir une empreinte de taille
fixe, puis on signe cette empreinte. C'est plus
rapide et tout aussi sûr (toute modification du
document change l'empreinte).

]]> Le mot de passe du signataire

]]> Erreur : aucun rapport avec un mot de passe. La
signature utilise la clé privée du signataire.

]]> Une partie aléatoire du document

]]> Erreur : on ne signe pas une partie aléatoire, ce
qui ne couvrirait pas tout le document.

]]> Le titre du document uniquement

]]> Erreur : signer le titre ne couvrirait pas le
contenu, donc ne protégerait pas l'intégrité.

]]> Sécurisation des communications — Q13 : Stockage des mots de passe Comment un site web bien conçu stocke-t-il les mots de
passe de ses utilisateurs ?

]]> Les fonctions de hachage classiques (SHA-$256$) sont
trop rapides pour les mots de passe : un attaquant peut
en tester des milliards par seconde sur GPU. Les
fonctions « lentes » comme bcrypt sont conçues pour
résister à ces attaques massives.

]]> 1.0 0.0 0 true true abc Sous forme d'empreinte (hash) calculée par une fonction de hachage adaptée (bcrypt, scrypt, Argon$2$), avec un sel unique

]]> Bonne réponse : on stocke seulement l'empreinte. À
la connexion, on hache le mot de passe saisi et on
compare. Le sel empêche les attaques par tables
précalculées (rainbow tables). Les fonctions
coûteuses (bcrypt) ralentissent les attaques par
force brute.

]]> Effacés après chaque connexion

]]> Erreur : il faudrait alors les redemander à chaque
fois, ce qui n'est pas pratique. Et le problème de
stockage subsisterait pour le mot de passe en
cours d'utilisation.

]]> Chiffrés avec une clé symétrique commune à tous les utilisateurs

]]> Erreur : si la clé est compromise, tous les mots
de passe le sont. De plus, on n'a pas besoin de
pouvoir déchiffrer les mots de passe.

]]> En clair dans la base de données

]]> Erreur : c'est une mauvaise pratique majeure. En
cas de fuite de la base, tous les mots de passe
seraient exposés.

]]> Sécurisation des communications — Q14 : Collisions Pourquoi est-il important qu'une fonction de hachage
cryptographique soit résistante aux collisions ?

]]> MD$5$ et SHA-$1$, autrefois standards, ne sont plus
considérés sûrs car des collisions ont été calculées
explicitement (Google, $2017$ pour SHA-$1$). Les
fonctions modernes recommandées sont SHA-$256$ et la
famille SHA-$3$.

]]> 1.0 0.0 0 true true abc Pour gagner de la place en mémoire

]]> Erreur : aucun rapport avec la mémoire. C'est une
propriété de sécurité.

]]> Pour éviter que deux documents différents puissent avoir la même empreinte, ce qui invaliderait les signatures numériques

]]> Bonne réponse : si on peut trouver deux documents
$A$ et $B$ ayant le même hash, on peut faire signer
$A$ par quelqu'un puis prétendre qu'il a signé $B$.
C'est une attaque par collision.

]]> Pour accélérer le calcul

]]> Erreur : la résistance aux collisions et la rapidité
sont des propriétés indépendantes (parfois en
tension : on veut « assez lent » pour les mots de
passe).

]]> Pour rendre le hash réversible

]]> Erreur : un hash cryptographique ne doit
précisément pas être réversible. La résistance
aux collisions est une autre propriété.

]]> Sécurisation des communications — Q15 : Authentification mutuelle En TLS, le serveur prouve son identité au client via
son certificat. Comment le client s'authentifie-t-il
auprès du serveur (cas usuel sur le web) ?

]]> TLS établit donc un « tunnel sécurisé » côté serveur ;
l'identification du client est ensuite la responsabilité
de l'application web. La double authentification (mot
de passe + code SMS ou TOTP) renforce cette étape.

]]> 1.0 0.0 0 true true abc Par mot de passe (ou autre secret) saisi sur la page sécurisée par TLS, après l'établissement du canal chiffré

]]> Bonne réponse : TLS ne fait par défaut
qu'authentifier le serveur. Le client est ensuite
identifié au niveau applicatif, généralement par
un mot de passe transmis dans le canal chiffré déjà
établi.

]]> Le client envoie aussi un certificat, automatiquement géré par le navigateur

]]> Erreur : la grande majorité des sites web n'exigent
pas de certificat client. C'est rare, réservé à des
contextes professionnels (banque, intranet
d'entreprise).

]]> Le client envoie son adresse email

]]> Erreur : l'email seul n'est pas une preuve
d'identité. Il sert d'identifiant, pas
d'authentificateur.

]]> Le client n'est jamais authentifié sur le web

]]> Erreur : il l'est, mais à un niveau supérieur (par
mot de passe, par exemple), pas par TLS.

]]> Sécurisation des communications — Q16 : Chiffrement de bout en bout Que signifie le chiffrement de bout en bout dans une
messagerie comme Signal ou WhatsApp ?

]]> Le chiffrement E$2$E est devenu la norme dans les
messageries modernes. Il a un coût : si on perd ses
clés, on perd l'accès à ses anciens messages. Mais il
offre une sécurité bien supérieure aux serveurs
« curieux ».

]]> 1.0 0.0 0 true true abc Le message est chiffré jusqu'au serveur, qui le déchiffre puis le rechiffre vers le destinataire

]]> Erreur : ce n'est pas du chiffrement « de bout en
bout ». Avec ce modèle, le serveur peut lire les
messages.

]]> Tous les messages sont automatiquement effacés

]]> Erreur : aucun rapport avec l'éphémérité.

]]> Le message est chiffré par l'expéditeur et ne peut être déchiffré que par le destinataire, le serveur lui-même ne peut pas le lire

]]> Bonne réponse : c'est précisément ce qui distingue
le chiffrement E$2$E. Même un serveur compromis ne
peut pas révéler le contenu des messages, faute de
clé.

]]> Le message est chiffré une fois sur l'ordinateur et une fois sur le téléphone

]]> Erreur : ce n'est pas la définition du E$2$E. Le
chiffrement reste basé sur des clés des utilisateurs,
pas sur la diversité des appareils.

]]> Sécurisation des communications — Q17 : Établir une clé sur un canal public Quel principe permet à deux personnes qui n'ont
jamais communiqué auparavant d'établir une clé
secrète commune sur un canal pourtant public ?

]]> L'échange asymétrique d'une clé symétrique est au
cœur du protocole HTTPS. Il combine la robustesse
de l'asymétrique (pas besoin de canal sûr
préalable) avec la rapidité du symétrique pour le
reste de la communication.

]]> 1.0 0.0 0 true true abc Utiliser un protocole asymétrique : chacun publie une clé publique, garde sa clé privée, et combine sa clé privée avec la clé publique de l'autre pour obtenir un secret partagé

]]> Bonne réponse : c'est l'apport fondamental de
la cryptographie asymétrique. Un attaquant
qui écoute le canal voit seulement les clés
publiques, ce qui ne lui permet pas de
retrouver le secret partagé.

]]> Chiffrer la clé avec elle-même

]]> Erreur : on aurait alors besoin de la clé pour
déchiffrer la clé. Ce n'est pas réalisable.

]]> Faire confiance au fournisseur d'accès Internet

]]> Erreur : la sécurité ne doit pas reposer sur
un acteur particulier du réseau.

]]> Envoyer la clé en clair, mais très rapidement

]]> Erreur : la vitesse d'envoi ne change rien à
l'interception possible.

]]> Sécurisation des communications — Q18 : HTTPS et confidentialité Quand vous visitez un site en HTTPS, qu'est-ce qui reste
visible pour votre fournisseur d'accès Internet (FAI) ?

]]> Pour aller plus loin (cacher même le site visité), il
faut utiliser un VPN ou Tor. DNS-over-HTTPS (DoH) ou
DNS-over-TLS (DoT) chiffrent la résolution DNS, mais
l'IP et le SNI restent visibles dans la plupart des
cas.

]]> 1.0 0.0 0 true true abc Rien du tout

]]> Erreur : HTTPS chiffre le contenu mais laisse
visible certaines métadonnées.

]]> Tout le contenu de la page que vous consultez

]]> Erreur : non, le contenu HTTP est chiffré par TLS.
Le FAI ne voit pas les requêtes ni les réponses.

]]> Le nom de domaine du site visité (via DNS et SNI), l'adresse IP, et le volume des échanges

]]> Bonne réponse : même en HTTPS, le FAI peut voir
quel site vous visitez (mais pas quoi vous y
faites précisément), à quelle heure, et combien de
données vous échangez.

]]> Vos identifiants de connexion uniquement

]]> Erreur : les identifiants sont chiffrés par TLS, le
FAI ne les voit pas.

]]> Sécurisation des communications — Q19 : Chiffrement de César Le chiffrement de César (décalage de chaque lettre
d'un certain nombre de positions dans l'alphabet) est-il
sûr ?

]]> Le César est facile à casser, mais il a une utilité
pédagogique : il introduit les notions de clé,
chiffrement, déchiffrement, cryptanalyse. La famille
des chiffrements par substitution est généralement
faible.

]]> 1.0 0.0 0 true true abc Non, il existe seulement $26$ clés possibles, donc on peut toutes les essayer en quelques secondes

]]> Bonne réponse : le chiffrement de César est un
exemple historique pédagogique mais pas un chiffrement
sérieux. L'analyse des fréquences ou la simple
énumération suffit à le casser.

]]> Cela dépend de la longueur du message

]]> Erreur : la sécurité du chiffrement de César ne
dépend pas de la longueur du message.

]]> Oui, il est très sûr s'il utilise un grand décalage

]]> Erreur : le décalage est borné par la taille de
l'alphabet ($26$ pour le français). Il y a donc
seulement $26$ clés possibles.

]]> Oui, à condition de changer la clé chaque jour

]]> Erreur : même avec changement quotidien, chaque jour
la clé peut être trouvée en quelques secondes.

]]> Sécurisation des communications — Q20 : Chiffrement de Vernam (masque jetable) Le chiffrement de Vernam (ou one-time pad) est :

]]> Limitation pratique : la clé doit être aussi longue que
le message et utilisée une seule fois (« one-time
pad »). Échanger des clés aussi longues que les
messages est rarement faisable, sauf pour des
communications très sensibles à très faible volume.

]]> 1.0 0.0 0 true true abc Un chiffrement faible facilement cassable

]]> Erreur : c'est en réalité le seul chiffrement
prouvé incassable mathématiquement. Mais il a
des contraintes pratiques.

]]> Le seul chiffrement prouvé incassable, à condition que la clé soit aléatoire, aussi longue que le message, et utilisée une seule fois

]]> Bonne réponse : Shannon a prouvé que ces conditions
sont nécessaires et suffisantes pour la sécurité
parfaite. Il a été utilisé pour le téléphone rouge
(ligne directe Washington-Moscou).

]]> Un type de signature numérique

]]> Erreur : c'est un chiffrement, pas une signature.

]]> Un chiffrement utilisé pour les SMS

]]> Erreur : aucun rapport avec les SMS.

]]> Sécurisation des communications — Q21 : Attaque par rejeu Dans une attaque par rejeu (replay attack) :

]]> Les protocoles modernes (TLS, SSH, etc.) intègrent des
protections anti-rejeu : numéros de séquence,
timestamps, nonces uniques. C'est crucial pour la
sécurité réelle.

]]> 1.0 0.0 0 true true abc L'attaquant change le contenu du message

]]> Erreur : c'est plutôt une attaque par modification
(interceptée par les codes d'authentification de
message, MAC).

]]> L'attaquant capture un message valide chiffré et le renvoie plus tard pour faire effectuer une action déjà autorisée

]]> Bonne réponse : sans mécanisme anti-rejeu (numéro
de séquence, horodatage, nonce), un attaquant peut
rejouer une transaction passée (par exemple, un
virement bancaire) sans même connaître la clé. Le
chiffrement seul ne protège pas contre cela.

]]> Le serveur tombe en panne

]]> Erreur : aucun rapport avec une panne.

]]> L'attaquant déchiffre tous les messages

]]> Erreur : le rejeu n'implique pas le déchiffrement.
C'est même son intérêt, l'attaquant n'a pas besoin
de connaître la clé.

]]> Sécurisation des communications — Q22 : Que faire avec une clé publique ? Alice veut envoyer un message confidentiel à Bob.
Bob a publié sa clé publique. Que doit faire
Alice ?

]]> Mémo : pour la confidentialité vers Bob, on
chiffre avec la clé publique de Bob. Pour
prouver qu'on est bien Alice, Alice signe
avec sa propre clé privée. Les deux usages
sont complémentaires.

]]> 1.0 0.0 0 true true abc Envoyer le message en clair, puisque Bob a une clé publique

]]> Erreur : la clé publique seule ne sécurise
rien. Encore faut-il que le message soit
chiffré avec.

]]> Envoyer la clé publique de Bob avec le message

]]> Erreur : la clé publique de Bob est… déjà
publique. Cela n'apporte aucune sécurité.

]]> Chiffrer son message avec la clé publique de Bob ; seul Bob, qui possède la clé privée correspondante, pourra le déchiffrer

]]> Bonne réponse : c'est l'usage de base du
chiffrement asymétrique pour la
confidentialité. La clé publique sert à
chiffrer, la clé privée à déchiffrer.

]]> Chiffrer son message avec sa propre clé privée

]]> Erreur : ce procédé existe mais correspond à
la signature (authentification de
l'émetteur), pas à la confidentialité.
N'importe qui pourrait déchiffrer avec la
clé publique d'Alice.

]]> Sécurisation des communications — Q23 : Que se passe-t-il si une clé fuite ? Dans un système de chiffrement asymétrique, si
la clé privée de Bob est volée par un
attaquant, quelle conséquence est correcte ?

]]> La sécurité d'un système asymétrique repose
entièrement sur la confidentialité de la clé
privée. En cas de compromission, on doit
révoquer la clé compromise et en générer une
nouvelle. C'est l'un des rôles des autorités de
certification.

]]> 1.0 0.0 0 true true abc L'attaquant peut déchiffrer tous les messages chiffrés à destination de Bob avec sa clé publique

]]> Bonne réponse : la clé privée est ce qui
permet de déchiffrer ; sa fuite compromet
immédiatement la confidentialité des messages
destinés à Bob. C'est pourquoi la clé privée
doit être protégée avec le plus grand soin.

]]> Il faut juste générer une nouvelle clé symétrique

]]> Erreur : la clé symétrique n'a aucun lien avec
la clé privée asymétrique compromise. Il faut
générer une nouvelle paire (publique, privée)
et faire republier la clé publique.

]]> L'attaquant peut chiffrer mais pas déchiffrer

]]> Erreur : c'est l'inverse, chiffrer se fait
avec la clé publique (que tout le monde
a) ; déchiffrer requiert la clé privée que
l'attaquant vient justement de voler.

]]> Aucune conséquence, puisque la clé publique reste secrète

]]> Erreur : la clé publique n'est pas
secrète, c'est précisément ce qui la
distingue de la clé privée. Et la fuite de
la clé privée est très grave.

]]> Sécurisation des communications — Q24 : Symétrique vs asymétrique Pour un même niveau de sécurité, quelle est la différence
de taille de clé entre un chiffrement symétrique (AES)
et un chiffrement asymétrique (RSA) ?

]]> Équivalences approximatives recommandées par le NIST :
AES $128$ ≈ RSA $3072$, AES $256$ ≈ RSA $15360$. Cela
explique en partie pourquoi le chiffrement asymétrique
est plus lent.

]]> 1.0 0.0 0 true true abc Les clés asymétriques sont beaucoup plus longues : AES $128$ bits ≈ RSA $3072$ bits

]]> Bonne réponse : la sécurité d'un chiffrement
symétrique de $n$ bits demande $2^n$ opérations à
l'attaquant (force brute). Pour un chiffrement
asymétrique, des algorithmes plus malins existent
(factorisation, log discret), donc il faut des clés
plus longues pour atteindre le même niveau.

]]> Les deux utilisent des clés de même taille

]]> Erreur : pour des raisons mathématiques, les clés
asymétriques doivent être beaucoup plus longues
pour offrir une sécurité équivalente.

]]> Aucun rapport entre les deux tailles

]]> Erreur : il y a un rapport établi par les meilleurs
algorithmes connus pour casser chaque type.

]]> Les clés symétriques sont plus longues

]]> Erreur : c'est l'inverse.

]]> Sécurisation des communications — Q25 : Sécurité et facteur humain Quel est généralement le maillon le plus faible dans la
sécurité d'un système ?

]]> Maxime de Bruce Schneier : « La sécurité est un
processus, pas un produit. » L'aspect humain
(formation, hygiène numérique, processus
organisationnels) est aussi crucial que les
algorithmes.

]]> 1.0 0.0 0 true true abc La taille de la clé

]]> Erreur : avec des tailles de clés modernes ($2048$
bits pour RSA, $256$ pour AES), aucune attaque par
force brute n'est faisable.

]]> Le facteur humain : ingénierie sociale, mots de passe faibles, hameçonnage, mauvaises configurations

]]> Bonne réponse : les meilleurs systèmes
cryptographiques sont contournés par des erreurs
humaines : mots de passe réutilisés, clic sur un
mail de hameçonnage, mots de passe collés sur un
post-it, mauvaise configuration de serveur. La
formation des utilisateurs est aussi importante que
la technique.

]]> Le langage de programmation

]]> Erreur : le langage n'est pas le problème principal,
même si certains langages aident à éviter des
vulnérabilités courantes (gestion de mémoire,
types).

]]> L'algorithme de chiffrement utilisé

]]> Erreur : les algorithmes modernes (AES, RSA, etc.)
sont très solides quand correctement utilisés. Les
attaques réussies passent presque toujours par
ailleurs.

]]> Sécurisation des communications — Q26 : Échange de clés Diffie-Hellman Le protocole de Diffie-Hellman ($1976$) résout
le problème suivant : deux personnes qui n'ont
jamais communiqué auparavant peuvent établir une
clé secrète commune sur un canal public, sans
qu'aucun observateur ne puisse la deviner. Sur
quelle propriété mathématique repose-t-il ?

]]> Diffie-Hellman est un jalon historique : il a
introduit l'idée d'échange de clé sans secret
partagé préalable, brisant un dogme millénaire de
la cryptographie. C'est encore aujourd'hui la
base de l'établissement des sessions TLS (en
version « éphémère » ECDHE pour la confidentialité
persistante).

]]> 1.0 0.0 0 true true abc La difficulté du problème du logarithme discret :
étant donné $g$, $p$ et $g^a \mod p$, il est
difficile de retrouver $a$

]]> Bonne réponse : Alice choisit $a$ secret et
envoie $g^a \mod p$ ; Bob choisit $b$ secret
et envoie $g^b \mod p$. Chacun calcule
ensuite $(g^b)^a = (g^a)^b = g^{ab} \mod p$,
qui est la clé commune. Un attaquant qui voit
$g^a$ et $g^b$ ne peut pas calculer $g^{ab}$
sans résoudre le logarithme discret, qui
n'a pas d'algorithme efficace connu.

]]> La difficulté de calculer une racine carrée

]]> Erreur : la racine carrée se calcule en temps
polynomial. La sécurité de Diffie-Hellman ne
peut donc pas reposer dessus.

]]> La difficulté de factoriser un grand nombre

]]> Erreur : c'est la base de RSA, pas de Diffie-
Hellman. Diffie-Hellman repose sur le
logarithme discret, qui est un autre problème
difficile (mais lié).

]]> Le simple secret du nombre $p$

]]> Erreur : $p$ est public dans Diffie-Hellman.
La sécurité repose sur le secret de $a$ et
$b$ (les exposants privés), pas sur celui de
$p$.

]]> Sécurisation des communications — Q27 : Authentification multi-facteur L'authentification multi-facteur (souvent appelée
« 2FA ») renforce la sécurité d'une connexion en
combinant plusieurs preuves d'identité. Sur quel
principe repose-t-elle ?

]]> L'authentification multi-facteur est l'une des
mesures les plus efficaces pour réduire les
attaques sur les comptes. Recommandée pour
tous les comptes sensibles (banque, mail, GAFAM).
Privilégier TOTP ou clé FIDO2 plutôt que SMS,
qui peut être intercepté.

]]> 1.0 0.0 0 true true abc Demander à l'utilisateur deux mots de passe
différents

]]> Erreur : deux mots de passe restent dans la
même catégorie (ce que l'on connaît).
L'attaquant qui hameçonne la victime obtient
les deux. La sécurité réelle vient de la
diversité des catégories.

]]> Chiffrer le mot de passe avant l'envoi

]]> Erreur : le chiffrement est déjà assuré par
HTTPS. L'authentification multi-facteur
ajoute une deuxième barrière, pas une
variante du mot de passe.

]]> Augmenter la longueur du mot de passe

]]> Erreur : augmenter la longueur (ou la
complexité) renforce la résistance à la
force brute, mais ne protège pas contre le
hameçonnage ou les fuites. Le multi-facteur
répond à un autre type de menace.

]]> Combiner deux facteurs de catégories
différentes : ce que l'on connaît (mot
de passe), ce que l'on possède (téléphone,
clé physique), ce que l'on est (empreinte,
visage). Compromettre un seul facteur ne
suffit alors plus à se faire passer pour
l'utilisateur

]]> Bonne réponse : la force vient du fait que
les facteurs sont indépendants. Un attaquant
qui obtient le mot de passe par hameçonnage
ne peut pas pour autant valider la
connexion, car il manque l'autre facteur
(téléphone, clé). Les modes courants : code
envoyé par SMS, code généré par application
(TOTP), clé physique (FIDO2), reconnaissance
biométrique.

]]> Sécurisation des communications — Q28 : Chiffrement et encodage On confond souvent chiffrement et encodage
(par exemple Base$64$). Quelle est la différence
fondamentale ?

]]> Erreur classique en pratique : « j'ai mis le mot
de passe en Base$64$, il est en sécurité ». Faux !
Base$64$ se décode en une commande
(base64 -d sous Linux). Pour la confidentialité,
il faut un véritable chiffrement (AES, par exemple)
avec une clé secrète. L'encodage est utile pour
d'autres raisons : transport, lisibilité,
compatibilité de format.

]]> 1.0 0.0 0 true true abc Le chiffrement utilise une clé secrète pour
rendre les données illisibles sans elle ;
l'encodage est une transformation
réversible publique (sans clé), qui ne
protège pas la confidentialité mais facilite
la transmission ou la représentation

]]> Bonne réponse : Base$64$ encode des octets en
caractères ASCII pour traverser des protocoles
texte (mail, URL). N'importe qui peut décoder
du Base$64$ : ce n'est pas un chiffrement.
Confondre les deux est une erreur fréquente
(et dangereuse) dans la pratique.

]]> L'encodage est un chiffrement plus rapide

]]> Erreur : ce n'est pas une question de
vitesse. Un encodage ne protège rien : il
ne suffit pas à rendre des données
confidentielles, même si lent.

]]> Le chiffrement est gratuit, l'encodage est
payant

]]> Erreur : aucune notion de coût financier
n'intervient dans cette distinction. C'est
purement technique.

]]> Le chiffrement transforme en lettres,
l'encodage en chiffres

]]> Erreur : la nature des caractères de sortie
(lettres, chiffres, symboles) ne joue aucun
rôle dans la définition. La distinction est
la présence ou l'absence d'une clé secrète.

]]> Sécurisation des communications — Q29 : Trace de RSA avec petits nombres On choisit deux nombres premiers $p = 5$ et
$q = 11$, donc $N = p \cdot q = 55$ et
$\varphi(N) = (p-1)(q-1) = 40$. On choisit
$e = 3$ (premier avec $40$). Alors
$d = 27$ vérifie $e \cdot d \equiv 1
\pmod{40}$ (car $3 \cdot 27 = 81 = 2 \cdot 40
+ 1$). Pour chiffrer $m = 4$ avec la clé
publique $(N, e) = (55, 3)$, on calcule
$c = m^e \mod N = 4^3 \mod 55 = 64 \mod 55$.
Quelle est la valeur du chiffré $c$ ?

]]> Cet exemple illustre concrètement le
principe de RSA. Avec de vrais nombres
premiers de plusieurs centaines de
chiffres, le calcul $m^e \mod N$ devient
coûteux pour quelqu'un qui ne connaît pas
$d$ (sauf à factoriser $N$, problème
réputé difficile). C'est cette
asymétrie entre la facilité du
chiffrement et la difficulté de la
factorisation qui fonde la sécurité de
RSA.

]]> 1.0 0.0 0 true true abc $9$

]]> Bonne réponse : $4^3 = 64$, et
$64 \mod 55 = 64 - 55 = 9$. Le message
chiffré est donc $9$. Pour vérifier le
déchiffrement avec la clé privée
$d = 27$, on calcule
$c^d \mod N = 9^{27} \mod 55 = 4$ (le
message original est bien retrouvé).
C'est l'identité d'Euler qui garantit
ce mécanisme : $m^{e \cdot d} \equiv m
\pmod{N}$ pour tout $m$ premier avec $N$.

]]> $12$

]]> Erreur de calcul : $4^3 = 64$, et
$64 - 55 = 9$, pas $12$. Vérifier
attentivement que $5 \cdot 11 = 55$,
pas autre chose.

]]> $64$

]]> Erreur : $64$ est la valeur de $m^e$
avant la réduction modulo $N$. Or
le chiffré doit appartenir à
$\{0, 1, \ldots, N-1\} = \{0, 1, \ldots, 54\}$.
Il faut donc appliquer le modulo : $64
- 55 = 9$.

]]> $4$

]]> Erreur : $4$ est le message clair, pas
le chiffré. Le chiffrement applique
l'opération $m^e \mod N$, qui transforme
$4$ en autre chose. Refaire le calcul :
$4^3 = 64$, et $64 \mod 55$ vaut $9$.

]]> Sécurisation des communications — Q30 : Chiffrement de Vigenère Le chiffrement de Vigenère consiste à
utiliser une clé de plusieurs lettres et
à décaler chaque lettre du message clair selon
la lettre correspondante de la clé (répétée
cycliquement). Avec la clé "BC" et le
message "HELLO", quel est le message
chiffré ?

]]> Vigenère a longtemps été considéré comme
« le chiffre indéchiffrable », jusqu'à ce
que Babbage et Kasiski montrent au $XIX^{e}$
siècle qu'il pouvait être cassé en
cherchant la longueur de la clé par
analyse des répétitions, puis en
appliquant l'analyse des fréquences sur
chaque sous-séquence. Aujourd'hui, c'est
un chiffre purement pédagogique.

]]> 1.0 0.0 0 true true abc "BCBCB" (la clé répétée)

]]> Erreur : la clé répétée n'est qu'un
intermédiaire de calcul, pas le
chiffré. On combine cette clé avec le
message clair pour produire le
chiffré.

]]> "HELLO" (la clé n'a aucun effet)

]]> Erreur : la clé décale bien chaque
lettre. Avec une clé non triviale, le
chiffré est obligatoirement différent
du clair.

]]> "IGMNO" (un décalage par lettre, mais avec un oubli sur la dernière)

]]> Erreur : le calcul est correct
jusqu'à l'avant-dernière lettre.
H+B (décalage de $1$) donne I,
E+C (décalage de $2$) donne G,
L+B donne M, L+C donne N.
Mais pour la dernière lettre, O+B
(décalage de $1$) donne P, pas
O. Le chiffré est donc "IGMNP",
pas "IGMNO".

]]> "IGMNP" (chaque lettre du clair
décalée selon la lettre correspondante
de la clé répétée)

]]> Bonne réponse : la clé "BC" est
répétée pour donner "BCBCB" à mettre
en correspondance avec "HELLO".
B correspond à un décalage de $1$
(car A = $0$, B = $1$), C à un
décalage de $2$. Donc :
H+1=I, E+2=G, L+1=M, L+2=N,
O+1=P. Résultat : "IGMNP". Vigenère
est plus solide que César car la même
lettre du clair peut être chiffrée
différemment selon sa position.

]]> Sécurisation des communications — Q31 : Cryptanalyse de César par fréquences On intercepte un long texte chiffré par
César (décalage inconnu). Dans le texte
français, la lettre 'E' est de loin la
plus fréquente (environ $17 \%$ des
occurrences). Dans le chiffré, la lettre la
plus fréquente est 'H'. Quel est, très
probablement, le décalage utilisé ?

]]> L'analyse des fréquences est une
attaque puissante contre tous les
chiffrements par substitution monoalphabétique
(où chaque lettre est toujours remplacée
par la même autre lettre). C'est ce qui
les rend tous obsolètes pour de vrais
usages cryptographiques. La parade
historique a été le chiffrement
polyalphabétique (Vigenère), puis les
chiffrements modernes (AES) qui
détruisent toute corrélation entre
fréquences du clair et du chiffré.

]]> 1.0 0.0 0 true true abc $3$ (vers la droite)

]]> Bonne réponse : si E (rang $4$ dans
l'alphabet, en comptant à partir de $0$)
a été chiffrée en H (rang $7$), le
décalage est $7 - 4 = 3$. C'est
d'ailleurs le décalage historiquement
attribué à Jules César. Pour
déchiffrer, on applique le décalage
inverse $-3$ (ou équivalent $+23$) à
chaque lettre du chiffré.

]]> $5$

]]> Erreur : un décalage de $5$
transformerait E en J, pas en H.
Calculer la différence entre la
position de la lettre la plus fréquente
du chiffré (H) et celle attendue
dans le clair (E).

]]> $7$

]]> Erreur : c'est la position de H dans
l'alphabet (A=0, ..., H=7), pas le
décalage. Le décalage est la
différence entre la position dans
le chiffré (H = $7$) et la position
dans le clair (E = $4$).

]]> $13$

]]> Erreur : $13$ est le décalage de
ROT$13$, qui transformerait E en R,
pas en H. ROT$13$ est cependant une
variante célèbre de César, utilisée
jadis sur Usenet pour cacher les
plaisanteries grivoises ou les
divulgations.

]]> Sécurisation des communications — Q32 : Signature numérique étape par étape Alice veut envoyer un document signé à Bob.
Quelle est la séquence correcte des
opérations effectuées par Alice (côté
émetteur) ?

]]> Pour la vérification, Bob applique
l'opération inverse : (1) il applique la
même fonction de hachage au document reçu
pour obtenir $h'$, (2) il déchiffre la
signature $s$ avec la clé publique
d'Alice pour obtenir $h$, (3) il compare
$h$ et $h'$. Si égaux : signature valide
(le document n'a pas été altéré et
l'expéditeur dispose bien de la clé
privée d'Alice). C'est sur ce principe
que reposent les certificats TLS, les
transactions bancaires sécurisées, et
les pièces d'identité électroniques.

]]> 1.0 0.0 0 true true abc Alice n'a rien à faire, sa signature est
ajoutée automatiquement par le système
d'exploitation

]]> Erreur : la signature numérique est un
processus actif qui demande la clé
privée d'Alice. Aucun système ne peut
signer à sa place sans accéder à cette
clé.

]]> Alice chiffre le document avec la clé
publique de Bob

]]> Erreur : c'est la procédure pour
assurer la confidentialité (Bob
seul pourra lire), pas pour signer.
Pour signer, il faut au contraire
utiliser la clé privée d'Alice, ce
qui prouve que c'est bien elle qui a
signé.

]]> Alice (1) calcule l'empreinte $h$ du
document avec une fonction de hachage
comme SHA-$256$, puis (2) chiffre cette
empreinte avec sa clé privée pour
obtenir la signature $s$, puis (3)
envoie le document accompagné de la
signature $s$

]]> Bonne réponse : signer = chiffrer
l'empreinte avec sa propre clé
privée. À la réception, Bob déchiffre
$s$ avec la clé publique d'Alice
(pour obtenir $h$), recalcule
l'empreinte du document reçu, et
compare. Si les deux empreintes
coïncident, la signature est valide.
La sécurité repose sur le fait que
seule Alice possède sa clé privée.

]]> Alice chiffre le document complet avec
sa clé privée

]]> Faux pour deux raisons. Première :
chiffrer avec sa clé privée ne sert
pas à protéger le document (n'importe
qui peut le lire avec la clé publique
d'Alice), mais à le signer. Deuxième :
on ne signe pas le document complet
mais seulement son empreinte, pour des
raisons de performance. Hacher un
fichier de plusieurs gigaoctets et
signer le hash est très rapide ;
chiffrer le fichier complet en
asymétrique serait extrêmement lent.

]]>