This is fine

On avait une liste de polynômes entiers (de degré 16 et avec des nombres très grands), un par lettre du flag. Pour chaque polynôme , il fallait trouver un entier tel que avec . Ça semble compliqué à première vue (il y a beaucoup de à tester), mais il y a une astuce. Décomposons :

Par conséquent, est un diviseur de (ou son opposé). Comme il n’y a que 256 valeurs de possibles, on peut donc les énumérer, et pour chacune énumérer les diviseurs de , et regarder si un de ces nombres satisfait (ou ). Ça se fait très bien avec sympy.

Convolu-quoi ?

Le flag était d’abord décomposé en une séquence binaire, puis on regardait une fenêtre glissante de 8 bits sur cette séquence et on enregistrait deux valeurs à chaque offset : la parité de state & G0 et celle de state & G1 avec G0 et G1 deux uint8s. On nous donnait le résultat de cette convolution.

On pouvait donc simplement deviner les bits du flags les uns après les autres, en essayant d’ajouter un 0 ou un 1 et en regardant si ça correspondait avec le flag encodé. Il y avait sûrement plus malin et efficace mais ça suffisait largement.

Maintenant, l’ESP !

En ouvrant le fichier avec wireshark, il m’a sauté aux yeux que le dernier octet des premiers blocs data.data formaient FCSC. J’ai commencé par sélectionner tous ces blocs avec

tshark -r capture.pcapng -e data.data -Tfields | cut -c25-26 | tr -d '\n' | xxd -r -p

J’ai obtenu un flag avec semble-t-il toutes les lettres en doubles, mais en les dédoublant j’ai obtenu un flag invalide. En regardant de plus près les échanges, ils étaient bidirectionnels : probablement un message et sa confirmation. Or, certains paquets manquaient : parfois le message, et parfois sa confirmation (mais jamais les deux heureusement). J’ai donc dédoublé les lettres à la main, ce qui m’a probablement pris plus de temps que d’écrire un script pour ce faire mais avait l’avantage de ne pas demander de réfléchir.

Tortoise Say

J’adore ce genre d’épreuves. On avait un enregistrement réalisé par un analyseur logique de la programmation d’un écran e-ink et il fallait retrouver ce qui était affiché à l’écran.

J’ouvre le fichier vcd avec Pulseview, j’ajoute un décodeur SPI (comme suggérait la doc de l’écran) en associant les bonnes bornes aux bon fils, et ça me décode les octets.

J’enregistre les octets dans un fichier que j’analyse avec Python.

Visuellement, Pulseview montrait aussi des pulses d’activité à intervalles réguliers, j’ai interprété ça comme des frames. En comptant le nombre d’octets par frames, ça faisait à peu près le nombre de pixels de l’écran (ou peut-être deux fois ce nombre je crois), ce qui a confirmé mon intuition. J’ai donc créé un tableau de la taille de l’écran et l’ai rempli avec les valeurs des octets, puis affiché avec matplotlib. Il a fallu que je m’y reprenne à plusieurs fois pour gérer le petit-endian (ou grand endian) et le sens de remplissage.

Transport me too

Pareil, une épreuve que j’ai beaucoup aimée. On avait accès à une carte de transport de STMicroElectronics, et il fallait lui envoyer des commandes pour lui permettre de faire 1000 voyages alors qu’elle n’en autorisait normalement qu’un maximum de 5.

Il suffisait de télécharger la documentation de la carte sur le site de STM, qui expliquait le format des commandes à envoyer pour lire et écrire dans les registres de la carte. Ils donnaient même un fichier C implémentant le code de vérification utilisé à chaque message, que j’ai traduit en Python.

Ce qui m’a fait lire la doc plusieurs fois, c’est que certains registres n’étaient débloqués en écriture qu’une fois après avoir modifié d’autres registres, et que ces registres-là n’étaient modifiables que vers le bas (une fois un 0 écrit c’était définitif). Il fallait donc faire un petit jeu de modifier tel registre pour débloquer tel autre pour pouvoir voyager 32 fois de plus, et de faire ça autant de fois que nécessaire pour arriver à 1000.

Times Square

C’était une connexion ssh qui ne donnait un message que si la taille du terminal était suffisamment grande. Même avec la fonte la plus petite, impossible de créer une taille suffisamment grande en redimensionnant la fenêtre. Heureusement il existe une commande stty cols 50000 rows 40000 qui aide à définir une taille arbitraire. Mais du coup le message était affiché au milieu de la fenêtre, hors de l’écran. Là je pense qu’il y avait peut-être une meilleure méthode, mais j’ai pipé la connexion ssh dans un fichier pour le lire (un peu laborieusement). Impossible de me souvenir comment j’avais fait pendant la compétation, mais là en m’y repenchant au calme j’ai écrit un script pour parser les codes d’affichage en les changeant pour les faire rentrer dans une fenêtre de taille raisonnable.

