Make GEA Great Again : comprendre un LFSR sans se noyer dans les bits

Cette note propose une lecture théorique du challenge Make GEA Great Again, classé en cryptographie sur Hackropole. Ce n’est pas une solution officielle ni une copie de write-up : l’objectif est de comprendre le mécanisme intellectuel que ce type d’épreuve cherche à faire manipuler.

L’idée en une image

Un LFSR est une règle de dominos : chaque nouveau bit est le XOR de quelques anciens. La suite paraît complexe, mais elle obéit à une récurrence linéaire.

Le niveau « hardcore » ne vient généralement pas d’une formule isolée. Il vient de la nécessité de reconnaître quelle structure est exposée, puis d’écarter tout ce qui n’influence pas réellement le secret.

Le modèle mathématique

Sur GF(2), s_=Σ c_i s_. Avec assez de bits consécutifs, Berlekamp–Massey retrouve la plus courte récurrence ; les combineurs non linéaires demandent ensuite corrélation, approximation ou résolution booléenne.

La première discipline consiste à écrire les objets avec leur domaine : entiers, classes modulo un nombre, vecteurs sur un corps fini ou octets. Une grande partie des bugs de raisonnement vient d’une opération effectuée dans le mauvais espace.

Ce qu’il faut repérer

• Une suite binaire longue ou du keystream connu
• Des polynômes de rétroaction
• Plusieurs registres combinés par une fonction booléenne

Ces indices ne prouvent pas encore une attaque. Ils servent à former une hypothèse testable : « si ce modèle est le bon, quelle valeur intermédiaire devrais-je pouvoir prédire ? »

Démarche d’analyse

1. Normaliser l’ordre temporel et l’ordre des bits.
2. Tester la complexité linéaire de la suite.
3. Retrouver la récurrence sur un échantillon puis prédire hors échantillon.
4. Étudier biais et corrélations du combineur.

À chaque étape, conserver un petit test connu. Un script qui produit un résultat plausible mais non vérifié est plus dangereux qu’une équation incomplète : il donne l’impression d’avancer.

Pourquoi le challenge devient difficile

Une épreuve avancée superpose souvent plusieurs couches : parsing, encodage, protocole et primitive. La bonne stratégie consiste à construire des invariants. Une taille doit rester constante, un point doit satisfaire son équation, une signature doit se vérifier, un état prédit doit reproduire plusieurs sorties jamais utilisées pendant l’analyse.

On peut formaliser ce réflexe ainsi :

1. Observer une relation stable.
2. Modéliser cette relation avec le moins d’hypothèses possible.
3. Prédire une nouvelle valeur.
4. Valider la prédiction sur des données indépendantes.

Fausses pistes classiques

• Inverser MSB et LSB.
• Confondre période maximale et sécurité cryptographique.
• Appliquer Berlekamp–Massey directement à une sortie non linéaire.

La difficulté utile d’un challenge n’est pas de lancer tous les outils disponibles. Elle est de savoir quelle propriété chaque outil teste et ce qu’un échec permet réellement de conclure.

Ce que l’architecte sécurité doit en retenir

Une grande période ne remplace ni la non-linéarité robuste ni une primitive de flot standard.

La crypto échoue rarement parce que l’algorithme central est totalement inconnu. Elle échoue aux frontières : génération d’aléa, réutilisation d’état, encodage, validation, gestion des erreurs et composition avec le protocole.

Pour aller plus loin

Reprendre le challenge en construisant d’abord un modèle miniature avec de petits paramètres. Une fois l’intuition vérifiée, remplacer progressivement les jouets par les vraies tailles. C’est plus lent pendant dix minutes et beaucoup plus rapide pendant les trois heures suivantes.