Rebondissant sur l’importance du chiffrement, Mozilla a décidé d’en rendre les bases accessibles à tout un chacun. Comment ? En proposant des exercices simples fournissant explications et pratique. Au centre du concept, l’utilisation des emojis pour rendre l’apprentissage ludique.
Mozilla fait partie des entreprises qui promeuvent largement le chiffrement. Depuis les débuts de l’affaire Snowden, le père de Firefox n’a de cesse de marteler que cette technologie est essentielle pour la vie privée. Quand on connait l’attachement de l’éditeur à cette valeur, on comprend mieux notamment pourquoi le lancement d’une campagne de sensibilisation du public sur l’importance du chiffrement.
Cette campagne, débutée en février, doit se poursuivre sur le long terme, avec une augmentation des contenus. L’objectif est ambitieux, puisqu’il s’agit de sensibiliser des populations qui n’ont pas réellement d’affinités et/ou de connaissances particulières en informatique, ou même le monde technologique en général. Des questions qui peuvent paraître abstraites à la plupart donc. Or, le pouvoir d'un public informé, comme souligné par Snowden en juin 2015, est crucial. On peut par exemple voir actuellement l’EFF critiquer des magistrats américains pour certaines décisions aux lourdes conséquences. Selon l’association, ces juges ne comprennent pas les technologies impliquées dans certaines affaires.
Des emojis pour attirer les jeunes utilisateurs
Fournir des explications, informer et fonctionner par analogies permet de dépeindre un tableau général, mais Mozilla veut aller beaucoup plus loin : sensibiliser aux principes fondamentaux du chiffrement en fournissant des contenus ludiques. Pour s’adresser aux plus jeunes, l’éditeur utilise donc les emojis, espérant sans doute que leur immense succès sera une motivation suffisante pour aller « jouer » au chiffrement.
L’idée est de faire comprendre ce qu’est une suite cryptographique avec Codemoji. Mozilla explique donc que dans les formes de chiffrement les plus basiques, chaque lettre est remplacée par une autre, selon un décalage dans l’alphabet. Ici, les lettres seront remplacées par des emojis. On choisit ensuite un emoji qui va servir de clé et affecter le résultat final. L’utilisateur est ensuite invité à envoyer le message chiffré à un contact, en lui fournissant des indices sur le moyen de retrouver la clé.
Il ne s’agit évidemment qu’un exercice visant à faire assimiler par les plus jeunes ou ceux n’ayant aucune notion de chiffrement l’un des concepts fondamentaux dans ce domaine. Mozilla indique d’ailleurs sur la page, avant même de commencer à se servir de Codemoji, que personne ne devrait l’utiliser pour communiquer de manière sécurisée : « Heureusement, les outils modernes de chiffrement sont bien plus forts que les emojis ».
Il faudra aller plus loin
Mark Surman, Directeur Exécutif de Mozilla, explique pour l’occasion : « Si nous souhaitons que les gens soient de plus en plus nombreux à soutenir le chiffrement, il est crucial de les sensibiliser à son fonctionnement et ses enjeux. C’est particulièrement important aujourd’hui, alors que le chiffrement est menacé aux quatre coins du monde. De la France à l’Australie en passant par le Royaume-Uni, les gouvernements proposent des mesures allant contre la sécurité des utilisateurs en affaiblissant le chiffrement. Aux États-Unis, le FBI a récemment demandé à Apple d’alléger les mesures de sécurité sur ses propres produits »
Nous avons demandé à l’éditeur s’il prévoyait par la suite de renforcer cette dimension d’apprentissage par des exercices supplémentaires. Nous mettrons à jour cette actualité avec la réponse.
Commentaires (37)
#1
https://mzl.la/294NAD1
🗼
#2
Quelle blague… Quand on voit l’état de délabrement de la cryptographie actuelle, je crois qu’il y aurait mieux à faire dans ce domaine.
#3
Tu pourrais développer sur cet “état de délabrement” et “mieux à faire” ? Là ça fait un peu ronchon yakafokon
" />
#4
Alors bon appétit !
" />
#5
yakafokon ? Ça fait 3 ans que je développe une application de chiffrement de fichiers. Alors libre à toi de croire ou pas ce qui suit.
Du coup, j’ai dû me rabattre sur une autre implémentation, celle optimisée de Gladman. Et ma plus grand surprise fut de constater que les tables produites après la préparation des clés sont exactement celles utilisées par les instructions AES-NI de Intel. En gros, Intel a littéralement pompé le travail Gladman.
Et bien sûr, accessoirement ça m’a ruiné 2 mois de temps libre utilisés pour adapter l’algo à mon application, vu que maintenant, les résultats sont différents.
Alors oui, le mot “délabrement” n’est pas trop fort. Si Mozilla veut faire quelque chose d’utile, ils pourraient déjà commencer par archiver les algos existants. Et je crois que je m’investis suffisamment pour pouvoir critiquer.
#6
Ah bah en fait, les liens pour le code source de AES sont à nouveau invalides.
Si quelqu’un a le code source d’origine de AES, en pouvant garantir qu’il s’agit bien du code présenté au concours, je serais intéressé.
Edit: je viens de le trouver ici.
#7
#8
Merci de lire mes messages jusqu’au bout.
#9
#10
Petite parenthèse :
Ce qu’il y a de bien en crypto, c’est que 1 source = 1 délire.
Je ne sais pas si ce que je viens de récupérer comme code d’AES est bien le code proposé au concours (c’est fort possible), mais ça ressemble fortement à ce que j’ai obtenu après avoir passé une semaine à écrémer le code de Gladman.
En conclusion, Intel n’a peut-être pas eu besoin de Gladman…
Pour ta question, ce qui peut différer n’est pas le résultat final, mais les calculs préalables.
En gros, le mot de passe est dérivé en clé de 256 bits (pour AES-256). Cette clé est transmise à une fonction d’initialisation qui produit des tables, et ces tables sont utilisées par les fonctions de chiffrement/déchiffrement. Mais ces tables peuvent différer d’une implémentation à l’autre.
Ça fonctionne comme ça pour la plupart des algos.
#11
@vampire7 oulà, ça pique les yeux o_O
#12
#13
#14
#15
#16
Oui, et ça tombe bien parce que je n’en suis pas un.
#17
En tout cas, merci pour des explications détaillées très intéressantes :)
#18
Oui bien sûr, on peut encore utiliser TrueCrypt aujourd’hui, à condition d’avoir un bon mot de passe.
Je voulais juste dire que même avec du temps et un logiciel populaire, on peut encore trouver des imperfections.
Et puis à mon avis, TrueCrypt a d’autres problèmes que les 4 soulevés dans l’audit. Il y a bien sûr la fonction de dérivation de clé qui était très bien il y a 10 ans mais un peu légère aujourd’hui vu les progrès faits sur les GPU et les ASIC.
Il y a aussi les traces de son utilisation laissées dans le système, dont certaines qui peuvent, suivant les circonstances, remettre en cause le “déni plausible”…
#19
#20
#21
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
Après démontage du volume, il y reste 2 valeurs dont le contenu est “TrueCryptVolumeF”.
Déjà en soi, c’est une indication. Mais ce que beaucoup de gens ne savent pas, c’est que les clés de registres sont datées. Une date pour chaque valeur du registre.
Cette information n’est pas affichée par regedit. Il faut passer par des outils alternatifs, comme RegScanner.
Comme le déni plausible consiste à mentir, si ton adversaire peut prouver que tu mens avec ce genre d’informations, ça se retournera contre toi.
#22
#23
#24
Intéressant ce fil!
#25
Ils ont augmenté le nombre d’itérations de PBKDF2. C’est bien mais ça ne change pas fondamentalement le problème : comme elle ne consomme presque pas de RAM, cette fonction peut être fortement parallélisée pour les attaques par force brute.
Lorsque PBKDF2 a été écrit, c’était l’époque des 3DFX… Alors personne ne pensait au calcul par GPU.
#26
Il y a quoi de mieux actuellement à l’épreuve des GPU ?
#27
Grande question. La première fonction a viser directement ce problème a été scrypt. Aujourd’hui, elle est assez critiquée mais aucune faiblesse majeure n’a été trouvée.
Il y a maintenant des alternatives à scrypt qui tentent d’améliorer certains points, comme yescrypt ou neoscrypt.
Et pour mettre tout le monde d’accord, le “Password Hashing Competition”, finalisé l’année dernière, était censé trouver un algorithme répondant aux possibles attaques actuelles, et Argon2 a été sélectionné. C’était une compétition ouverte, avec des organisateurs venant d’un peu partout, pour éviter le problème d’une sélection par une agence américaine (AES et SHA-3 ont été sélectionnés par le NIST).
A priori, tout était parfait. Mais vu la mise à jour faite sur Argon2 il y a quelques mois, j’ai aujourd’hui beaucoup de mal à lui faire confiance.
Non seulement cela montre que les organisateurs ont laissé passé un problème important, mais la mise à jour a été présentée comme mineure (version 1.3), alors qu’elle change les hashs produits, et donc les mots de passe ne sont plus reconnus.
S’il y avait beaucoup de monde utilisant cette fonction, on aurait eu un joli scandale. Mais il y a une telle inertie dans le monde de la cryptographie que la plupart des logiciels ou des sites web utilisent encore PBKDF2.
#28
Merci pour ces précisions. Scrypt me dit quelque chose, c’est l’algo utilisé dans certaines cryptomonnaies. À l’heure actuelle, bcrypt n’est-elle pas une bonne alternative ?
#29
bcrypt est clairement plus évoluée que PBKDF2, mais elle n’utilise pas particulièrement la RAM et a certaines limitations. Enfin à vrai dire je ne la connais pas trop.
Pour le minage, scrypt est effectivement parfois utilisée, mais avec les paramètres minimums ou presque. Là, elle n’a donc pas plus d’intérêt que PBKDF2 puisqu’on la configure pour être facilement parallélisée.
#30
C’est pas ça une attaque temporelle. Une attaque temporelle, c’est quand tu arrive a obtenir de l’information sur le message ou sur la clé à partir de temps de calculs à différentes étapes. Pour prendre un exemple simpliste et caricatural, si ta fonction de chiffrement répond en un temps proportionnel à la longueur de ton mot de passe, rien que le temps d’exécution de ton programme trahis ce qu’il fait.
D’où le problème cité par vampire7 : il y a souvent un tradeoff à faire entre la performance de l’algo (qui t’incite à renvoyer la valeur dès que tu l’as) et la sécurité (qui exige que le temps de réponse soit le même dans tous les cas, donc au moins aussi long que le temps de réponse dans le pire des cas).
#31
#32
Je croyais que ton message était ironique.
" />
#33
#34
Ca ne sert à rien ce que tu fais.
Presque personne ne perd son temps à implémenter un algorithme de chiffrement, car Il existe des dizaines d’implémentation open source disponible comme Bouncy Castle ou Openssl.
Vouloir l’implémentation original du concours n’a tout simplement aucun sens.
#35
#36
La rapidité d’AES est par conception adapté aux processeurs, puisque qu’il s’agit d’un réseau de permutation substitution de matrice, vous faites donc un travail inutile.
La rapidité va déprendre très largement du compilateur ou de la JVM plus que de l’implémentation.
Je suppose que le code de TrueCrypt est une compilation générique x86 et que vous avez ciblé un processeur spécifique. Cela expliquerait l’écart plus que d’avoir tenter d’optimiser un algorithme.
#37