Ça donnait donc la condition un peu énigmatique suivante : X + Y + t = 42 && X > 300 && Y > 200 (t était un compteur de secondes qui commençait à 0 quand on se connectait). Mais comme ces valeurs sont sur 16 bits, il suffisait de sommer à 2^16 + 42 : stty cols 50000 rows 15578 et le flag était affiché à la première seconde.

Tunnel routier (1/2)

J’ai bien galéré sur cette épreuve, je crois que c’est parce que j’y ai travaillé pendant une coupure du service, ce qui faisait que la connexion ne me retournait absolument rien et je croyais que c’était ma faute.

Les infos utiles étaient volontairement dissimulées dans l’énoncé, avec des formulations vagues comme « un protocole industriel sur le port TCP/502 ». Wikipedia m’apprend que le port 502 est en général utilisé pour le protocole Modbus, qui semble complètement approprié pour gérer un automate tel que décrit dans l’épreuve. Je télécharge donc pymodbus qui me permet de me connecter.

L’énoncé disait qu’un token était caché dans les données d’identification de l’automate, un coup d’œil à l’API de pymodbus m’indique une fonction read_device_information qui me semble prometteuse, bingo.

J’ai pas réussi à faire la partie 2 qui semblait être plus intéressante.

FizzBuzz (1/2 et 2/2)

J’ai vraiment aimé ces deux épreuves, qui consistaient simplement à programmer le programme classique FizzBuzz en assembleur. Dans la deuxième épreuve, on n’avait pas le droit au modulo ni à la division (des instructions assez naturelles pour programmer FizzBuzz), donc j’ai implémenté un modulo à la main avec des soustractions, avant de me rendre compte qu’il fallait être un peu efficace parce qu’on était limité à 65536 cycles de processeur (c’est un peu short pour un FizzBuzz jusqu’à 1000, sans modulo, si on ne fait pas un peu attention). J’ai vraiment adoré écrire ces programmes et les optimiser.

Las Vegas Baby

Ahh, peut-être mon épreuve préférée, en tout cas la plus dure que j’ai résolue (on est seulement 25 à l’avoir réussie) et rien à voir avec de la cybersécurité (mais ça change un peu et c’est rafraîchissant). On avait l’énoncé suivant :

Vous êtes à Las Vegas, en plein tournoi de poker Texas Hold’em. Tous les joueurs sont partis en pause, et vous vous retrouvez seul avec le paquet de cartes et votre conscience. L’envie vous prend alors de tricher.

Cependant, la tâche n’est pas si facile: le croupier coupe le deck à une position aléatoire avant la distribution des cartes. Il vous faut alors être malin pour que la distribution vous donne le meilleur jeu, quel que soit la coupe effectuée par le croupier. De plus, vous savez que vous allez être à la petite blinde, mais ne savez pas encore si il y aura 3 ou 4 joueurs après la pause.

Votre objectif est de trier le paquet de carte de manière à être certain de gagner la prochaine main.

C’est original et amusant ! J’ai vu ça comme un problème d’optimisation / de programmation par contraintes. Pour la programmation par contraintes ou la satisfiabilité, ça m’aurait demandé d’implémenter les mains de poker en un langage de contraintes et ça avait l’air pénible, je n’avais pas envie de m’infliger ça. Idem pour l’optimisation ILP. J’ai donc décidé de prendre la fonction d’évaluation des mains comme une boîte noire, et d’utiliser une méta-heuristique, celle avec laquelle je suis le plus familier, soit le recuit simulé. C’est une méthode particulièrement adaptée aux problèmes où l’on peut transformer graduellement un état en un autre (un état étant ici un deck, qu’on peut réordonner petit à petit).

À chaque étape, on propose un changement aléatoire et assez élémentaire à l’état (par exemple, échanger deux cartes prises au hasard dans le deck). Ce changement peut faire augmenter ou diminuer le score (le nombre de mains remportées). Si ça améliore le score on garde le changement, et si ça rend le score moins bon on le garde avec une certaine probabilité qui dépend de la différence de score, et d’un paramètre qu’on nomme habituellement la température. Plus la température est élevée, plus la probabilité de conserver des changements qui détériorent le score est élevée, et avec une température de zéro, on ne garde que les changements qui améliorent le score. On commence avec une température très élevée (pour pouvoir bien explorer l’espace d’états possibles), et on diminue progressivement la température pour se concentrer sur les meilleurs scores.

