Ça date d'août 2016, mais je voulais étudier ça à tête reposée.

Les algorithmiques cryptographiques de chiffrement symétrique découpent les données à chiffrer en blocs de taille identique pour ensuite travailler sur chacun d'eux (et en les liant mais passons). Certains algorithmes, comme Blowfish et 3DES bossent avec des blocs de 64 bits. AES, SEED et Camellia utilisent des blocs de 128 bits. On parle bien de la taille des blocs, pas de la taille de la clé de chiffrement.

La taille des blocs définit la quantité maximale d'information qui pourra être chiffrée de manière sûre avec la même clé : 2^n blocs où n est la taille des blocs. Sauf qu'avec le paradoxe des anniversaires (que je n'ai jamais compris :- ), on tombe à 2^(n/2), ce qui nous donne 256 exaoctets (soit 256 000 pétaoctets soit 256 000 000 téraoctets) avec une taille de blocs de 128 bits (donc on a le temps de voir venir) mais seulement 32 gigaoctets avec une taille de blocs de 64 bits. Il faut donc changer de clé de chiffrement avant cette limite.

Au-delà de cette quantité de données échangées avec la même clé, on peut obtenir des collisions entre deux blocs chiffrés, ce qui révèle le XOR des deux blocs non chiffrés à l'origine des blocs chiffrés qui ont fait collision (dans le cas du mode opératoire CBC, mais ça reste aussi applicable aux autres modes opératoires genre GCM, c'est juste plus compliqué, voir https://blog.imirhil.fr/2016/03/03/chiffrement-donnees.html ). Sauf qu'en pratique, récupérer un XOR de deux blocs non chiffrés, ça ne suffit pas à avoir la version claire des données échangées… Sauf si l'on connaît l'un des deux blocs clairs.

Jusqu'ici, c'est de la crypto habituelle, il n'y a rien de nouveau. À titre d'illustration, depuis 2014, l'ANSSI recommande d'utiliser des algos avec des blocs de 128 bits minimum dans son RGS (annexe B1). Alors en quoi Sweet32 est-il nouveau ? C'est un proof-of-concept qui montre que la faisabilité d'une attaque par collision de blocs chiffrés sur des algos cryptos utilisant des blocs de 64 bits se rapproche : dans un lab, il faut environ 19 heures et 705 Go de données échangées dans un tunnel OpenVPN utilisant Blowfish pour retrouver un secret d'une taille de 16 octets. Toujours dans ce lab, il faut environ 30 à 40 heures et entre 610 et 785 Go de données échangées pour retrouver un secret de 16 octets dans un échange HTTPS chiffré avec 3DES.

Qu'en retenir ? Que la fin des algos avec des tailles de blocs de 64 bits approche mais qu'il y a encore le temps puisque l'attaque pratique montée par les chercheurs de l'INRIA derrière Sweet32 suppose :

• des débits élevés (705 Go échangés en 19 heures, ça nous fait du 10,5 mo/s constant) qui supposent des connexions rapides que ne sont pas encore la norme (et ensuite, il faut être capable d'écouter ces liaisons à fort débit genre capter à distance 100 mbps, ça commence à se voir ;) ) ;
  
  
• que la connexion sera persistante sans être interrompue et que la clé ne changera pas pendant suffisamment longtemps alors qu'OpenVPN, dans son mode TLS, change la clé de session toutes les heures. Les serveurs web positionnent également très souvent une limite en nombre de requêtes qu'un client web peut réaliser dans une même connexion HTTP persistante ;
  
  
• que l'attaquant est en mesure d'écouter l'échange chiffré et qu'il connaisse une partie de l'échange en clair ou qu'il soit en mesure d'injecter des données en boucle, de manière prépondérante, dans ce qui sera échangé de manière chiffrée. Or, les cryptographes nous ont toujours dit, et Snowden nous l'a rappelé, que le chiffrement est sûr uniquement si les extrémités de la communication le sont donc oui, si tu te fais pwned par une iframe bidon et que tu ne constates pas une baisse de ton débit, oui, tu peux avoir mal.
  
  
• Tout ce qui précède suppose une attaque active, ciblée et minutieuse. On ne conduit pas une attaque Sweet32 à grande échelle.

Néanmoins, comme il faut toujours avoir de l'avance en crypto, je trouve que Sweet32 reste un bon rappel qu'il faut dégager les algos de chiffrement avec des tailles de blocs inférieure à 128 bits de tous nos usages : TLS, SSH, VPN, etc. Pour OpenVPN, voir mes notes http://shaarli.guiguishow.info/?r6npkg .