Qu'est-ce que la cryptographie - Définition et panorama 2026

La cryptographie est l'ensemble des techniques mathématiques qui permettent de protéger l'information et de prouver son origine, même en présence d'un adversaire. Elle est invisible mais omniprésente : TLS quand tu charges un site en HTTPS, signatures GPG sur tes commits Git, chiffrement au repos de tes données cloud, passkeys qui remplacent tes mots de passe, signatures Cosign sur les images Docker. Ce guide pose les fondations : objectifs, primitives (symétrique, asymétrique, hashing, MACs, signatures), construction AEAD, PKI, post-quantum, et la règle d'or universelle - don't roll your own crypto.

1. Définition et positionnement

1.1 Le mot et ce qu'il recouvre

"Cryptographie" vient du grec kryptos (caché) et graphein (écrire). Historiquement : écriture secrète. Aujourd'hui, le terme recouvre bien plus large :

• Chiffrement : rendre un message illisible pour qui n'a pas la clé.
• Hachage : produire une empreinte courte, irréversible.
• Signatures : prouver qu'un message a été émis par le détenteur d'une clé privée.
• Authentification de messages (MAC) : vérifier qu'un message n'a pas été modifié.
• Échange de clés : partager une clé secrète sur un canal public.
• Zero-knowledge proofs : prouver qu'on sait quelque chose sans le révéler.
• Primitives avancées : chiffrement homomorphe, multi-party computation, post-quantum crypto.

1.2 Cryptographie vs cryptanalyse vs stéganographie

• Cryptographie : conception et usage des outils cryptographiques.
• Cryptanalyse : cassage de la cryptographie, étude des faiblesses.
• Stéganographie : cacher l'existence d'un message (vs cryptographie qui cache le contenu). Image avec message caché dans ses pixels = stéganographie.

Ces trois disciplines sont distinctes. L'offensive utilise les trois, la défensive principalement la cryptographie.

1.3 Positionnement cryptographie appliquée vs théorique

