Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Mozilla lance Codemoji pour sensibiliser la jeunesse au chiffrement

Un autre genre de jeu d'éveil

Mozilla lance Codemoji pour sensibiliser la jeunesse au chiffrement

Le 28 juin 2016 à 14h20

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é.

codemojicodemoji

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)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar







vampire7 a écrit :



 

Sauf qu’il n’existe aucune implémentation de AES qui soit à la fois performante et insensible aux attaques temporelles. Excepté celles qui utilisent les instructions AES-NI.



Et alors ? Perso, je m’en fous que mes données chiffrées avec AES soient lisibles dans 30 ans. Je serais sûrement mort d’ici là de toute façon.

L’algo est assez solide (jusqu’à preuve du contraire) pour faire ce qu’il a à faire.

Prenons l’exemple d’un terroriste qui communique grace à AES. Je crois qu’il s’en fout que son message soit lisible dans 30 ans, même dans 10 ans. Lui aussi il sera mort.


votre avatar







vampire7 a écrit :



Petite parenthèse :

Ce qu’il y a de bien en crypto, c’est que 1 source = 1 délire.



Un peu comme avec les pseudo cryptologues sur Nxi, hein ?


votre avatar

Oui, et ça tombe bien parce que je n’en suis pas un.

votre avatar

En tout cas, merci pour des explications détaillées très intéressantes :)



 









vampire7 a écrit :



Ah, le mythe des “implémentations éprouvées”… un peu comme dans TrueCrypt, un logiciel “éprouvé”, au code “stable”, et dont l’audit a été… pas des plus folichons.

Pour ma part, je n’hésite pas à retoucher les algorithmes si je peux gagner en performance ou en taille de code. Tant que les vecteurs de test correspondent, je ne vois pas où est le problème.





Sauf qu’il n’existe aucune implémentation de AES qui soit à la fois performante et insensible aux attaques temporelles. Excepté celles qui utilisent les instructions AES-NI.



 

Il me semblait pourtant que le test pratiqué sur TrueCrypt avait été plutôt sérieux et que les vulnérabilités découvertes ne remettaient pas en cause le logiciel?


votre avatar

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”…

votre avatar







uhsdhfezu a écrit :



 

Il me semblait pourtant que le test pratiqué sur TrueCrypt avait été plutôt sérieux et que les vulnérabilités découvertes ne remettaient pas en cause le logiciel?





D’autant plus que TC supporte les fameuses instructions AES NI depuis la version 7


votre avatar







vampire7 a écrit :



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”…





Plus de précisions STP, parce que trouver un volume fantôme de TC, ok c’est acquis. Prouver le déni plausible, je ne vois pas comment.


votre avatar

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.

votre avatar







vampire7 a écrit :



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.





Ha ok. Désolé, je suis sous Linux. Mais bon d’après ce que je comprends, ça prouve juste que tu vois un volume TC.

Par contre pour le déni plausible, je ne vois toujours pas. Le fait qu’il y ai un volume caché ne prouve toujours pas le déni plausible.<img data-src=" />


votre avatar







vampire7 a écrit :



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.





Je crois que ce point a été amélioré dans Vera Crypt justement (et bien d’autres).


votre avatar

&nbsp; Intéressant ce fil!

votre avatar

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.

votre avatar

Il y a quoi de mieux actuellement à l’épreuve des GPU ?

votre avatar

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.

votre avatar

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 ?

votre avatar

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.

votre avatar
votre avatar

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.

votre avatar

Tu pourrais développer sur cet “état de délabrement” et “mieux à faire” ? Là ça fait un peu ronchon yakafokon <img data-src=" />

votre avatar

Alors bon appétit !



<img data-src=" />

votre avatar

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.





  • Il y a 3 ans, les sources d’AES (l’algo Rijndael présenté au concours) étaient tout simplement indisponibles. L’algo de chiffrement le plus utilisé : disparu ! J’ai vérifié ça pendant plusieurs mois. J’ai regardé à nouveau récemment : elles sont à nouveau disponibles.

    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.



  • Beaucoup d’algorithmes n’ont plus la moindre source. J’ai récemment bossé sur SHACAL-2, l’un des finalistes du concours européen NESSIE. La seule implémentation disponible était celle de la librairie Crypto++. J’ai (indirectement) contacté un des auteurs : il n’avait même plus les sources.



  • XTS, le fameux mode de chiffrement utilisé pour les disques durs, existe pour des algos chiffrant des blocs de 128 bits. Si tu utilises un algo de chiffrement utilisant des blocs de 256 bits (comme SHACAL-2), tu dois utiliser XTS en 256 bits. Sauf que personne ne l’a jamais fait, et qu’il n’existe aucun “vecteur de test”.



  • La fonction de dérivation de clé Argon2, vainqueur du “Password Hashing Competition”, a été changée… après le concours. A cause d’une faiblesse de design. J’ai lu la description de l’attaque. Même un petit programmeur comme moi aurait fini par la trouver. Et pourtant, il a quand même été sélectionné. A ce niveau-là, je trouve ça plus que suspect.

    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.

votre avatar

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.

votre avatar







vampire7 a écrit :



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.





<img data-src=" />&nbsp;Merci de nous faire part de ta solution et des ta proposition. <img data-src=" />


votre avatar

Merci de lire mes messages jusqu’au bout.

votre avatar