Cet algorithme a été très étudié pendant des décennies, et il s’adapte à beaucoup de problèmes, mais ce n’est pas forcément évident de choisir une bonne fonction de score, une bonne fonction de proposition (les étapes élémentaires qu’on utilise pour passer d’un état à un autre état voisin), et un bon programme de refroidissement. Si on refroidit trop vite on peut se retrouver bloqué dans un optimum local, et si on refroidit trop lentement ben ça prend trop de temps¹.

Bon, comme ça demande en général beaucoup d’étapes, il faut que l’évaluation soit rapide et j’ai donc RIIR le programme d’exemple qu’on nous fournissait en Python. Ça m’a permis de multiplier par 15000 la vitesse d’évaluation, et passer de ~2 decks évalués par seconde à ~30000. Vive Rust.

Au lieu de manipuler un paramètre de température je trouve en général plus pratique d’utiliser son inverse. J’ai donc commencé par une température inverse de 0 (donc température infinie : tous les mouvements sont acceptés) que je faisais augmenter linéairement. En traçant le nombre de mains perdues (que je cherchais donc à minimiser) en fonction de la température, j’ai vu une descente assez régulière jusqu’à une température inverse de 2,5, puis une descente beaucoup plus lente, qui est quand même descendue à 2 mais est restée bloquée là.

Ça m’a montré que ce n’est pas forcément la peine de s’attarder sur la première phase, mais que la température inverse critique semble être 2,5 et que c’est probablement à ce moment-là et après qu’il faut particulièrement insister.

J’ai donc un peu changé le programme de refroidissement : j’ai commencé à 2, et quand j’arrivais à 10 je considérais que j’étais bloqué dans un minimum local dont il fallait sortir. Pour ça, je redescendais tout à coup la température inverse à 2 et je recommençais (les fameux recuits).

J’ai lancé un run et je suis allé me coucher, quand je me suis réveillé ça avait trouvé une solution, au bout de 2h30 de calcul et 236 millions de decks testés. Vive le recuit simulé.

Vendredi

Accueilli par Aurèle Duda tout aussi chaleureusement que par Nicolas la semaine dernière, je vais saluer les quelques personnes que je reconnais de Lyon. C’est un peu la même chose mais en plus petit : on passe de 4 salles à une seule, la boutique qui prenait une salle entière tient maintenant sur une seule table, mais une différence notable concerne justement les tables : alors qu’à Lyon on était alignés comme à l’école, ici il y a trois groupes de tables en U.

Je commence par l’atelier de Chtik qui commence par s’asseoir près de nous et par nous expliquer sa vision de l’origami : des pliages simples à plier, à retenir et à enseigner, avec le moins de préparation possible (seulement des feuilles carrées : pas d’hexagones ou de pentagones à découper), à plier sans table par exemple dans les transports, et qui donnent envie d’être pliés et repliés. Rien à voir avec Lyon en effet ! Il nous montre alors comment faire des feuilles d’arbre en trois plis, et en plus de nous expliquer quels plis faire il nous explique aussi comment les faire : Chtik plie sans table et ça peut dérouter mais il a passé beaucoup de temps à trouver les bonnes positions et les bons mouvements et tient à nous les transmettre pour essayer de nous convaincre que se passer de la table n’est pas une contrainte mais au contraire une liberté.

Avec la demi-heure qu’il nous restait à la fin de l’atelier Chtik nous a distribué du papier et invité à créer des compositions de branches et de feuilles avec autant de papier qu’on voulait mais à condition de l’utiliser entièrement ! Ça demandait un peu de préparation pour savoir comment découper son papier en carrés et rectangles pour faire les feuilles et les tiges et comment organiser sa composition : j’ai fait 8 feuilles et 4 tiges.

Pour l’atelier suivant, je suis allé voir Hong qui enseignait le modèle Seeds in the Wind de Toshikazu Kawasaki : un joli enchevêtrement géométrique. J’ai été tellement fasciné par ce système d’accroche que j’en ai plié trois autres variations pendant le weekend, en faisant varier la taille et le nombre de bandes, et la géométrie du modèle.

Samedi