• Cryptographie théorique : conception des algorithmes, preuves mathématiques, recherche académique. Fait par des cryptographes de métier (Daniel Bernstein, Tanja Lange, Dan Boneh, Mihir Bellare, et quelques centaines d'autres dans le monde).
• Cryptographie appliquée : usage correct des primitives dans les systèmes réels. Fait par des ingénieurs, développeurs, architectes - toi et moi.

Cet article et cette catégorie sont sur le versant appliqué.

2. Les 5 objectifs de la cryptographie

Toute utilisation de cryptographie vise un ou plusieurs de ces buts :

2.1 Confidentialité

Personne ne peut lire le message sans la clé.

• TLS chiffre le trafic entre navigateur et serveur.
• AES-GCM chiffre les buckets S3 au repos.
• End-to-end encryption dans Signal/WhatsApp.

2.2 Intégrité

Personne ne peut modifier le message sans que ce soit détecté.

• HMAC sur un webhook prouve qu'il n'a pas été altéré en transit.
• SHA-256 d'une release vérifie qu'elle n'a pas été corrompue.
• Merkle trees dans Git détectent toute modification historique.

2.3 Authenticité

Le message provient bien de qui prétend l'avoir émis.

• Signature numérique (Ed25519) sur un certificat prouve l'émetteur.
• JWT signé par l'IdP prouve qu'il vient bien de l'IdP.
• Code signing d'un binaire prouve son éditeur.

2.4 Non-répudiation

L'émetteur ne peut nier avoir émis le message.

• Signature numérique Ed25519 = preuve juridique dans certains contextes (eIDAS).
• Git commits signés créent une trace attribuable à la clé GPG.
• Transactions blockchain sont non-répudiables par construction.

2.5 Anonymat / pseudonymat

L'identité de l'émetteur est masquée.

• Tor utilise plusieurs couches de chiffrement pour anonymiser la source.
• Signatures de groupe (group signatures).
• Zero-knowledge proofs révèlent une propriété sans révéler l'identité.

Plus l'objectif demande de garanties simultanées, plus le choix de primitives doit être fait consciemment.

3. Cryptographie symétrique

3.1 Principe

La même clé est utilisée pour chiffrer et déchiffrer. Alice et Bob partagent un secret avant de pouvoir communiquer.

Alice                                         Bob
  |                                             |
  | plaintext --[encrypt(K)]--> ciphertext -->  |
  |                                             |  ciphertext --[decrypt(K)]--> plaintext
  |                                             |

• Avantage : rapide (des centaines de Mo/s en logiciel, Go/s avec accélération matérielle AES-NI).
• Inconvénient : comment Alice et Bob partagent-ils la clé K en premier lieu ? C'est le problème de distribution des clés.

3.2 Block ciphers et stream ciphers

• Block ciphers : chiffrent par blocs de taille fixe (128 bits pour AES). Nécessitent un mode d'opération pour traiter des messages plus longs. Exemples : AES, Twofish, Serpent.
• Stream ciphers : chiffrent byte par byte. Plus naturels pour données streaming. Exemples : ChaCha20, Salsa20, RC4 (déprécié).

3.3 AES - le standard de facto

AES (Advanced Encryption Standard) standardisé par le NIST en 2001 (FIPS 197) après un concours public. Rijndael sélectionné.

• Tailles de clé : 128, 192, 256 bits. AES-128 suffit contre attaques classiques, AES-256 recommandé pour durée de vie longue et résistance pré-quantum.
• Taille de bloc : 128 bits.
• Intégré en hardware : instructions AES-NI depuis Intel 2010, ARM ARMv8, RISC-V. Vitesse proche du memcpy.

3.4 Les modes d'opération - le piège

Un block cipher seul ne chiffre qu'un bloc de 128 bits. Pour chiffrer plus long, on utilise un mode d'opération. Tous ne sont pas égaux :

Règle : si ton code utilise ECB ou CBC sans MAC, c'est un bug. Utiliser AES-GCM ou ChaCha20-Poly1305 par défaut.

3.5 ChaCha20-Poly1305 - l'alternative moderne

Créé par Daniel Bernstein. Stream cipher ChaCha20 + MAC Poly1305 = AEAD complet.

Avantages sur AES-GCM :

• Pas besoin d'accélération hardware pour être rapide.
• Meilleur sur mobile et embarqué.
• Plus simple à implémenter correctement en constant-time.
• Utilisé par TLS 1.3, WireGuard, Signal, libsodium.

AES-GCM et ChaCha20-Poly1305 sont équivalents en sécurité, le choix dépend de la plateforme.

4. Cryptographie asymétrique (à clé publique)

4.1 Principe

Chaque partie dispose d'une paire de clés :

• Une clé privée gardée secrète.
• Une clé publique partageable librement.

Propriété fondamentale :

• Ce qui est chiffré avec la clé publique ne peut être déchiffré qu'avec la clé privée correspondante.
• Ce qui est signé avec la clé privée peut être vérifié avec la clé publique.

Résout le problème de distribution des clés symétriques : Bob publie sa clé publique partout, Alice l'utilise pour chiffrer un message ou échanger une clé symétrique.

4.2 RSA

Premier système à clé publique déployé massivement (Rivest, Shamir, Adleman, 1977). Basé sur la difficulté de factoriser des grands nombres.

• Taille de clé en 2026 : 2048 bits minimum, 3072 ou 4096 recommandés.
• Usages : signatures (RSA-PSS), échange de clés (dépréciée au profit de ECDH), chiffrement direct (rare, préférer hybride).
• Perte de vitesse : RSA est lent, surtout pour signer (des milliseconds). Souvent combiné avec du symétrique.

RSA reste omniprésent (certificats TLS historiques, JWT RS256) mais cède progressivement la place aux courbes elliptiques.

4.3 Elliptic Curve Cryptography (ECC)

Basée sur le problème du logarithme discret sur les courbes elliptiques. Plus efficace que RSA à sécurité équivalente :

4.4 Les courbes modernes

Recommandation 2026 : Curve25519 (X25519) pour key agreement, Ed25519 pour signatures, sauf contraintes d'interopérabilité qui imposent P-256.

4.5 Usages pratiques

• TLS 1.3 : ECDHE avec X25519 ou P-256 pour échange de clé éphémère, puis AEAD.
• SSH : Ed25519 est le choix moderne pour les clés.
• JWT : RS256 (RSA) historique, ES256 et EdDSA modernes.
• Cosign : Ed25519 ou ECDSA pour signer les images.
• Signal Protocol : Curve25519 + Ed25519 pour le Double Ratchet.

5. Hash functions

5.1 Propriétés

Une fonction de hachage prend une entrée de taille arbitraire et produit une sortie de taille fixe. Propriétés recherchées :

• Déterministe : même input → même output.
• One-way : étant donné H(x), impossible de retrouver x.
• Collision-resistant : impossible de trouver x, y tels que H(x) = H(y).
• Avalanche : un bit de différence en input = moitié des bits différents en output.

5.2 Les familles principales

Par défaut en 2026 : SHA-256 pour signatures et fingerprints, BLAKE2 ou BLAKE3 pour performance.

5.3 Cas où NE PAS utiliser SHA comme hash

Mots de passe : un SHA-256 d'un mot de passe est calculé en microsecondes sur GPU. Des milliards de candidates testés par seconde. SHA seul = cassable par bruteforce.

Pour hasher des mots de passe, il faut des fonctions lentes et paramétrables :

• Argon2id : gagnant Password Hashing Competition 2015, recommandation 2026.
• bcrypt : historique, toujours acceptable mais paramétrage limité.
• scrypt : memory-hard, bon mais Argon2 meilleur.
• PBKDF2 : ancien mais toujours utilisé, minimum 600 000 iterations en 2026 (OWASP).

Paramétrisation Argon2id OWASP 2024 :

• m = 19 MiB, t = 2, p = 1 au minimum.

Règle : SHA pour fingerprints, KDFs spécialisés pour mots de passe.

6. Message Authentication Codes (MAC)

6.1 Principe

Prouve intégrité + authenticité d'un message. Nécessite une clé secrète partagée.

MAC(key, message) = tag

Le récepteur recalcule MAC(key, message) avec la même clé et compare au tag reçu.

6.2 HMAC - le standard

HMAC (Hash-based MAC) construit un MAC à partir d'une hash function. HMAC-SHA-256 = choix dominant.

Usages :

• Signature de webhooks (Stripe, GitHub, etc.).
• Validation de cookies de session serveur-side.
• Authentification dans JWT HS256 (secret partagé).
• Vérification d'intégrité dans protocoles custom.

6.3 HMAC vs signatures numériques

Pour une intégrité inter-services de confiance, HMAC suffit. Pour une preuve d'origine vers un tiers qui ne doit pas connaître le secret, signature.

7. AEAD - Authenticated Encryption with Associated Data

7.1 Le problème historique

Longtemps, chiffrement et authentification étaient séparés :

• Chiffrer un message (confidentialité).
• Calculer un MAC sur le ciphertext (intégrité).
• Transmettre les deux.

Problèmes :

• Nombreuses façons de se tromper (encrypt-then-MAC, MAC-then-encrypt, encrypt-and-MAC, seul encrypt-then-MAC est sûr).
• Padding oracle attacks (BEAST, Lucky 13, POODLE) quand mal implémenté.
• Deux clés à gérer (crypto et MAC).

7.2 La solution AEAD

AEAD combine chiffrement et authentification en une seule primitive :

AEAD.encrypt(key, nonce, plaintext, associated_data) -> ciphertext, tag
AEAD.decrypt(key, nonce, ciphertext, tag, associated_data) -> plaintext (or failure)

• associated_data : données authentifiées mais non chiffrées (en-têtes, metadata).
• tag : intégré au ciphertext dans la pratique.

Nonce (number used once) : doit être unique par clé. Jamais réutilisé ! La réutilisation de nonce casse GCM complètement.

7.3 AEAD standard 2026

• AES-GCM : AEAD basé sur AES-CTR + GHASH.
• ChaCha20-Poly1305 : AEAD basé sur ChaCha20 + Poly1305.
• AES-GCM-SIV : variant "synthetic IV" qui pardonne la réutilisation de nonce (utile quand générer un nonce unique est difficile).

Règle : chiffrer = AEAD. Jamais chiffrer sans authentification.

8. Signatures numériques

8.1 Principe

Alice possède une clé privée et une clé publique. Elle signe un message avec sa clé privée :

signature = Sign(private_key, message)

Bob vérifie la signature avec la clé publique d'Alice :

Verify(public_key, message, signature) -> true/false

Propriétés garanties :

• Authenticité : seule Alice avec sa clé privée peut signer.
• Intégrité : si le message change, la signature ne correspond plus.
• Non-répudiation : Alice ne peut pas nier avoir signé.

8.2 Algorithmes standard 2026

Ed25519 : rapide, petit (signature 64 octets), résistant aux side-channel, déterministe. C'est le standard moderne.

8.3 Usages pratiques

• Certificats X.509 : signés par une autorité de certification.
• Code signing : Microsoft Authenticode, Apple codesign, Cosign pour containers.
• Git commits / tags : GPG ou SSH signing.
• SSH keys : Ed25519 par défaut.
• JWT : RS256, ES256, EdDSA selon l'IdP.
• Blockchain : ECDSA ou EdDSA pour les transactions.

9. Échange de clés - Diffie-Hellman

9.1 Le problème

Alice et Bob veulent partager une clé symétrique sur un canal public (internet, observable par un attaquant). Comment ?

9.2 Diffie-Hellman (DH, 1976)

Alice choisit un secret a, calcule A = g^a mod p et envoie A à Bob (publiquement).

Bob choisit b, calcule B = g^b mod p et envoie B à Alice.

Alice calcule shared = B^a mod p, Bob calcule shared = A^b mod p. Les deux obtiennent le même nombre.

L'attaquant voit A et B mais ne peut pas calculer shared sans résoudre le logarithme discret (computationally infaisable).

9.3 ECDH - version moderne

Elliptic Curve Diffie-Hellman fait la même chose sur courbes elliptiques. Plus rapide, clés plus petites.

• X25519 (ECDH sur Curve25519) : standard moderne.
• ECDH P-256 : alternative NIST.

9.4 Ephemeral DH (DHE / ECDHE)

Clés DH générées à chaque session puis jetées. Propriété cruciale : Perfect Forward Secrecy (PFS). Même si la clé privée long-terme d'un serveur est compromise, les communications passées ne peuvent pas être déchiffrées.

TLS 1.3 impose ECDHE pour toutes les connexions.

10. PKI et certificats

10.1 Le problème d'authenticité des clés publiques

Alice veut communiquer avec bank.com. Le serveur présente une clé publique. Comment Alice sait que c'est vraiment celle de bank.com et pas celle d'un MITM ?

10.2 La solution PKI

Public Key Infrastructure : une autorité de certification (CA) signe un certificat qui associe un nom de domaine à une clé publique.

Certificat de bank.com :
  - Subject: bank.com
  - Public Key: <clé publique de bank.com>
  - Issuer: Let's Encrypt Authority X3
  - Signature: <signature de Let's Encrypt>

Alice vérifie la signature avec la clé publique de Let's Encrypt, qu'elle connaît (pré-installée dans son système / navigateur).

10.3 X.509 - le format standard

Tous les certificats TLS utilisent le format X.509. Champs clés :

• Subject : à qui appartient le cert.
• Issuer : qui a signé.
• Validité : notBefore / notAfter.
• Public Key.
• Subject Alternative Names (SANs) : liste des domaines couverts.
• Extensions : key usage, basic constraints, CRL distribution.

10.4 Let's Encrypt et ACME

Révolution 2016 : Let's Encrypt distribue des certificats TLS gratuits via le protocole ACME automatisé. Validité 90 jours, renouvellement automatique.

Résultat : HTTPS est passé de 50 % du web en 2016 à 95+ % en 2026.

10.5 Les défis PKI

• Trust store bloat : centaines de CAs de confiance par défaut, dont certaines ont été compromises historiquement (DigiNotar 2011, Symantec 2017).
• Certificate Transparency (CT) : logs publics immutables de tous les certs émis, pour détecter abus.
• Short-lived certificates : Let's Encrypt 90 jours, tendance à aller vers 7-30 jours.
• Automation : gestion de certs manuelle = incidents d'expiration. ACME + cert-manager obligatoires.

11. Random number generation

11.1 Pourquoi c'est critique

Toute la cryptographie repose sur de l'aléa imprévisible : clés, nonces, IVs, salts. Si l'aléa est prévisible, toute la sécurité s'effondre.

11.2 PRNG vs CSPRNG

• PRNG (Pseudo-Random Number Generator) : déterministe, reproduit la même séquence à partir d'une seed. Acceptable pour simulations, pas pour crypto.
• CSPRNG (Cryptographically Secure PRNG) : imprévisible même connaissant une partie de la séquence. Requis en crypto.

11.3 Sources système

Chaque OS expose une CSPRNG système :

• Linux : /dev/urandom (ou syscall getrandom()).
• Windows : BCryptGenRandom.
• macOS : SecRandomCopyBytes.

Langages modernes exposent des wrappers :

• Python : secrets.token_bytes(32).
• Go : crypto/rand.
• Node.js : crypto.randomBytes(32).
• Java : SecureRandom.
• Rust : rand::rngs::OsRng.

Règle : pour tout usage crypto, utiliser la CSPRNG système. Jamais Math.random(), rand() C, Random() Java (sans Secure).

11.4 Incidents historiques liés au random

• Debian OpenSSL (2008) : un patch réduit l'entropie à 15 bits. Des milliers de clés SSH et TLS déterministes. Désastre.
• Sony PS3 (2010) : ECDSA k réutilisé → clés privées extractibles.
• Android Bitcoin wallets (2013) : faille Java SecureRandom → vols de bitcoins.

Chaque incident démontre l'importance de l'aléa correct.

12. Don't roll your own crypto

12.1 La règle absolue

Ne jamais implémenter soi-même :

• Un algorithme de chiffrement.
• Un protocole cryptographique (handshake, key exchange).
• Un password hasher.
• Une signature scheme.

Utiliser des bibliothèques matures et auditées.

12.2 Pourquoi c'est critique

La cryptographie est contre-intuitivement piégeuse. Une implémentation qui passe les tests unitaires peut être totalement cassée :

• Side-channel attacks : timing, puissance, acoustique. Un branchement conditionnel sur bit secret peut révéler la clé.
• Implémentation non constant-time : memcmp sur des tokens = timing attack.
• Paramètres mal choisis : nonce répété, modes faibles, padding erroné.
• Compositions dangereuses : chiffrement sans authentification, PKE sans hybride.

Les cryptographes passent leurs carrières à trouver des bugs dans les implémentations existantes. Un développeur qui "juste écrit un petit chiffrement" est certain d'en introduire.

12.3 Bibliothèques recommandées 2026

Priorité : chaque écosystème a ses bibliothèques de référence, auditées et régulièrement mises à jour. Utiliser celles-là en exclusivité.

12.4 Les rares exceptions

Implémenter soi-même est acceptable dans deux cas :

1. Recherche académique : tu écris une preuve de concept dans un papier de recherche, avec supervision experte.
2. Plateforme sans bibliothèque : environnement embarqué ultra-contraint sans crypto lib disponible.

Dans les deux cas, audit par un cryptographe avant production.

13. Post-quantum cryptography - la transition en cours

13.1 La menace quantique

Un ordinateur quantique suffisamment puissant exécutant l'algorithme de Shor (1994) pourrait :

• Casser RSA en temps polynomial (factorisation).
• Casser ECDSA/ECDH en temps polynomial (log discret).

Les systèmes symétriques (AES, SHA) sont moins impactés - Grover divise la sécurité par 2 (AES-128 devient 64 bits = insuffisant, AES-256 reste 128 bits = OK).

13.2 Où en est-on

• 2024 : IBM Condor 1121 qubits, Google Willow 105 qubits avec correction d'erreur significative.
• Estimations : ordinateur quantique capable de casser RSA-2048 attendu entre 2030 et 2040, avec incertitude forte.
• Harvest now, decrypt later : adversaires étatiques stockent déjà du trafic chiffré pour le déchiffrer plus tard.

13.3 Les standards NIST 2024

Après 8 ans de concours, NIST a publié en août 2024 les premiers standards post-quantum :

• ML-KEM (FIPS 203) : ex-CRYSTALS-Kyber, pour key encapsulation.
• ML-DSA (FIPS 204) : ex-CRYSTALS-Dilithium, pour signatures.
• SLH-DSA (FIPS 205) : ex-SPHINCS+, signature hash-based (plus lente, alternative).

D'autres candidats (HQC, BIKE, Classic McEliece) en finalisation.

13.4 Déploiement en cours

• Cloudflare, Google Chrome : hybride X25519+Kyber pour TLS 1.3 depuis 2023-2024.
• Signal Protocol : PQXDH lancé en 2023.
• Apple iMessage PQ3 : protocole post-quantum depuis fin 2023.
• AWS KMS, Azure Key Vault : roadmap PQ en cours.

13.5 Ce qu'il faut faire en 2026

• Crypto agility : code qui permet de changer d'algorithme sans refactor majeur.
• Inventaire : quelles primitives utilise-t-on, quels protocoles, quelles lib ?
• Hybride : adopter progressivement les constructions hybrides (classique + PQ).
• Roadmap : alignement avec CNSA 2.0 (NSA) et ANSSI pour transition sur 5-10 ans.

13.6 CNSA 2.0 (NSA, 2022)

La NSA prescrit pour systèmes classifiés US :

• ML-KEM 1024 pour encapsulation.
• ML-DSA 87 pour signatures.
• AES-256 GCM.
• SHA-384 ou SHA-512.
• Transition obligatoire sur les systèmes NSS d'ici 2035.

ANSSI française prépare un guide équivalent.

14. Checklist cryptographie en pratique

Pour toute app ou service en 2026, vérifier :

Chiffrement en transit

• TLS 1.2 minimum, 1.3 recommandé
• Cipher suites modernes uniquement
• ECDHE obligatoire (PFS)
• HSTS avec preload
• Certificate pinning mobile

Chiffrement au repos

• AES-256-GCM pour volumes et données sensibles
• Clés gérées par KMS (AWS, GCP, Azure) ou HSM
• Envelope encryption pour données haute valeur

Mots de passe

• Argon2id avec paramètres OWASP 2024
• Salt unique par user (géré automatiquement par la lib)
• Jamais SHA/MD5/bcrypt sans cost factor

Authentification messages

• AEAD (AES-GCM, ChaCha20-Poly1305) partout
• HMAC-SHA-256 pour webhooks/cookies
• Nonces uniques garantis par design

Signatures

• Ed25519 par défaut, ES256 pour interop, RS256 legacy
• Clés privées en HSM ou KMS
• Rotation planifiée (12-24 mois)

PKI et certificats

• Let's Encrypt automatisé via cert-manager/ACME
• Monitoring expiration
• Certificate Transparency actif

Random

• CSPRNG système uniquement
• secrets.token_bytes, crypto.randomBytes, getrandom()

Bibliothèques

• Maintenues activement
• Mises à jour régulières
• Pas de crypto custom
• CVE monitoring

Post-quantum readiness

• Inventaire des primitives
• Crypto agility dans le design
• Plan de transition aligné CNSA 2.0 / ANSSI

15. Apprendre davantage

15.1 Livres pour ingénieurs

• Serious Cryptography (Jean-Philippe Aumasson, 2024 2nd ed) : la référence pour cryptographie appliquée.
• Real-World Cryptography (David Wong, Manning 2021) : excellent pour ingénieurs.
• Cryptography Engineering (Ferguson, Schneier, Kohno) : classique, toujours pertinent.

15.2 Livres pour approfondir

• Handbook of Applied Cryptography (Menezes, van Oorschot, Vanstone) : référence académique, gratuit en ligne.
• A Graduate Course in Applied Cryptography (Boneh, Shoup) : cours Stanford, gratuit.

15.3 Ressources en ligne

• Crypto 101 (Laurens Van Houtven) : introduction gratuite et claire.
• Cryptopals Challenges (cryptopals.com) : puzzles pratiques, apprendre en cassant.
• DJB's papers (cr.yp.to) : papiers de Daniel Bernstein, références pour Curve25519, ChaCha20, EdDSA.
• IACR eprint (eprint.iacr.org) : archives de recherche crypto.

15.4 Certifications

• Pas de certif dédiée cryptographie qui ait vraiment du poids.
• (ISC)² CISSP inclut un chapitre crypto de base.
• SANS FOR578 : threat intelligence, mais touche crypto.
• Formations dédiées : Cryptography Services @ NCC Group, Trail of Bits training.

16. Verdict et posture Zeroday

La cryptographie appliquée est invisible quand elle marche, catastrophique quand elle échoue. Ses règles sont stables depuis 20 ans, régulièrement redécouvertes par des développeurs qui réinventent les mêmes erreurs. La bonne nouvelle : 95 % des besoins cryptographiques en production sont déjà résolus par des bibliothèques matures. Ton job n'est pas d'inventer, c'est de choisir les bons outils et de les utiliser correctement.

Pour un développeur : maîtriser la checklist §14 et les règles de §12 "Don't roll your own crypto" protège contre la majorité des incidents. Pas besoin d'être cryptographe, juste d'être discipliné.

Pour un AppSec : savoir distinguer AES-CBC sans MAC vs AES-GCM, SHA-256 sur password vs Argon2id, PKCS1v15 vs PSS est le minimum vital. Ces distinctions passent dans 100 % des audits sérieux.

Pour une organisation : le chantier post-quantum s'impose sur 5-10 ans. Démarrer par l'inventaire des primitives et la crypto agility est une première étape prudente.

Pour approfondir : les prochains articles de la catégorie Cryptographie appliquée détailleront les sujets listés ici (TLS 1.3 hardening, PKI moderne, password hashing, KMS cloud, signing d'artefacts, post-quantum). Articles connexes existants : JWT : risques et bonnes pratiques pour la crypto dans JWT, gestion de session sécurisée, sécurité des workloads cloud pour le chiffrement au repos, secrets management cloud pour KMS.