🛠️ Ne pas réinventer ou recoder la crypto : bibliothèques éprouvées

Vous pensez pouvoir recoder la crypto ? Amis développeurs, parlons franchement. Vous êtes talentueux, vous codez des applis qui tournent, vous optimisez des boucles à coups de caféine et vous faites tenir des API avec du scotch et des promesses. Mais il y a un domaine où votre créativité n’est pas la bienvenue : la cryptographie maison.
Oui, toi qui penses : « je vais coder mon propre AES en PHP, ça sera plus léger que la lib OpenSSL »… Spoiler alert : tu viens d’écrire la prochaine CVE.

🚫 Pourquoi « recoder la crypto » est une mauvaise idée

La cryptographie, ce n’est pas comme refaire un bouton CSS ou un algorithme de tri. Ce n’est pas juste « quelques maths et un peu de logique ».
Les algorithmes modernes sont conçus par des équipes entières de chercheurs, testés pendant des années, et validés par la communauté scientifique. Si tu penses pouvoir reproduire ça en un week-end avec Stack Overflow et trois tutos Medium, j’ai une mauvaise nouvelle : tu viens de réinventer une passoire.

Exemple concret :

• En 2013, un développeur a créé une librairie JavaScript maison pour générer des nombres aléatoires. Manque de bol : ses nombres n’étaient pas aléatoires du tout. Résultat : clés prédictibles, système cassé.
• Autre perle : certains devs stockent des mots de passe avec md5($password.$salt). Résultat : rainbow tables toujours efficaces, attaques trivialement possibles.

Moralité : la crypto maison, c’est comme un avion en carton. Ça peut voler deux secondes, mais ça finit toujours par se crasher.

📚 Les bibliothèques éprouvées : vos meilleures amies

Heureusement, vous n’avez pas à coder tout ça vous-mêmes. Il existe des bibliothèques solides, maintenues, auditées et testées :

• OpenSSL : la référence pour C/C++, largement utilisée dans TLS/HTTPS.
• libsodium : moderne, simple à utiliser, intègre directement les bons choix par défaut. Disponible pour de nombreux langages (PHP, Python, Node.js, Go…).
• BouncyCastle : incontournable dans l’écosystème Java.
• NaCl (Networking and Cryptography Library) et ses implémentations (libsodium en est un dérivé).
• Microsoft CNG et les API .NET intégrées.

Ces bibliothèques ne sont pas seulement « pratiques », elles sont maintenues par des experts. Quand une faille comme Heartbleed survient, elles sont patchées rapidement. Si vous aviez écrit votre propre chiffrement en 2012, croyez-moi, vous n’auriez même pas vu passer le bug.

🧩 Les erreurs classiques des devs

Même quand ils utilisent la bonne lib, beaucoup de développeurs réussissent encore à tout casser. Voici un florilège :

1. Mode ECB d’AES
   Exemple d’horreur classique :openssl_encrypt($plaintext, 'aes-128-ecb', $key); Résultat ? Une jolie fuite d’information, car ECB chiffre chaque bloc de manière indépendante. Si tu chiffrages une image, tu obtiens… l’image chiffrée mais reconnaissable (Google « penguin AES ECB » pour traumatiser tes yeux).
2. IV fixe ou réutilisé
   L’IV (vecteur d’initialisation) doit être aléatoire et unique par chiffrement. Le fixer à 00000000 est une hérésie. Pourtant, on trouve encore ça dans le code source d’applis bancaires.
3. Random non sécurisé
   Utiliser rand() pour générer une clé ? Sérieusement ? C’est comme sécuriser une porte blindée avec un cadenas de vélo.
   👉 Utilisez random_bytes() en PHP, SecureRandom en Java, ou les équivalents fournis par vos libs.
4. Rejouer les erreurs du passé
   Certains développeurs adorent mélanger hash et chiffrement : « tiens, je vais hasher la clé avec SHA-1 et ensuite chiffrer avec AES en ECB ». Bravo, tu viens d’inventer un mécanisme que personne ne comprend et qui se casse en deux minutes.

🕹️ Exemple pédagogique : faire simple et solide

Prenons un cas concret en PHP avec libsodium, intégrée depuis PHP 7.2 :

Mauvais code (crypto maison, à fuir) :

function myEncrypt($data, $key) {
    return base64_encode(openssl_encrypt($data, 'aes-128-ecb', $key));
}

Problèmes : mode ECB, gestion des clés bidon, aucune authentification, bref… une catastrophe.

Bon code (libsodium) :

$key = sodium_crypto_secretbox_keygen();
$nonce = random_bytes(SODIUM_CRYPTO_SECRETBOX_NONCEBYTES);

$ciphertext = sodium_crypto_secretbox($message, $nonce, $key);

// Déchiffrement
$plaintext = sodium_crypto_secretbox_open($ciphertext, $nonce, $key);

• Algorithme solide (XSalsa20-Poly1305).
• Nonce aléatoire.
• Authentification intégrée.
• Pas besoin de choisir un mode : c’est sécurisé par défaut.

🔍 Anecdotes croustillantes

• Sony PlayStation 3 (2010) : la console a été hackée parce que les devs ont réutilisé une valeur aléatoire fixe pour signer le firmware. Résultat : les hackers ont pu générer leurs propres signatures valides.
• Appli bancaire en 2018 : chiffrement maison basé sur XOR et une clé fixe… découverte en clair dans le code source. Résultat : toutes les données clients exposées.
• Start-up blockchain : crypto maison « pour aller plus vite ». Résultat : vol de plusieurs millions parce que l’implémentation de l’ECDSA était cassée.

Moralité : la crypto maison coûte toujours plus cher que d’utiliser une bibliothèque éprouvée.

🧨 Les 3 règles d’or pour les devs

1. N’inventez rien. Utilisez une lib reconnue.
2. Ne choisissez pas les algos vous-mêmes. Fiez-vous aux recommandations (NIST, OWASP, ANSSI, ENISA).
3. Paranoïa utile. Si vous trouvez que votre code crypto est « ingénieux », relisez la règle n°1.

✅ Conclusion : faites confiance aux experts

Coder sa propre crypto, c’est comme bricoler son propre airbag avec des ballons de baudruche. Ça donne une illusion de sécurité, jusqu’au crash.
En 2025, il existe des bibliothèques matures, sûres, documentées, disponibles dans tous les langages. Vous n’avez aucune excuse pour jouer aux apprentis sorciers.

Alors, la prochaine fois que vous sentez l’envie de taper function myAES() { ... }, faites une pause, respirez, et tapez plutôt composer require paragonie/sodium_compat. Votre futur vous remerciera.

Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com