Samedi matin des participant·es avaient apporté des gâteaux pour le petit déjeuner ! Je suis allé à l’atelier de Chtik pour faire des fleurs avec du joli papier imprimé, puis on est allé s’acheter à manger avec plusieurs participant·es et on a mangé ensemble dans la salle en discutant d’origami. C’était vraiment sympa. Une fois les tables essuyées on s’est remis au travail, pour ma part avec une version simple du gland de Beth Johnson, enseignée par Camille, puis avec un cadre photo tessellé créé et enseigné par Valérie, une experte en tesselations, qui nous a dit s’être inspirée des cheveux du Green man de Nick Robinson.

On termine la journée par un pliage surprise plié dans le noir complet (autant que possible compte tenu des lumières de sécurité) réalisé sur un papier phosphorescent ! Une expérience que j’ai trouvée très originale. On est ensuite passé au dîner pizza, suivi d’une session de pliage libre jusqu’au bout de la nuit jusqu’à 22 heures, pendant laquelle on a formé des petits groupes spontanés pour plier ensemble, avec notre salade de fruits ou notre boisson à portée de main : j’ai plié dans le groupe de Cécile qui révisait son atelier du lendemain.

Dimanche

J’ai choisi le petit requin de Tu Kaiming, enseigné par Jonathan, et le troisième atelier de Chtik, d’origamikebana, dans lequel on a vu une fleur supplémentaire, une base en hydrangea, et la souris de Rikki Donachie.

Pendant la pause déjeuner, Valérie nous a laissé fouiller dans son incroyable boîte à tessellations et nous a expliqué les merveilles qui s’y trouvaient.

Comme au moins trois choses se passent à la fois, je ne pouvais pas être partout, mais je me dois de mentionner deux ateliers auxquels je n’ai pas participé : l’atelier de Cécile de création de papier bullé (originale technique de peinture avec un rendu incroyable), et le stop motion d’Aurèle qui a animé une petite scène dans un décor entièrement réalisé en origami par les participant·es. J’ai trouvé ce concept de réalisation collective une super idée, et je voyais certain·es participant·es plier ensemble du mobilier pour les scènes du film : une théière, des meubles, etc., à partir de plusieurs livres remplis de diagrammes de maisons de poupées. Je regrette de ne pas y avoir pris part et j’ai hâte de voir la scène montée.

Mommy Morse (77 résolutions)

Il est demandé de transmettre un signal en morse, où les points et les traits sont représentés par une « porteuse pure à une fréquence de 5 kHz », et les espacements par une fréquence de 1 kHz. Un signal d’exemple est fourni, et comme j’aime bien visualiser, j’ai fait un graphe:

Comme d’habitude, je trouve que tracer l’argument complexe du signal aide bien, parce que dans ce cas il évolue de manière linéaire (modulo le modulo ), avec une pente qui dépend de la fréquence de la porteuse. C’est exactement la manière dont je m’y suis pris pour créer le signal dont j’avais besoin : j’ai créé l’argument qu’il fallait, que j’ai mis dans une exponentielle complexe et c’est passé.

Hash-ish (71 résolutions) et Khal Hash (10 résolutions)

Sûrement mes deux épreuves préférées :)

Hash-ish donne un entier H et demande de trouver deux entiers a et b tels que la valeur de hash((a, b)) soit H (hash étant la fonction de hachage par défaut de Python).

Mais comment ça fonctionne, hash, d’abord ? Pour les tuples, son code est là ou bien simplifié² ici en Python (PH1, PH2 et PH5 sont des constantes définies dans le code de CPython, et MOD vaut ) :

def myhash(integer_tuple: Tuple[int, ...]):
    acc = PH5
    for element in integer_tuple:
        acc = (acc + element * PH2) % MOD
        acc = ((acc << 31) | (acc >> 33)) % MOD
        acc = (acc * PH1) % MOD
    acc = (acc + len(t) ^ (PH5 ^ 3527539)) % MOD
    return acc

C’est donc cette fonction qu’il faut inverser (on sait ce qu’elle doit retourner, et on veut savoir quel argument lui donner pour qu’elle fasse ça).

Entre Z3, un « prouveur de théorèmes » développé par Microsoft Research. Plus précisément, c’est un solveur SMT. Sans rentrer dans les détails, un solveur SMT est une généralisation d’un solveur SAT. Alors qu’un solveur SAT détermine la satisfiabilité de formules logiques (avec des portes logiques et des booléens), un solveur SMT détermine la satisfiabilité de formules impliquant des objets plus complexes, comme des nombres ou des structures de données. Ici, c’est exactement ce qu’il faut : on a une formule mathématique à résoudre sur les entiers modulo .

