Designing and evaluating a secure system

Don't roll your own crypto

A well-meaning developer sometimes says to themselves: "I'll invent my own encryption algorithm, that way no one will know how it works." This is one of the most dangerous mistakes in computer security. The rule, known to every expert, boils down to one phrase: don't roll your own crypto.

Why the flaws are invisible

Cryptography is a field where code can produce the right results on every test, and yet be completely broken. The flaws there are subtle and never show up in a classic functional test.

Here are the traps that lie in wait for the 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.

Each of these traps has, in real history, broken systems written by competent people. The attacker does not need to "break the math": they exploit the mistake next to it.

The strength of the standard

An algorithm like AES was:

designed by top-tier cryptographers;
submitted to thousands of experts over years;
attacked publicly in every imaginable way;
fixed with each flaw discovered.

Your weekend algorithm, on the other hand, has only been seen by you. The balance of forces is not comparable. Kerckhoffs's principle applies fully here: a public, battle-tested standard is worth more than a secret invention.

Good practice

The concrete rule comes down to two points:

Don't invent a primitive: never your own encryption, hashing, or signature algorithm.
Use audited libraries like libsodium or OpenSSL, which offer proven functions that are hard to misuse.

Designing is not the only mistake

It is not enough to use a good library, you also have to use it correctly. We distinguish:

designing an algorithm: reserved for specialists worldwide — not for you;
misusing a good algorithm: the most common trap, even with good tools (wrong mode, reused key, fixed nonce).

Wisdom consists of relying on solid building blocks and carefully reading their instructions.

In summary