Un Write Up de cryptographie illustré, où l’on ne parle pas de réseaux euclidiens, où l’on n’explique pas comment transformer des polynômes en matrices, mais où l’on débat de l’importance de savoir faire la différence entre les 0 et les -1, et où l’on apprend que le bruteforce résout tous les problèmes mais qu’il vaut mieux optimiser aujourd’hui pour ne pas pleurer demain.
Ce challenge caché se débloque seulement une fois que Merry a été validé. Parce que Merry et Pippin bien sûr. Bon. Nous n’en avons donc définitivement pas fini avec FrodoKEM, on on espère juste que ce ne sera pas une trilogie à la seigneur des anneaux. On réouvre la documentation qu’on venait de fermer et on s’y remet.
L’énoncé nous explique que la faille de sécurité permettant l’attaque précédente a été résolue, et que désormais les bi-clés ne seraient réutilisées que pendant un nombre limité de requêtes. On se connecte au serveur et on constante effectivement une limite de 3000 requêtes. L’énoncé nous informe également que certaines valeurs ne sont pas correctement générées, mais nous n’avons pas accès au code source. Un dilemme se pose alors : doit-on tenter de deviner quelles sont les valeurs affectées et monter une nouvelle attaque pour les exploiter, ou bien peut-on essayer d’optimiser notre attaque précédente pour descendre en dessous des 3000 requêtes ?