Z3 possède des variables de type entier, mais vu qu’ici on a des opérations sur des bits, j’ai préféré utiliser les BitVecs, qui sont comme leur nom l’indique des tableaux de bits de taille fixée, et sur lesequels on peut quand même faire des opérations arithmétiques facilement.

def solve(h):
    N = 64
    s = z3.Solver()
    # a and b are the integers that we are looking for
    a = z3.BitVec('a', N)
    b = z3.BitVec('b', N)
    # they need to be less than 2**60, or they don't hash to themselves
    # ULT = Unsigned Less Than: `a < 2**60` doesn't work unless we also add `0 <= a`
    s.add(z3.ULT(a, 2**60))
    s.add(z3.ULT(b, 2**60))
    # hashing the first integer
    acc0 = z3.BitVec('acc0', N)
    s.add(acc0 == PH5 + a * PH2)
    acc1 = z3.BitVec('acc1', N)
    # LShR stands for Logical Shift Right, >> being the arithmetic one
    s.add(acc1 == (acc0 << 31) | z3.LShR(acc0, 33))
    acc2 = z3.BitVec('acc2', N)
    s.add(acc2 == acc1 * PH1)
    # hashing the second integer
    acc3 = z3.BitVec('acc3', N)
    s.add(acc3 == acc2 + b * PH2)
    acc4 = z3.BitVec('acc4', N)
    s.add(acc4 == (acc3 << 31) | z3.LShR(acc3, 33))
    acc5 = z3.BitVec('acc5', N)
    s.add(acc5 == acc4 * PH1)
    # the final hash value should be the one specified
    s.add(h == acc5 + (2 ^ (PH5 ^ 3527539)))
    # calling the solver
    sol = s.check()
    if str(sol) == 'sat':
        # a solution was found: return it
        model = s.model()
        return (model.evaluate(a).as_long(), model.evaluate(b).as_long())

Appelée avec h = 42 (au hasard), la fonction retourne le tuple suivant: (471024597674449489, 129304832457527322). On vérifie :

>>> hash((471024597674449489, 129304832457527322))
42

Ça suffisait pour passer Hash-ish. En revanche, le grand frère Khal Hash est plus coriace. En effet, il demande toujours de trouver un tuple d’entiers dont le hash est une valeur donnée, mais avec la contrainte que les entiers doivent être des caractères ascii (compris entre 0 et 127). Or, deux entiers ne suffisent plus : en effet, le hash étant une valeur de 64 bits, il faut environ le même nombre de paramètres pour avoir une chance, soit environ 9 ou 10 entiers (puisque chacun a 7 bits utilisables et que ). Z3 est malheureusement dépassé par ces contraintes (le problème est beaucoup plus profond : non seulement il y a plus de variables intermédiaires, mais aussi le chemin est plus long entre le hash final et l’entrée à trouver).

J’ai donc écrit une version optimisée de la fonction hash en Rust, qui tourne en une poignée de nanosecondes pour une entrée de 10 entiers. C’est rapide ! Il ne reste plus qu’à essayer des tuples au hasard jusqu’à tomber sur la valeur qu’on voulait. Pas vrai ? Pas vrai ?

On peut essayer d’estimer combien de temps ça peut prendre : la probabilité de tomber sur la valeur qu’on veut en hachant un tuple est environ . Donc la probabilité de ne pas tomber dessus est de . La probabilité de ne jamais être tombé dessus après avoir haché tuples est donc . Quelle valeur doit avoir pour que cette probabilité soit assez basse, disons à  ? La réponse est , à peu de choses près. Même avec la fonction optimisée, ça prendrait plus de 2000 ans de hacher ce nombre de tuples³. Le FCSC ne durant que 10 jours, il faut trouver une autre technique.

La clé ici était de se rendre compte que les opérations de la fonction de hash sont toutes inversibles. En effet, reprenons la fonction ligne par ligne:

acc = (acc + element * PH2) % MOD

Pour inverser cette addition, il suffit de retirer element * PH2 modulo MOD à acc.

acc = ((acc << 31) | (acc >> 33)) % MOD

Cette ligne réalise en fait une rotation des bits de acc, de 33 bits vers la droite (ou 31 vers la gauche). Pour l’inverser, il suffit donc de faire la même rotation à l’envers.

acc = (acc * PH1) % MOD

Pour inverser cette multiplication, on multiplie acc par l’inverse modulaire de PH1 modulo MOD. On peut calculer facilement cet inverse en python avec la fonction pow du langage: pow(PH1, -1, MOD).

acc = (acc + len(t) ^ (PH5 ^ 3527539)) % MOD

