Ne réinventez pas la crypto

Un développeur bien intentionné se dit parfois : « Je vais inventer mon propre algorithme de chiffrement, comme ça personne ne saura comment il marche. » C'est l'une des erreurs les plus dangereuses en sécurité informatique. La règle, connue de tous les experts, tient en une formule : don't roll your own crypto — n'écris pas ta propre crypto.

Pourquoi les failles sont invisibles

La cryptographie est un domaine où le code peut produire les bons résultats à tous les tests, et pourtant être totalement cassé. Les failles y sont subtiles et n'apparaissent jamais dans un test fonctionnel classique.

Voici les pièges qui guettent l'amateur :

  PIEGE                    | CE QUI SE PASSE
 --------------------------+-------------------------------------------
  Canaux auxiliaires       | Le temps de calcul ou la consommation
  (side channels)          | electrique trahit la cle, sans casser
                           | le moindre chiffre.
 --------------------------+-------------------------------------------
  Mauvais aleatoire        | Utiliser rand() au lieu d'un generateur
                           | cryptographique rend les cles previsibles.
 --------------------------+-------------------------------------------
  Erreurs d'implementation | Un decalage d'un octet, un padding mal
                           | verifie, une comparaison non constante...
 --------------------------+-------------------------------------------
  Reutilisation d'un nonce | Reutiliser un vecteur d'initialisation
                           | peut reveler tout le message.

Chacun de ces pièges a, dans l'histoire réelle, cassé des systèmes écrits par des gens compétents. L'attaquant n'a pas besoin de « casser les maths » : il exploite l'erreur d'à-côté.

La force du standard

Un algorithme comme AES a été :

• conçu par des cryptographes de premier plan ;
• soumis à des milliers d'experts pendant des années ;
• attaqué publiquement de toutes les manières imaginables ;
• corrigé à chaque faille découverte.

Votre algorithme du week-end, lui, n'a été vu que par vous. Le rapport de force n'est pas comparable. Le principe de Kerckhoffs joue ici pleinement : un standard public et éprouvé vaut mieux qu'une invention secrète.

La bonne pratique

La règle concrète tient en deux points :

1. N'inventez pas de primitive : jamais votre propre algorithme de chiffrement, de hachage ou de signature.
2. Utilisez des bibliothèques auditées comme libsodium ou OpenSSL, qui offrent des fonctions éprouvées, difficiles à mal employer.

Concevoir n'est pas la seule erreur

Il ne suffit pas d'utiliser une bonne bibliothèque, encore faut-il l'utiliser correctement. On distingue :

• concevoir un algorithme : réservé aux spécialistes du monde entier — pas pour vous ;
• mal utiliser un bon algorithme : le piège le plus courant, même avec de bons outils (mauvais mode, clé réutilisée, nonce fixe).

La sagesse consiste à s'appuyer sur des briques solides et à lire attentivement leur mode d'emploi.

En résumé

Ne concevez jamais votre propre primitive cryptographique : les failles y sont invisibles aux tests ordinaires (canaux auxiliaires, mauvais aléatoire, erreurs d'implémentation). La crypto standardisée a été éprouvée par des milliers d'experts. Utilisez des bibliothèques auditées comme libsodium, et distinguez « concevoir un algorithme » (à proscrire) de « mal utiliser un bon algorithme » (à éviter par une lecture attentive).