Mozilla lance Codemoji pour sensibiliser la jeunesse au chiffrement

Mozilla lance Codemoji pour sensibiliser la jeunesse au chiffrement

Un autre genre de jeu d'éveil

Avatar de l'auteur

Vincent Hermann

Publié dansLogiciel

28/06/2016
37
Mozilla lance Codemoji pour sensibiliser la jeunesse au chiffrement

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.

37
Avatar de l'auteur

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Carte graphique AMD GeForce

Cartes graphiques : 30 ans d’évolution des GPU

Ha… la bonne époque d’un CF de 4870 X2 !

18:10 Hard 13

Google lance son opération de communications Gemini pour rivaliser avec OpenAI

Preprint not PR-print

17:31 IA 5
Ecran bleu de Windows

Linux : le composant systemd se dote d’un écran bleu de la mort

LoL Micro$oft

16:33 Soft 25

Sommaire de l'article

Introduction

Des emojis pour attirer les jeunes utilisateurs

Il faudra aller plus loin

Carte graphique AMD GeForce

Cartes graphiques : 30 ans d’évolution des GPU

Hard 13

Google lance son opération de communications Gemini pour rivaliser avec OpenAI

IA 5
Ecran bleu de Windows

Linux : le composant systemd se dote d’un écran bleu de la mort

Soft 25
Une petite fille en train d'apprendre à programmer et hacker logiciels et appareils électroniques

Un roman graphique explique les logiciels libres aux enfants

SoftSociété 17
Nouveautés pour Messenger

Meta lance (enfin) le chiffrement de bout en bout de Messenger, entre autres

Socials 5

#LeBrief : cloud européen, OSIRIS-REx a frôlée la catastrophe, CPU AMD Ryzen 8040

Windows en 2024 : beaucoup d’IA, mais pas forcément un « 12 »

Soft 18
Einstein avec des qubits en arrière plan

Informatique quantique, qubits : avez-vous les bases ?

HardScience 9
Notifications iPhone

Surveillance des notifications : un sénateur américain demande la fin du secret

DroitSécu 17

En ligne, les promos foireuses restent d’actualité

DroitWeb 19

#LeBrief : modalité des amendes RGPD, cyberattaque agricole, hallucinations d’Amazon Q, 25 ans d’ISS

Logo Twitch

Citant des « coûts prohibitifs », Twitch quitte la Corée du Sud

ÉcoWeb 29
Formation aux cryptomonnaies par Binance à Pôle Emploi

Binance fait son marketing pendant des formations sur la blockchain destinées aux chômeurs

Éco 10
Consommation électrique du CERN

L’empreinte écologique CERN en 2022 : 1 215 GWh, 184 173 teqCO₂, 3 234 Ml…

Science 6
station électrique pour voitures

Voitures électriques : dans la jungle, terrible jungle, des bornes de recharge publiques

Société 75

#LeBrief : intelligence artificielle à tous les étages, fichier biométrique EURODAC

KDE Plasma 6

KDE Plasma 6 a sa première bêta, le tour des nouveautés

Soft 13
Un homme noir regarde la caméra. Sur son visage, des traits blancs suggèrent un traitement algorithmique.

AI Act et reconnaissance faciale : la France interpelée par 45 eurodéputés

DroitSociété 4
Api

La CNIL préconise l’utilisation des API pour le partage de données personnelles entre organismes

SécuSociété 3
Fouet de l’Arcep avec de la fibre

Orange sanctionnée sur la fibre : l’argumentaire de l’opérateur démonté par l’Arcep

DroitWeb 23
Bombes

Israël – Hamas : comment l’IA intensifie les attaques contre Gaza

IA 22

#LeBrief : bande-annonce GTA VI, guerre électronique, Spotify licencie massivement

Poing Dev

Le poing Dev – Round 7

Next 102
Logo de Gaia-X sour la forme d’un arbre, avec la légende : infrastructure de données en forme de réseau

Gaia-X « vit toujours » et « arrive à des étapes très concrètes »

WebSécu 6

Trois consoles portables en quelques semaines

Hard 37
Une tasse estampillée "Keep calm and carry on teaching"

Cyberrésilience : les compromis (provisoires) du trilogue européen

DroitSécu 3

#LeBrief : fuite de tests ADN 23andMe, le milliard pour Android Messages, il y a 30 ans Hubble voyait clair

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Commentaires (37)


Donk
Le 28/06/2016 à 14h33
vampire7
Le 28/06/2016 à 14h47

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.


ColinMaudry Abonné
Le 28/06/2016 à 14h56

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


Jarodd Abonné
Le 28/06/2016 à 15h23

Alors bon appétit !

<img data-src=" />


vampire7
Le 28/06/2016 à 15h30

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.


vampire7
Le 28/06/2016 à 15h41

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.


Ricard
Le 28/06/2016 à 15h51






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=" />



vampire7
Le 28/06/2016 à 15h55

Merci de lire mes messages jusqu’au bout.


CryoGen Abonné
Le 28/06/2016 à 16h13






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 ??



vampire7
Le 28/06/2016 à 16h31

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.


yoochan
Le 28/06/2016 à 17h09

@vampire7 oulà, ça pique les yeux o_O



C'est quoi le nom de cette application exactement ![:D](https://cdn2.nextinpact.com/smileys/icon_mrgreen.gif)  





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;

vampire7
Le 28/06/2016 à 17h33






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.



Ricard
Le 28/06/2016 à 17h41






vampire7 a écrit :

Merci de lire mes messages jusqu’au bout.

Pour quoi faire ?



Ricard
Le 28/06/2016 à 17h52






vampire7 a écrit :

&nbsp;
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.



Ricard
Le 28/06/2016 à 17h54






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 ?



vampire7
Le 28/06/2016 à 17h59

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


johndoe7894674551???
Le 28/06/2016 à 18h13

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

&nbsp;






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.

&nbsp;
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?



vampire7
Le 28/06/2016 à 18h40

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


Ricard
Le 28/06/2016 à 19h11






uhsdhfezu a écrit :

&nbsp;
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



Ricard
Le 28/06/2016 à 19h13






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.



vampire7
Le 28/06/2016 à 19h31

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.


Ricard
Le 28/06/2016 à 19h41






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=" />



Vekin Abonné
Le 29/06/2016 à 06h15






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



Zig76
Le 29/06/2016 à 06h33

&nbsp; Intéressant ce fil!


vampire7
Le 29/06/2016 à 08h44

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.


Vekin Abonné
Le 29/06/2016 à 08h58

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


vampire7
Le 29/06/2016 à 10h02

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.


Vekin Abonné
Le 29/06/2016 à 11h14

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 ?


vampire7
Le 29/06/2016 à 11h36

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.


Zerdligham Abonné
Le 29/06/2016 à 11h57

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


Ricard
Le 29/06/2016 à 17h26






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.



vampire7
Le 29/06/2016 à 17h43

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


Ricard
Le 29/06/2016 à 17h46






vampire7 a écrit :

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

Non.<img data-src=" />



jimmy_36
Le 30/06/2016 à 12h54

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;


vampire7
Le 30/06/2016 à 15h27






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



jimmy_36
Le 30/06/2016 à 15h35

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;


vampire7
Le 30/06/2016 à 16h19






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…