La dernière ligne est également facile à inverser puisqu’il s’agit encore juste d’une addition.

Tout cela signifie qu’en partant de la valeur finale connue du hash, on peut prendre les éléments du tuple à l’envers et revenir à la valeur initiale de l’accumulateur acc (PH5). Mais chercher dans un sens ou dans l’autre ne change rien en termes de temps de calcul. L’astuce est de chercher par les deux bouts et de faire se retrouver la recherche au milieu.

Imaginons qu’on commence par le faisceau de droite, et qu’on enregistre tous ses points d’arrivée. Maintenant, le faisceau de gauche peut se raccorder non plus juste au point final, mais à chacun des points du faisceau de droite. On arrive ainsi à au lieu des de la première méthode, pour la même probabilité de succès. C’est un sacré progrès, et ça se calcule à présent en quelques secondes ou minutes au lieu de miliers d’années⁴.

En pratique, j’ai calculé tous les tuples de taille 4 en partant d’un côté, et cherché les tuples de taille 6 en partant de l’autre côté, et je suis tombé sur une solution en une ou deux minutes.

T-Rex (67 résolutions)

Je passe des détails, mais en gros on nous donnait le résultat de où est l’application modulo , et on veut remonter à qui est la clé de chiffrement du message. Après m’être rendu compte que était bijective, j’ai passé un bon moment à essayer de l’inverser à la main sans succès, avant de réaliser que je pouvais utiliser là aussi Z3 (31337 fois de suite).

Gaston La Paffe (29 résolutions)

On avait ici un algorithme de signature à base de polynomes, qui fonctionnait de la manière suivante (là aussi, j’omets des détails) :

• s1 et s2 des polynomes choisis au hasard, constituent la clé privée ;
• On nous donne a et t, polynomes tels que t = a*s1 + s2 ;
• Pour signer un message m, y1 et y2 sont d’abord générés aléatoirement. Puis on calcule c = H(a*y1 + y2, m) où H est une fonction à sens unique. Enfin, on retourne z1 = s1*c + y1 et z2 = s2*c + y2, ainsi que y1 « par erreur ».

Quelques calculs permettent de se rendre compte que connaître y1 permet de trouver aussi y2:

y2 = a*(z1 - y1) + z2 - t*c

et qu’à partir de là, on a les équations

s1 * c = z1 - y1
s2 * c = z2 - y2

dans lesquelles on connaît toutes les variables à part les secrets s1 et s2.

Pour trouver les coefficients des secrets, j’ai choisi d’utiliser ortools, une suite de solveurs développée par Google. Z3 aurait peut-être pu aussi fonctionner, mais il s’agissait ici en fait d’un problème de programmation linéaire sur les entiers, ce sur quoi ortools est plus efficace.

Never Skip Class Nor Multiplication (85 résolutions)

On avait accès à un oracle RSA chiffrant des messages choisis, à l’aide d’une fonction d’exponentiation modulaire « buguée » de manière à ce qu’on puisse choisir quelle multiplication elle allait sauter. L’objectif était de déterminer la clé privée (l’exposant de l’opération ).

La question à se poser est la suivante : Si je saute la multiplication du bit de la clé , quel est l’exposant qui a alors été utilisé ?

    Exposant d initial                       Exposant d' réel
N-1          K            0    skip K    N-1          K            0
[    dH    ] 0 [    dL    ]    ----->    [    dH    ] 0 [    dL    ]

N-1          K            0    skip K    N-1          K            0
[    dH    ] 1 [    dL    ]    ----->    [    dH    ] 0 [    dL    ]

On remarque facilement que sauter un bit nul ne modifie pas l’exposant, alors que sauter un bit non-nul le change. Il suffit alors de demander à chiffrer le même message en sautant tous les bits un par un, et de comparer ces résultats à la situation où on ne saute aucun bit. On a alors une correspondance directe entre les résultats et la clé.

Never Skip Class Nor Squaring (70 résolutions)

Même principe, mais la fonction est buguée de manière à sauter l’étape de mise au carré. La question est la même : si on saute le bit de l’exposant , quel exposant a-t-on alors vraiment utilisé ?

    Exposant d initial                       Exposant d' réel
N-1          K            0    skip K    N-2        K            0
[    dH    ] 0 [    dL    ]    ----->    [    dH    ] [    dL    ]

N-1          K            0    skip K    N-2        K            0
[    dH    ] 1 [    dL    ]    ----->    [  dH + 1  ] [    dL    ]