vampire7 a écrit :





  • Il y a 3 ans, les sources d’AES (l’algo Rijndael présenté au concours) étaient tout simplement indisponibles. L’algo de chiffrement le plus utilisé : disparu ! J’ai vérifié ça pendant plusieurs mois. J’ai regardé à nouveau récemment : elles sont à nouveau disponibles.

    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.





    Je suis loin d’être un expert mais pourquoi des implémentations différentes du même chiffrement devraient donner des résultats différents ??


votre avatar

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.

votre avatar

@vampire7 oulà, ça pique les yeux o_O 



C'est quoi le nom de cette application exactement :D  







En cryptographie il est en général recommandé de partir d'implémentations éprouvées, je ne vois pas en quoi l'algorithme initial, tel que présenté au concours, serait d'une aide quelconque. Sauf pour la curiosité personnelle.     







@CryoGen, certaines implémentation "naïves" laissent fuir des informations. Pour un programme capable par exemple de surveiller les temps d'accès au cache, les clefs secrètes peuvent être retrouvées. Parfois même en écoutant simplement le bruit du processeur !


&nbsp; 



Typiquement, l'implémentation initiale de l'AES 256 est une infame passoire sur ce point. Et boucher les trous est un travail de professionnel, utiliser une librairie comme crypto++ est souvent un gage de qualité.      







&nbsp;
votre avatar







yoochan a écrit :



En cryptographie il est en général recommandé de partir d’implémentations éprouvées, je ne vois pas en quoi l’algorithme initial, tel que présenté au concours, serait d’une aide quelconque. Sauf pour la curiosité personnelle.





Ah, le mythe des “implémentations éprouvées”… un peu comme dans TrueCrypt, un logiciel “éprouvé”, au code “stable”, et dont l’audit a été… pas des plus folichons.

Pour ma part, je n’hésite pas à retoucher les algorithmes si je peux gagner en performance ou en taille de code. Tant que les vecteurs de test correspondent, je ne vois pas où est le problème.







yoochan a écrit :



Typiquement, l’implémentation initiale de l’AES 256 est une infame passoire sur ce point. Et boucher les trous est un travail de professionnel, utiliser une librairie comme crypto++ est souvent un gage de qualité.





Sauf qu’il n’existe aucune implémentation de AES qui soit à la fois performante et insensible aux attaques temporelles. Excepté celles qui utilisent les instructions AES-NI.


votre avatar







vampire7 a écrit :



Merci de lire mes messages jusqu’au bout.



Pour quoi faire ?


votre avatar

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).

votre avatar







Zerdligham a écrit :



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).





<img data-src=" />je comprends mieux son propos.


votre avatar

Je croyais que ton message était ironique. <img data-src=" />

votre avatar







vampire7 a écrit :



Je croyais que ton message était ironique. <img data-src=" />



Non.<img data-src=" />


votre avatar

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.



&nbsp;&nbsp;&nbsp;

&nbsp;

votre avatar







jimmy_36 a écrit :



Ca ne sert à rien ce que tu fais.





Tout le monde n’est pas de cet avis, à moins que certains aiment faire des dons sur des projets inutiles.







jimmy_36 a écrit :



Presque personne ne perd son temps à implémenter un algorithme de chiffrement





Pourtant ça existe, et ce n’est pas si rare que ça.

Cela dit, je dois admettre que c’est en dehors de mes compétences. Je me contente de prendre des sources et de les optimiser.







jimmy_36 a écrit :



Vouloir l’implémentation original du concours n’a tout simplement aucun sens.





Seulement dans le cas où il existe de meilleures implémentations. Et à moins de toutes les étudier en détails, difficile de dire laquelle est la meilleure. Donc n’ayant pas de temps à perdre, je cherche en priorité l’implémentation originale.

Mon implémentation, dérivée de celle de Gladman, est déjà plus rapide en C que la version assembleur de TrueCrypt. Donc si je l’ai demandée dans ce thread, c’était évidemment par curiosité.


votre avatar

La rapidité d’AES est par conception adapté aux processeurs, puisque qu’il s’agit d’un réseau de permutation substitution de matrice, &nbsp;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.

&nbsp;

&nbsp;

votre avatar







jimmy_36 a écrit :



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.





AES (Rijndael) a été sélectionné pour sa rapidité, ça ne signifie pas qu’il est rapide partout et dans toutes les implémentations. Je suis tombé un jour sur une implémentation optimisée pour processeurs 8 bits. Sur PC, ça allait pas super-vite… <img data-src=" />



Moi je ne suppose rien du tout. Je code, je mesure les temps, et je confirme les gains avec d’autres machines.

Créer une version SSE2 de SHACAL-2 qui multiplie environ par 3 les performances initiales (proches de celles de Crypto++ puisque c’est basé dessus), c’est aussi inutile ? Le compilateur a beau être essentiel, c’est pas lui qui se tape ce genre de boulot.



D’ailleurs, à propos du compilateur (GCC dans mon cas), il ne suffit pas de mettre bêtement -O3 partout pour avoir le code le plus rapide. -O1 produit parfois un code plus rapide que -O3 (c’est même souvent le cas avec des instrinsics SSE2 ou autre), il n’y a que les tests qui permettent de voir ça. Et c’est pas seulement 1 ou 2% de différence…


Mozilla lance Codemoji pour sensibiliser la jeunesse au chiffrement

  • Des emojis pour attirer les jeunes utilisateurs

  • Il faudra aller plus loin

Fermer