La cryptographie, ce n’est pas seulement AES, RSA et SHA256 lancés comme des incantations magiques. C’est aussi un univers de normes crypto, RFC, guides de bonnes pratiques et bibliothèques logicielles. Le problème ? Cette jungle est tellement dense que beaucoup abandonnent avant d’avoir trouvé leur chemin.
⚡ Sarcasme time : lire une RFC crypto sans préparation, c’est comme attaquer “À la recherche du temps perdu” de Proust en VO latine. On abandonne à la troisième page.
Pourtant, ces ressources existent pour une bonne raison : éviter que les développeurs réinventent la crypto façon “AES en PHP maison” (oui, ça arrive encore en 2025). Ici, on va cartographier les sources fiables pour que chacun sache où chercher, quoi lire, et surtout quoi ignorer.
🏛️ Les institutions qui dictent les règles
🇺🇸 NIST : le maître Jedi américain
Le NIST (National Institute of Standards and Technology) est la référence mondiale. C’est eux qui ont normalisé AES, SHA, RSA, et qui pilotent la transition vers la crypto post-quantique (PQCrypto).
- Documents phares : la série SP 800-xxx (800-38D pour AES-GCM, 800-131A pour l’obsolescence des algos).
- Exemple concret : l’annonce du passage à  SHA-3 et aux algos post-quantiques est directement pilotée par eux.
⚡ Sarcasme time : le NIST, c’est un peu comme le manuel officiel des règles de Monopoly. On peut ne pas aimer, mais si on veut jouer sérieusement, on s’y conforme.
🇪🇺 ANSSI : le garde du corps français
En France, l’ANSSI fournit des guides pratiques, audits de bibliothèques et recommandations officielles.
- Documents phares : le Référentiel Général de Sécurité (RGS), les guides sur TLS, PKI et mots de passe.
- Exemple concret : le guide ANSSI recommande d’abandonner SHA-1 depuis des années, mais certaines administrations ont attendu que Chrome bloque les certificats pour s’en apercevoir.
🌍 ETSI & ISO : la norme à l’échelle planétaire
- ISO/IEC 27000 : cadre global pour la sécurité de l’information.
- ETSI : normes européennes sur la signature électronique et eIDAS.
- Exemple concret : la signature électronique qualifiée en Europe repose sur ces standards → une facture signée doit être reconnue juridiquement de Paris à Varsovie.
⚡ Sarcasme time : l’ISO, c’est comme une encyclopédie. Passionnant si on a du temps, mais pour trouver la recette du gâteau, c’est plus rapide d’aller sur Marmiton.
📜 Les RFC : quand la crypto s’écrit en 300 pages
Les RFC (Request for Comments) sont les documents qui définissent les protocoles Internet. Certains sont incontournables pour la crypto :
- RFC 8446 : TLS 1.3, la base des communications sécurisées actuelles.
- RFC 8017Â : PKCS#1 (RSA cryptography).
- RFC 7748Â : courbes elliptiques modernes (X25519, Ed25519).
⚡ Sarcasme time : lire une RFC, c’est comme ouvrir un dictionnaire Klingon. Mais la bonne nouvelle, c’est que vous n’avez pas besoin de TOUT lire. Souvent, un résumé ou une implémentation sérieuse suffit.
👉 Exemple concret : un développeur qui veut implémenter TLS ne va pas réinventer TLS 1.3 en partant de la RFC. Il utilise OpenSSL, qui suit la RFC, et c’est très bien comme ça.
🔧 Les bibliothèques éprouvées : où coder sans se planter
Si vous êtes développeur, la règle est simple : ne jamais coder votre propre crypto. Vous n’êtes pas Turing. Utilisez une bibliothèque éprouvée :
- OpenSSL : la référence open source. Utilisé partout, mais parfois jugé complexe.
- libsodium : moderne, simple, haut niveau. Idéal pour éviter les erreurs de débutants.
- BouncyCastle : Java & C#, robuste et maintenu.
- Botan : alternative C++ propre et modulaire.
⚡ Sarcasme time : coder son propre AES en Python, c’est comme fabriquer son propre pacemaker avec des Legos. Techniquement faisable, mais je vous déconseille d’y faire confiance.
👉 Exemple concret : la faille Heartbleed (2014) n’était pas due à un mauvais algorithme, mais à une implémentation OpenSSL boguée. Preuve que même avec les bonnes bibliothèques, la vigilance reste cruciale.
🧰 Les bonnes pratiques pour s’y retrouver
🔍 OWASP : la bible des développeurs
L’OWASP Cryptographic Cheat Sheet est un concentré de recommandations claires :
- Quels algorithmes utiliser (AES-GCM, RSA-OAEP, Ed25519).
- Quels algos bannir (DES, RC4, MD5).
- Exemples de configuration TLS sécurisée.
⚡ Sarcasme time : OWASP, c’est un peu le “mode d’emploi IKEA” de la crypto. Sans ça, vous finissez avec une bibliothèque montée à l’envers et une clé Allen en trop.
👩‍💻 GitHub et la communauté
De nombreux projets maintiennent des guides et exemples :
- Dépôts officiels des bibliothèques.
- Exemples de configurations sécurisées.
- Outils comme testssl.sh pour auditer vos serveurs TLS.
📉 Ce qu’il faut ignorer absolument
Dans la jungle, il y a aussi des plantes vénéneuses :
- Les blogs obscurs proposant “AES maison en PHP”.
- Les tutos YouTube de 3 minutes “Comment créer son VPN avec RC4” (oui, ça existe).
- Les forums qui recommandent encore “SHA-1 est suffisant”.
⚡ Sarcasme time : croire un forum obscur sur la crypto, c’est comme confier sa santé à un influenceur TikTok qui vend du jus de céleri comme vaccin.
âś… Conclusion : apprivoiser la jungle crypto
La cryptographie peut sembler effrayante avec son jargon, ses RFC interminables et ses guides de 400 pages. Mais en réalité :
- Les normes officielles (NIST, ANSSI, ISO, ETSI) dictent les règles du jeu.
- Les RFC expliquent les protocoles, mais vous n’êtes pas obligé de les lire intégralement.
- Les bibliothèques éprouvées (OpenSSL, libsodium, BouncyCastle) existent pour vous éviter les pièges.
- Les guides pratiques (OWASP, GitHub, ANSSI) traduisent tout ça en recettes digestes.
👉 Punchline finale : La crypto n’est pas une secte de mathématiciens fous. C’est un outil vital, balisé par des normes et guides. Le vrai danger n’est pas de s’y perdre… mais de croire qu’on peut s’en passer.
