🌊 Chiffrement par flot : de RC4 (RIP) à ChaCha20 (le hipster de TLS)

Imagine une table en bois, trois pintes, et trois cryptographes qui refont le monde : le premier jure encore par RC4 (“il a tenu 20 ans, quand même !”), le second parle de Salsa20 avec des étoiles dans les yeux, et le dernier trinque en murmurant “ChaCha20 ou rien”.
Bienvenue dans la saga du chiffrement par flot — ce pan de la crypto qui a voulu faire vite, léger, élégant… et parfois un peu trop confiant.

⚙️ RC4 — L’algorithme qu’on a tous aimé avant de le haïr

Ah, RC4. Inventé par Ron Rivest en 1987 pour RSA Security, resté secret jusqu’à une fuite anonyme en 1994, et devenu la star des années 2000 dans WEP, SSL, TLS et MS-CHAP.
Un algorithme si simple qu’on pouvait l’implémenter sur un coin de nappe — et si fragile qu’il a fini en miette sous les analyses statistiques.

Le principe est enfantin : on garde un état interne, un tableau de permutation S de 256 octets, et deux index i, j. On échange, on XOR, et on obtient un keystream pseudo-aléatoire.
Formellement :

Key Scheduling Algorithm (KSA)

\text{for } i = 0 \text{ to } 255
\quad S[i] = i
j = 0
\text{for } i = 0 \text{ to } 255:
\quad j = (j + S[i] + K[i \bmod |K|]) \bmod 256
\quad {swap}(S[i], S[j])

Pseudo-Random Generation Algorithm (PRGA)

i = (i + 1) \bmod 256
j = (j + S[i]) \bmod 256
\text{swap}(S[i], S[j])
K = S[(S[i] + S[j]) \bmod 256]

Chaque octet du flux clair est ensuite chiffré par un simple XOR :
C_t = P_t \oplus K_t

Problème : RC4 n’est pas un vrai générateur uniforme. Les biais dans les premiers octets du flux sont légendaires, et les clés faibles pullulent. Dès 2001, Fluhrer, Mantin et Shamir démontrent la vulnérabilité de WEP.
Puis vint la série noire : Bar Mitzvah, RC4 NOMORE, et enfin la mise à mort officielle dans RFC 7465 (2015), interdisant RC4 dans TLS.

Moralité : quand ton keystream préfère certains octets aux autres, ce n’est plus un flot, c’est une fuite.

🌪️ Salsa20 — Le retour de la simplicité élégante

2005, Daniel J. Bernstein débarque. Il n’a pas aimé RC4, il n’aime pas les S-box compliquées, et il veut un algo “danse du flot”, d’où Salsa20.
L’idée ? Remplacer les tables par des additions, des rotations et des XOR (ARX : Add-Rotate-XOR). Tout tourne sur du 32 bits, sans cache ni branchement tordu.

L’état initial est une matrice 4×4 de mots de 32 bits :

Chaque round applique une quarter-round function sur quatre mots (a, b, c, d) :

Après 20 rounds (10 colonnes + 10 diagonales), on additionne l’état initial et on extrait le keystream.
La magie : pas de biais, pas de clé faible, pas de structure exploitable.
Salsa20 est d’une élégance rare — si pure que même Bruce Schneier a salué sa simplicité (“exactement ce qu’un processeur aime”).

Et contrairement à RC4, Salsa20 est toujours vivant : utilisé dans NaCl, libsodium, et les bibliothèques de crypto modernes.
Daniel Bernstein livrera ensuite une version plus chaotique encore : ChaCha20.

🌀 ChaCha20 — Le hipster de TLS

ChaCha20, c’est Salsa20 qui a découvert le cold brew et la RFC.
Introduit en 2008 par Bernstein, puis standardisé dans RFC 7539, il ajuste les rotations (16, 12, 8, 7 au lieu de 7, 9, 13, 18) pour améliorer la diffusion et la résistance aux attaques différentielles.

Sa fonction de round est donc :

Et comme pour Salsa, après 20 rounds, on additionne l’état initial.
Le résultat ? Un algorithme rapide sur CPU et sur mobile, constant-time, sans table ni branche.
Quand Google a proposé ChaCha20-Poly1305 pour remplacer AES-GCM sur terminaux mobiles, tout le monde a levé son verre : moins de failles, plus de perfs.
Adopté dans TLS 1.3, WireGuard, OpenSSH, QUIC — bref, le hipster s’est embourgeoisé.

Un petit extrait pseudo-code pour briller en société :

def chacha20_block(key, counter, nonce):
    state = constants + key + counter + nonce
    for i in range(10):
        quarter_rounds(state)
    return state + initial_state

Le secret du succès de ChaCha20 : aucune table, aucune surprise, juste de la belle arithmétique et un peu de sueur mathématique.

📊 RC4 vs Salsa20 vs ChaCha20

🍻 Conclusion — Du RC4 au ChaCha20 : le flot s’est clarifié

RC4, c’était la jeunesse insouciante : un XOR, deux index, et roule ma clé.
Salsa20, c’était la maturité : de la structure, de la diffusion, une vraie réflexion.
ChaCha20, c’est la version barbu-tatoué : performant, élégant, standardisé, et surtout toujours debout après 15 ans.

Entre temps, la crypto a appris une leçon : la simplicité n’est pas l’ennemie de la sécurité.
Ce qui compte, c’est la rigueur mathématique, la transparence et la vérifiabilité.

“La cryptographie n’échoue jamais. Ce sont les humains qui le font.” — Bruce Schneier, probablement entre deux bières.

Et si un jour vous tombez sur un serveur encore en RC4, souvenez-vous :
ce n’est pas un chiffrement, c’est un hommage posthume.

Références

• RFC 7465 – Prohibiting RC4 Cipher Suites
• RFC 7539 – ChaCha20 and Poly1305 for IETF Protocols
• D.J. Bernstein – Salsa20 specification (2005)
• D.J. Bernstein – ChaCha, a variant of Salsa20 (2008)
• AlFardan, Bernstein, Paterson et al. – On the Security of RC4 in TLS
• Fluhrer, Mantin, Shamir – Weaknesses in the Key Scheduling Algorithm of RC4 (2001)

Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com