Grâce à quelques dessins dans ce genre, on se rend compte que peu importe la valeur du bit , on a toujours . Cette observation permet de déterminer bit par bit. En effet, si on appelle la vraie valeur de , en sautant le bit on obtient pour deux valeurs possibles selon que le bit est nul ou non : soit (s’il est nul), soit (s’il ne l’est pas). Armé de cette information, on saute alors le bit pour déterminer la valeur du bit , etc.

Guess Me Too (68 résolutions)

Un nombre de 128 bits est tiré au hasard et il faut le deviner. On ne peut poser que 136 questions de la forme « Parmi les bits numéros , , , etc. du nombre secret, quelle est la parité du nombre de bits non nuls ? » (en choisissant les ). De plus, on sait qu’une des réponses sera fausse mais on ne sait pas laquelle.

Il semble logique de commencer par demander les 128 bits un à un. On a déjà presque 6% de chance d’avoir deviné le nombre (si la réponse incorrecte tombe dans les 8 autres questions), donc on pourrait déjà s’arrêter là et faire plusieurs tentatives jusqu’à ce que ça marche (17 fois en moyenne).

Pour deviner le nombre à coup sûr, il faut faire de la correction d’erreur.

On commence par demander la parité de la somme de tous les bits, et on compare avec le résultat des 128 premières questions. Si les résultats concordent, on sait qu’on n’est pas encore tombé sur la réponse incorrecte. Sinon, c’est qu’il y a une erreur soit dans les questions individuelles, soit dans la question de contrôle. Pour la déterminer, on demande alors la parité de la somme de tous les bits impairs, que l’on compare à nouveau au résultat des questions individuelles. On sait que le résultat de cette question sera correct, puisqu’on a déjà détecté une erreur et qu’il ne peut y en avoir qu’une seule. Si les résultats concordent, on sait que l’erreur est dans les bits pairs, sinon c’est qu’elle est dans les bits impairs. On peut alors continuer à préciser la position de l’erreur en demandant la parité de la somme des bits impairs des bits suspects d’être erronés, jusqu’à ce qu’il n’y ait plus qu’une seule possibilité.

En pratique, toutes les questions doivent être posées en même temps au début. Qu’à cela ne tienne, les huit questions supplémentaires à poser qui fonctionnent dans tous les cas sont les suivantes :

11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
10101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010
11001100110011001100110011001100110011001100110011001100110011001100110011001100110011001100110011001100110011001100110011001100
11110000111100001111000011110000111100001111000011110000111100001111000011110000111100001111000011110000111100001111000011110000
11111111000000001111111100000000111111110000000011111111000000001111111100000000111111110000000011111111000000001111111100000000
11111111111111110000000000000000111111111111111100000000000000001111111111111111000000000000000011111111111111110000000000000000
11111111111111111111111111111111000000000000000000000000000000001111111111111111111111111111111100000000000000000000000000000000
11111111111111111111111111111111111111111111111111111111111111110000000000000000000000000000000000000000000000000000000000000000

Si on regarde par exemple la ligne 11001100..., elle contient bien tous les bits impairs des bits impairs, ainsi que tous les bits impairs des bits pairs, et ainsi de suite.

Discrete case

We are searching for the winning expectancy against opponents, if we play at (between and ).

Assume the selected number is . Then we can count the number of numbers at the same distance from the target as we are: such that . This will be or . We can also count the number of numbers farther from the target than we are: such that . If of our opponents are at the same distance from the target as we are, and all the others are farther, then in case we split the prize, we win of the prize. This happens with probability for given and . The total winning expectancy is then

From this graph, we indeed win every time when we have no opponent, we win less often as the number of opponents increases, and picking the middle region seems in general to be a good choice.

But as the number of opponents goes up, the winning expectancy goes down and it becomes more difficult to distinguish the strategy. To make it appear more clearly, I will normalize each curve such that their integrals are equal (more precisely I divide them by the total winning expectancy for this number of opponents).

What jumps to the eye is that for enough opponents, the best strategy is not to play in the middle any more. We can also note that the strategies against 1 or 2 opponents are identical. Finally, when the number of opponents becomes very large, the best strategy becomes to chose uniformly: indeed in this case all the numbers will probably have been chosen by several people, so that we only win if we pick exactly the selected number.

Similar reasoning allows to obtain formulas for the other rules:

Continuous case

A closed-form formula is easier to find for the continuous case: following a similar reasoning, the winning expectancy if we play at against opponents is

A small advantage seems to subsist in the continuous case, since we can make a guess as close to the border as we want. The positions of the two peaks of the strategy and are such that when tends to infinity, and , the demonstration of these properties is left as an exercise to the reader.

Continent

• Historiska museet Museum of the history of Sweden, free and interesting;
• Östermalms saluhall Covered market, closed on Sundays. It is a very nice place to buy all kinds of fancy food (fish, meat, bread), and also to eat traditional Swedish meals that can be heated up and served on the spot. It is in a temporary location until winter 2020, while the historical building is being renovated. Without contest one of my very favourite places in Stockholm;
• The observatory hill Nice point of view to see the sunrise over Stockholm;
• KTH library seems open to everyone, is a pretty nice building and is a nice place to study, or prepare the rest of the day;
• KTH R1 The dismantled (and safe) remains of the first nuclear reactor in Sweden. It is now used as a culture center and exhibitions and parties are regularly organized there.

Kungsholmen

• The city hall is open to visits during the summer, but the view from under the archs is very pretty all year long. This is where the Nobel gala dinner is served on December 10th. Fun fact: the restaurant is open all year long and can serve the menu from any given year’s gala, on the porcelain actually used for the banquet.

Gamla Stan

Not my favourite part of the city: too many tourists.

• The royal palace, the official residence of the royal family (but they don’t usually live here) can be visited. As for the city hall, it is a massive building but finely decorated inside. Watching the changing of the guard in the palace’s courtyard is a fun attraction;
• The Nobel museum was a little bit underwhelming but I probably had too high expectations. It is rather small, presents two showcases about Alfred Nobel, a temporary exhibition and a permanent collection of some of the personal items that the Nobel laureates are invited to donate to the museum. Among them, the scarf that Malala Yousafzai wore during her speech at UN, Geim and Novoselov’s original scotch tape dispenser, or the sample jar Barry Marshall drank his Helicobacter pylori broth from, but also a trumpet, a calculator, an abacus belonging to the laureates… Most notably, some of the prize diplomas were also exposed. Each of them is unique, and are expectedly some of the finest works of art there are, drawn and colored by hand by Swedish artists. They also have a video room with short introductions to the work of the laureates playing in random order: I could have spent hours in this room…

Riddarholmen

• Riddarholmskyrkan The visit costs a couple dozens of crowns, but I recommend it. This church is the sepulchre of the royal family. It is better to see it after the visit of Historiska museet to have some of the genealogy in mind (it doesn’t help that everyone is named Gustav).

Skeppsholmen

• The museum of east-asian art: free and open late (20 o’clock). I have seen a nice exhibition on traditional paper making in asian countries, and the Japan section of the museum appealed to me. The museum also hosts an extensive collection of ancient chinese books (not that I could read them);
• Moderna museet that I didn’t have time to visit.

Djurgården

• Nordiska museet: go in the afternoon, it is free after 13 o’clock. This is the museum of nordic life and exposes the daily life of Swedes during the last 6 centuries. The building itself looks like a fairy tale castle. Really worth the visit;
• Vasamuseet exposes the local Titanic: a battle ship that sunk in 1628 in her maiden trip and was resurfaced in 1961;

• Skansen is an old and large open air museum / ecomuseum / zoo. The public is mostly Swedish: families, or school classes. I understood that Stockholmers generally buy a ticket allowing entry all year long, and come back regularly for the animations proposed all along the year around the traditional holidays. I visited over Easter and have seen for example a Swedish grandma prepare traditional Easter cakes. Furthermore, the shop is nice, and there is a couple of restaurants and hot dog stands inside: I would recommend to visit Skansen in the morning, eat there and wait for 13 o’clock to go visit Nordiska museet just in front;
• The botanical garden was unfortunately closed for restauration.

Södermalm

• This part of the island, besides being a nice picnic place, has very old traditional wooden houses once occupied by the working class. The view from this bank to the north side of the city is alone worth the trip;
• Stockholm’s city museum, closed for restauration until a couple of days after my return date…

Further

• The furthest I went by foot is Vinterviken, a very bucolic place once owned by Nobel where he installed his dynamite factory. The beauty of the landscape contrasts with the rocks torn by the experiments. The place seems to be appreciated by Stockholmers since I saw many of them jogging in the park, or going out with a baby stroller. The old acid factory was converted into an exhibition center, and a really nice restaurant. You can take a tray, order one of the three meals of the day, grab bread and water and go eat it outside at one of the picnic tables, as a reward for the walk to arrive here from Stockholm. I warmly recommend it.

Even further

• I wish I had the time to go pick a rock at Ytterby’s ytterbium quarry but that will be for another time.