Plus que le fait que tu rédiges des messages insultants, ce qui me désole le plus c'est qu'il se trouve des gens pour les plusser. Ton opinion et ta véhémence seraient donc représentatives… J'attire quand même ton attention sur le fait que tu utilises beaucoup d'insultes : "répugnants bricolages d’adolescents", tu m'accuses de souhaiter "semer le chaos et la confusion" (rien que ça), de n'avoir "rien à taper" des conséquences de mes actes, d'être un "égoïste" de "mauvaise volonté nuisible" etc. C'est difficile de répondre en restant zen (je fais ce que je peux), ça ne facilite pas le débat et du coup ne facilite pas l'émergence de la vérité.
Je ne penses pas que tu (vous) sois malveillant, ni même que tu sois un "méchant", pas plus que je ne crois être le "gentil". Je crois que chacun défend les idées qui lui semblent justes ou vraies, mais que nous ne sommes pas d'accord sur ce qui est juste ou vrai, tout simplement. Évidemment, je pense avoir raison (ici, parce que je pense avoir un éclairage plus large que celui proposé jusqu'ici), mais si on réfute mes arguments, je peux changer d'avis. J'espère qu'il en va de même pour toi, raison pour laquelle je discute avec toi.
Sur le fond, je commence par ton meilleur argument
Faux: Je refuse ce machin, et j'accepte l'idée qu'il pourrait y avoir un privilège masculin.
Exact. Il aurait fallu que j'écrive "Accepter l'écriture non-genrée implique d'accepter l'idée qu'il pourrait y avoir un privilège masculin". Un manque de rigueur dans la rédaction, c'est une implication, pas une équivalence.
Je crois que cette idée de "transgresser la règle" rentre bien dans le modèle cout/bénefice. C'est juste que tu estimes le coût de l'écriture non-genrée comme très élevé, à cause du fait qu'il nécessite de "transgresser une règle". Tu sembles penser que "transgresser une règle" est forcément dramatique. La transgression de certaines règles à des conséquences dramatiques (e.g. transgresser la règle: tu ne tueras point), mais transgresser d'autres règles en a beaucoup moins (e.g. tondre à 9h le matin le dimanche alors que ta commune l'interdit avant 11h). D'autres part les règles évoluent en permanence (on écrit de nouvelles loi en permanence), parfois suite à des transgressions. C'est d'ailleurs le cas du vocabulaire français (on ajoute des nouveaux mots en permanence dans le dictionnaire), et même de la grammaire (on n'écrit plus comme au temps de molière). Bref, rien de dramatique à changer un peu le français.
Pour ce qui est des conséquences, à quoi penses-tu ? Qu'est-ce qu'une "conséquence récursive" ? Quelles conséquences "stratégiques" ? Comment va-t-on "dans le mur" exactement ? Tu n'es pas très loin de nous prédire l'apocalypse pour de bon…
Et donc, il faudrait que sur linuxfr, pour quelque raison que ce soit, on forke le français ?
Pas vraiment. On te demande pas de changer ta manière d'écrire. On te demande juste d'autoriser les gens qui écrivent de manière non-genrée à le faire sur Linuxfr. Le changement ne vient pas de linuxfr, il s'agit d'accepter (ou non) ce changement (qui vient d'ailleurs) sur linuxfr.
Et dernier truc: "C'est quoi au juste un linuxfrien (on dit une moule, au fait)"
J'utilise linuxfrien pour désigner un lecteur de linuxfr. J'ai pas utilisé moule parce qu'à mon sens ça désigne plutot ceux qui glandent sur la tribune (ou le bouchot). Donc les moules c'est un subset des linuxfriens. Et puis bon tu vas pas me faire la leçon, si j'en crois les dates de création de profil, je me suis inscrit pas loin de 7 ans avant toi, hein.
Je rentre pas directement dans le débat mais je voulais juste vous faire remarquer qu'àmha vous tournez autour de votre point de désaccord sans vraiment le nommer.
Ici, on a deux hypothèses:
Hyp. A: Le langage genré renforce les discriminations envers les femmes
Hyp. Non-A: Le langage genré ne renforce pas les discriminations envers les femmes.
Ariasuni a apporté quelques éléments (que je n'ai pas lus) en faveur de A semble-t-il. Jc-32 les juge plutot bons et pense que A est plus probable que Non-A (sans dire que c'est une certitude). Michaël et kantien les jugent invalides, et pensent donc qu'il n'y pas de preuve en faveur de A. Vous n'êtes pas d'accord certes sur ce point, mais votre divergence est ici légère.
Nos actions (ici agir = changer notre manière d'écrire) ne dépendent pas seulement de la probabilité qu'on nos actions d'être bénéfiques, mais aussi de l'ampleur (ampleur au sens magnitude) supposée du bénéfice et du cout.
En fait, vos métaphores du médicament, du parapluie et du juge sont excellentes pour illustrer ça. Le médicament, supposons deux cas.
Cas 1. Bénéfice faible (e.g. atténuer les symptomes d'un mal de gorge), Cout moyen (e.g. possibilité d'une atteinte hépatique). Dans ce cas, je vais exiger une probabilité très faible de payer le cout (e.g. moins d'une chance sur 10000 de mourir).
Cas 2. Bénéfice très élévé (e.g. soigne le cancer du pancréas), Cout élevé (e.g. peut causer la mort). Dans, ce cas, je vais accepter une probabilité élevée de payer le cout (e.g. même si j'ai 1 chance sur 100 de mourir, je vais prendre le médoc vu le bénéfice et le cout).
Le parapluie
Supposons qu'il y a 9 chances sur 10 qu'il fasse beau demain. Vous pouvez quand même décider de prendre un parapluie, parce que ça ne vous coute rien d'en prendre un (bénefice élevé: pas être mouillé, cout nul). Si en revanche vous détestez trimbaler un parapluie pour rien, vous ne le prendrez pas (bénéfice élevé: pas être mouillé, cout élevé: vous détestez être encombré).
Le juge
Cout extrêmement élevé: Enfermer un innocent c'est extrêmement grave (en tous cas, c'est ce qu'on pense dans nos sociétés)
Bénefice élevé: Enfermer un coupable, ça a un bénéfice élevé (protège la société, effet dissuasif etc.).
Du coup, on exige une probabilité très élévée (présomption d'innocence, le parquet doit prouver avec certitude la culpabilité).
Et l'écriture non-genrée dans tout ça ? Il me semble que jc-32 trouve le coût faible (impact faible sur la grammaire), et le bénéfice élevé (il me semble assez convaincu que les femmes ne puissent pas se sentir bienvenues sur linuxfr). Michael et kantien pensent le coût élevé (changement d'une règle établie, validée par une instance de normalisation, l'académie française), et le bénéfice faible (j'interprète peut-être mal, mais il me semble qu'ils pensent qu'il n'y pas de raison particulière que les femmes se sentent malvenues sur linuxfr).
Vous l'aurez peut-être deviné de part mes précédents commentaires, je suis plutôt de l'avis de jc-32. Je ne pense pas pouvoir vous convaincre (Michael et kantien), mais je voudrais apporter quelques éléments qui montrent que vous pourriez sur-estimer le cout et sous-estimer le bénéfice.
Il me semble que ce n'est pas un changement profond de la grammaire/structure de la langue; il n'y a pas besoin de l'expliquer: les linuxfriens comprennent directement ce que veut dire utilisateurices ou tout-es. Surtout, on ne demande même pas aux linuxfriens de changer leur manière d'écrire, on demande juste à accepter qu'on puisse écrire de manière non-genrée. C'est une demande très limitée, tout de même.
Aussi, et ce sera mon argument principal, dans le cas de l'écriture non-genrée, nous (les hommes sur linuxfr) devons payer une partie du coût (accepter de lire un texte un peu plus difficile à décoder, et surtout accepter l'idée que peut-être les femmes ne pourraient pas se sentir bienvenues sur linuxfr et donc qu'il y aurait une forme de privilège masculin), mais nous n'en tirerons aucun bénéfice (si jamais il y a un bénéfice, ce sera pour les femmes, donc difficile à évaluer pour nous). Il me semble que cette situation (cout pour moi et bénéfice pour les autres) introduit un biais inconscient (et naturel) sur la manière dont nous estimons l'ampleur du bénéfice et du cout.
Si je ne vous ai pas convaincu du bien fondé de l'écriture non-genrée, j'espère vous avoir encouragé a essayer de prendre conscience de certains biais de raisonnement que vous pourriez (notez le conditionnel) avoir. Accepter l'écriture non-genrée c'est accepter l'idée qu'il pourrait y avoir un privilège masculin. Rien que le principe de demander des preuves scientifiques (donc un très haut niveau de preuve) à quelqu'un juste pour qu'il puisse écrire comme il veut, ça dit quelquechose de nos représentations (conscientes ou inconscientes).
Posté par X345 .
En réponse au journal Retour sur le « No poo ».
Évalué à 9.
Dernière modification le 25 juillet 2016 à 13:24.
Heu, comme dis plus bas, ça fait environ 3500 ans que l'on utilise la saponification pour faire du savon d'Alep. Les produits sont relativement naturels et le procédé plutôt simple. […]
C'est encore ce même argument que si c'est ancien et simple, ça doit être plus naturel donc meilleur pour la santé.
En plus dire que les produits pour fabriquer du savon sont relativement naturels, ça me laisse un peu songeur. La soude caustique, relativement naturelle ? Vraiment ?
Alors oui, c'est plus simple de synthétiser de la soude, puis de fabriquer du savon que de synthétiser du sodium laureth sulfate et de fabriquer un gel douche. Et ça fait plus longtemps qu'on maitrise le procédé de fabrication de la soude et du savon. Mais en quoi c'est naturel ?
Pour être absolument clair, le bicarbonate de soude, le bicarbonate de cuisine et le bicarbonate de sodium, c'est exactement la même chose. Tous les trois désignent l'hydrogénocarbonate de sodium (NaHCO3).
D'ailleurs au passage la soude, ou soude caustique c'est de l'hydroxyde de sodium (NaOH).
Alors, si ça peut te rassurer, tu n'es pas le seul. En lisant le titre, j'avais supposé qu'il s'agissait d'un nouveau régime alimentaire à la mode ayant pour objectif de réduire la quantité… d'excréments produits par le corps humain.
Alors je ne sais pas tu faisais du second degré, mais je vais faire l'explication de texte, quitte à ruiner la blague initiale.
Donc l'image décrit les molécules composant une fraise 100% naturelle. Les fraises de ton jardin contiennent exactement ça. Certains colorants et additifs (oui les fameux EXXX qui-font-peur), sont extraits de produits naturels. Par example si vous aspergez un guacamole de jus de citron pour pas que les avocats noircissent, alors vous avez utilisé l'additif E330 (acide critique). La fraise contient naturellement du beta-carotène (qui lui donne en partie sa couleur), donc elle contient du E160a.
Un truc intéressant à noter est que la fraise naturelle contient un très longue liste d'arômes (flavors). En effet, les gout naturels sont en général très complexes. Le gout fraise fait intervenir plusieurs dizaines de molécules. Même chose pour certaines odeurs de fleurs qui nécessitent plusieurs centaines de molécules. C'est pour ça qu'on a du mal à les synthétiser. Si vous avez déjà mangé un yaourt ou un bonbon à la cerise, vous aurez remarqué que c'est assez loin du gout d'une cerise. C'est parce que l'arome de synthèse utilisé dans ce yaourt ou ce bonbon ne comporte qu'une ou quelques molécules (qui d'ailleurs ne sont pas forcément les mêmes que les naturelles, mais suffisamment proches pour faire illusion). Donc l'arome de synthèse fraise contient moins de noms de molécules qui font peur que l'arome naturel.
Bref, c'est assez facile de se faire peur pour rien juste parce qu'on lit des noms chimiques qu'on ne comprends pas… Tu savais que 100% des personnes ayant déclaré un cancer avait consommé du monoxyde de dihydrogène ? Pire, la seule consommation d'une trop grande quantité de monoxyde de dihydrogène peut entrainer la mort ! Pire encore, ce produit est en ventre libre en supermarché, et est présent comme additif dans de très nombreuses préparations industrielles. Tu penses qu'on devrait interdire le monoxyde de dihydrogène ?
La saponification, tu peux la faire chez toi, avec des produits assez simples.
Ça ne fait toujours pas du savon un produit naturel. Il est issu d'une synthèse chimique, comme le gel douche.
En fait je m'oppose à cette idée fausse que simple = naturel = sain. Ce n'est pas parce qu'on ne comprend pas quelquechose que c'est dangereux, et inversement ce n'est pas parce qu'on croit comprendre quelquechose que ce n'est pas dangereux. Ce n'est parce qu'on peut fabriquer du savon dans son garage (simple) que c'est un produit naturel. Et ça ne veut pas dire non plus que c'est plus sain qu'un autre produit de synthèse (le gel douche).
Enfin vraiment, écrire "savon naturel", c'est un oxymore…
le savon de Marseille ( le naturel, pas celui coloré :D ).
Honnêtement le savon de Marseille n'a rien de "naturel". En tous cas, rien de plus naturel que le sodium laureth sulfate des gels douches et savons. C'est un produit de synthèse, obtenu par une réaction chimique qui-fait-peur (saponification). Une réaction chimique exothermique (au secours !) impliquant de l'hydroxyde de sodium, un produit corrosif qui peut causer des brûlures chimiques, rendez-vous compte !
Et il utilise un interconnect spécifique (pas de l'ethernet standard…), comme une bonne partie des supercalculateurs. Bref, il est tout sauf standard (interconnect spécifique, processeur manycore spécifique, jeu d'instruction spécifique etc.).
Quand à la remarque sur le prix, m'étonnerai pas que la Chine soit prête à lacher des masses de pognon pour gagner le concours de celui qui a le plus gros supercalculateur avec les USA. Donc si ça se trouve le processeur SW26010 est hors de prix.
Dites, vous avez regardé la date avant de réagir avec vos réflexes de 2016 ?
Appollo 11, ça date de 1969. La première version du langage C date de 1972. Donc clairement, ça aurait pas pu être du pseudo C.
À l'époque, y'avait quelques langages de haut niveau (Fortran, Cobol), mais les compilateurs n'étaient pas aussi fiables qu'actuellement. Si vous discutez avec des ingénieurs qui ont fini leur études dans les années 70, certains vous expliquent qu'ils ont du recommencer leur projet de fin d'études en assembleur parce que le compilateur Algol ne marchait pas finalement. C'est inimaginable de nos jours. Alors ça ne m'étonnerai pas qu'en 1969, on ait décidé que les compilateurs n'étaient pas assez fiables pour leur confier la compilation d'un code qui fait atterrir un engin lunaire.
AES, utilise généralement un cœur spécialisé chiffrement […]
Non. Sur les processeurs Intel, les instructions AES-NI ne sont ni exécutées par un coprocesseur, ni par un core dedié. Elles sont exécutées comme n'importe qu'elle autre instruction. En particulier, elles utilisent les registres SIMD (1) (donc pas de registres spécifiques), elles sont décodées et pipelinées exactement comme toutes les autres instructions, et sont dispatchées sur les ports d'éxecution du processeur (2). En fait, tout laisse à penser qu'elles ont été implémentées dans l'ALU SIMD, comme n'importe quelle autre instruction SIMD.
les instructions SIMD à n opérandes sont complètement dans la philosophie RISC, on les trouve depuis des années, la philosophie du RISC, consiste à avoir des instructions simple […]
Honnêtement, je vois pas trop ce que les instructions SIMD des processeurs Intel récents (genre AVX) ont de RISC (ou de simple). Elles sont probablement parmi les plus complexes à décoder: le schéma de codage (VEX) supporte entre 2 et 4 opérandes, des registres de 128 bit ou 256 bit (3). Au passage les opérandes peuvent parfois être en mémoire, parfois dans des registres. Une partie de ces instructions est microcodée, et certaines font le café…
Et malgré le fait qu'elles soient complexes, ces instructions permettent souvent des gros gains de performance.
Le problème est que tu manipules un concept tellement flou "la philosophie RISC" qu'on arrive pas à discuter. Tu nous dit que le philosophie RISC, c'est: un core simple, des instructions simple, et du KISS. On a montré que que RISC != core simple. Aujourd'hui le décodage d'instruction CISC, ça consomme que dalle en silicium comparé aux caches, pipeline et autre. Après, "instruction simple", ça ne veut rien dire. C'est quoi une instruction simple ? c'est une instruction pas microcodée ? c'est une instruction qui ne fait qu'une seule opération ? La seule chose qu'on peut dire c'est que RISC, c'est Reduced Instruction Set Computing, dont ça suppose un jeu d'instruction réduit, donc peu d'instructions, donc que des instructions généralistes. La multiplication actuelle des instructions SIMD, des plus en plus spécifiques, c'est pas très RISC parce que ça augmente la taille du jeu d'instruction. Pareil, le concept de "KISS", y'a rien de plus flou.
Je réinsiste, mais encore une fois, je pense que t'es a côté de la plaque dans des interpretations. C'est pas un problème de Intel vs ARM (ou CISC vs RISC), c'est un problème de CPU versus GPU (ou proco manycore). Les trois premiers calculateurs ont tous des GPU/manycore: SW26010, Xeon Phi ou Nvidia Tesla. Les GPU (ou manycore) offrent 5-10 fois plus de performance à consommation équivalente par rapport au processeurs multicore classiques, mais uniquement sur des workload très parallèles (et sans branchements, et sans accès aléatoire à de la mémoire). Les GPU ont pas mal révolutionné le monde du HPC: aujourd'hui personne n'entraine des réseaux de neurones sans GPU. Les GPU sont devenu l'outil d'exécution standard pour une partie des workload scientifiques. Donc encore une fois, le monde des processeurs n'est pas divisé entre CISC/RISC mais entre CPU/GPU.
Ensuite, c'est une erreur de tirer des conclusion générales sur la performance d'un processeur. Oui le SW26010 marche très bien pour faire du calcul scientifique, mais pour faire tourner nginx + RoR + PostgreSQL, il sera problablement très mauvais (oui plus mauvais qu'un bon vieux Xeon). Ça n'a pas vraiment de sens de parler de la performance "en général" d'un processeur. Un processeur est bon ou mauvais sur une workload donnée. S'il s'agit de multiplier des matrices, le SW26010 sera très bon, il va bénéficier de toutes les unités SIMD qu'on a fourré sur le chip. S'il s'agit d'exécuter ta page RoR et que la base données a besoin d'aller chercher des trucs partout dans la mémoire, mieux vaut un Xeon avec son gros pipeline, son caché énorme, et ses 3 controlleurs mémoire par cœur qui vont permettre d'extraire de l'IPC.
le fait d'utiliser des instructions complexes consomment toujours plus d'énergie en étant toujours moins optimal.
C'est complètement faux. Les instructions très spécialisé sont bien plus efficace
En fait je crois qu'on peut dire que ça dépend. Effectivement pour AES-NI, les implémentations hardware sont très efficaces. Pour d'autres instructions, type VGATHER, j'ai déjà eu des pertes de performance en comparaison à l'utilisation d'un ensemble d'instructions plus simples. Pareil dans certains cas, pour faire un pop count, les instructions SIMD "simples" sont plus efficaces que l'instruction "complexe" POPCNT microcodée (SSE3: fast popcount). Mais dans l'ensemble, je suis plutot d'accord avec toi, les instructions "qui font le café" microcodées sont souvent très efficaces.
Le jeu d'instruction reste plus simple sur les RISC que sur les CISC aujourd'hui et le fait d'utiliser des instructions complexes consomment toujours plus d'énergie en étant toujours moins optimal. […]
Si tu as une référence relativement récente (c'est à dire qui date pas de 1995 avec des processeurs gravés en 250nm) sur la consommation d'énergie des architectures CISC vs RISC, je suis intéressé. Intel arrive à faire des processeurs avec un TDP très faible (voir par exemple, List of Intel Atom processors), qui pourtant supportent tout un tas d'instructions CISC à la FCOS ou FSIN.
En fait, j'ai l'impression qu'aujourd'hui, le fait qu'un core soit RISC ou CISC a peu d'impact sur sa performance, et sur sa consommation énergétique. Dans les années 1990, un core RISC était un core simple (= consommant peu de silicium), et un core CISC était un core complexe (= consommant beaucoup de silicium). C'était du au fait que le core CISC utilisait du silicium pour implémenter des instructions complexes à la FCOS. Depuis ce temps, on a gagné un facteur 10 en finesse de gravure (dans les années 90, on faisait du 250nm, maintenant on est vers 25nm). Aujourd'hui implémenter les instructions CISC consomme une quantité de silicium négligeable. D'autres facteurs, comme la taille et la configuration des caches, la taille du pipeline, ou le nombre d'unités redondantes vont avoir plus d'impact sur la consommation de silicium et consommation d'énergie que le fait d'être RISC ou CISC. Il y a moins de différence (en terme de conso. énergie et silicium) entre un core d'IBM Power7 et un core de Intel Xeon (deux processeurs multicore, l'un RISC et l'autre CISC) qu'entre un core de Intel Xeon et un core de Intel Xeon Phi (un processeur multicore, un manycore, les deux CISC). Sur un processeur moderne, les caches utilisent une grosse partie du silicium (voire par exemple, Haswell-E processor features, 6e slide, Intel Core 5960X Processor Die Map), pas l'implémentation des instructions CISC.
Force est de constater que le processeur chinois semble très puissant et le mystère qui entoure son architecture encourage toutes les spéculations.
Il y a quand même quelques éléments qui ont fuité, et qui expliquent pas mal la perf obtenue. Voir par exemple Report on the Sunway TaihuLight System, par Jack Dongarra.
Tu as raison de faire remarquer l'architecture très particulière de ce nouveau super calculateur; c'est la première fois qu'on voit calculateur n'incluant aucun processeurs connu: Intel Xeon, IBM Power ou Sparc. Par contre, tu sembles (en tous cas, c'est mon interprétation) en tirer la conclusion d'une victoire du RISC sur le CISC, et par extention des architectures historiquement RISC (e.g. ARM) sur les architectures historiquement CISC (e.g. x86).
Ça me semble être une erreur parce que la distinction RISC/CISC a de moins en moins de sens. Les processeurs Intel actuels (typiquement labelés CISC) découpent les instructions en micro-opérations (notés µops) élémentaires qu'ils exécutent ensuite. Inversement, les processeurs ARM ont maintenant des instructions qu'on pourrait qualifier de complexes (e.g. instructions SIMD qui opèrent sur des vecteurs). Aujourd'hui, on appelle CISC les jeux d'instructions qui distinguent les opérations mémoires des opérations arithmétiques. Par exemple, les processeurs Intel (CISC) offrent une instruction ADD qui peut prendre une opérande en mémoire. En interne, le processeur exécute une instruction de chargement mémoire, suivie d'une addtion entre deux registrees. Sur un processeur ARM (RISC), il faut d'abord . En fait, de nos jours, la différence entre un processeur CISC et un processeur RISC est assez minime, et surtout n'a que peu d'impact sur la performance du processeur. D'autres facteurs influencent plus la performance comme la taille du pipeline d'exécution, la taille et la configuration des caches, la fréquence, et la répartition des unités de calculs.
J'ai l'impression qu'on peut distinguer trois grandes familles de "processeurs" (je note processeurs entre guillemets car certains "processeurs" commencent à ne plus ressembler beaucoup à l'idée qu'on se fait d'un processeur).
Processeurs multicore: Dans cette catégorie, on pourrait ranger le processeur ARM de votre smartphone, celui de votre laptop, les Intel Xeon, Sparc et autres IBM Power. Ce type de processeur contient relativement peu de core (< 30), mais chaque core offre une une performance élevée. Chaque core offre une performance élevée parce qu'il est complexe, et donc qu'il utilise un surface de silicium élevée. Et donc, mécaniquement on peut pas en caser énormément sur un chip. Pour obtenir des bonnes performances, les cores ont un pipeline relativement long, offrent plusieurs niveaux de cache (2 voire 3 niveau), qui peuvent atteindre plusieurs Mo, disposent d'unité de calculs redondantes (ce qui permet d'obtenir un bon IPC), et aussi d'unités SIMD (qui permettent de travailler directement sur des vecteurs).
Processeurs manycore: Dans cette catégorie on pourrait ranger les Xeon Phi d'Intel, mais aussi les SW26010 utilisés dans le Sunway TaihuLight. Ce type de processeur contient plus de cores de calcul (50-300), mais contient des cores plus simples, qui occupent moins de silicium. Chaque core offre donc une performance moins élevée que dans les processeurs multicores. En général, les cores ont des pipelines moins long, ne sont pas forcément out-of-order, ont des caches moins gros, ont moins d'unités redondantes. Par contre en général, les cores proposent une unité SIMD. Les cores ont aussi une fréquence moin
GPU: Dans cette catégorie, on pourrait ranger n'importe quel GPU Nvidia, en particulier les Nvidia Telsa dédiés au calcul scientifique. Ce type de "processeur" continent beauoup de cores de calcul (1000-5000), mais chaque core est très simple. En fait, on peut à peine parler de core tellement chaque core est réduit à sa plus simple expression. Chaque core n'a pas d'unité de décodage d'instruction indépendante, ils sont coordonés par groupes (warp) de 32 cores (sur les cartes Nvidia) qui doivent exécuter la même instruction à un instant t. Evidemment chaque core n'a pas de pipeline, ni d'unité redondantes, ni d'unité SIMD. Les caches sont partagés entre plusieurs cores.
Depuis quelques années, les supercalculateur tirent le gros de leur puissance de calcul soient de processeurs manycore, soit de GPU. Ce type de processeur offre de meilleurs performances que les multicores sur des workload très parallèles, mais moins bonnes sur des workload plus séquentielles. En général, les workload HPC sont bien parallélisables (le en général est quand même à prendre avec des pincettes). Du coup, les manycore ou GPU sont avantagés parce qu'il n'y a pas de silicium "gaché" pour avoir une performance séquentielle élevée (long pipeline, unité redondantes, cache inutilement gros). À ce titre, le Sunway TaihuLight n'est pas si étonnant et entérine juste le fait que les manycore et GPU sont avantageux en HPC. Par contre, c'est quand même la première fois qu'on voit un supercalculateur sans aucun processeur multicore.
La Chine entérine aussi sa supériorité technologique naissante, avec non seulement les deux premiers calculateurs du TOP500, mais aussi avec un processeur de conception maison.
Certaines écoles qui sont normalement "post-bac" prennent des étudiants de prépa en 3ème année pour remplir leurs départements de spécialité. C'est au moins vrai pour certains INSA, tu peux peut-être regarder de ce côté.
Y'a quelques années j'avais aussi acheté une carte Digilent (une Nexys 3 à l'époque) chez Trenz Electronic. Je n'avais eu aucun problème particulier, la livraison s'était faite par UPS et s'était bien passée (même si lacher 40€ pour faire venir un truc d'Allemagne, j'avais trouvé ça cher).
Posté par X345 .
En réponse à la dépêche Linux Mint a été compromise.
Évalué à 10.
Dernière modification le 07 mars 2016 à 18:24.
Non, ton calcul d'entropie est erroné et tu fais la même erreur que Nairwolf.
Dans le calcul de nombre de bits d'entropie pour quatre mots du dictionnaire (5000 mots), je calcule 50004 (49 bits) et non pas: 2624 (112 bits) ce qui correspondrait à 4 mots aléatoires de 6 caractères chacun (ie 24 caractères aléatoires).
Il n'y pas de problème particulier à utiliser des mots du dictionnaire, c'est juste que le dictionnaire est un ensemble de petite taille et donc génère une entropie assez faible. Si vous faites suffisamment (4-5) de tirages dans cet ensemble, l'entropie générée est satisfaisante.
C'est exactement l'idée du XKCD: mieux vaut tirer trois mots aléatoirement du dictionnaire qu'un mot de passe alphabétique lowercase aléatoire de 6 caractères. C'est peut-être contre intuitif parce qu'on nous répète de craindre les attaques par dictionnaire depuis des années. Mais en faisant les calculs d'entropie, on voit que la première alternative est largement supérieure.
Il n'y a pas de différence fondamentale entre une attaque bruteforce et une attaque dite par dictionnaire: dans les deux cas l'attaquant énumère un ensemble de mots de passe possible. La seule chose qui importe est la taille de cet ensemble.
Tu te trompes, le nombre de bits d'entropie définit complètement la sécurité d'un mot de passe. Si un mot de passe a b bits d'entropie, alors il faut essayer 2b mot de passes pour le deviner, quelque soit le type d'attaque.
La nombre de bits d'entropie d'un mot de passe est le log_2 du nombre de possibilités.
Par exemple, pour 4 mots choisis au hasard dans un dictionnaire de 5000 mots (vocabulaire courant): entropie = log_2(5000^4) = 49 (bits d'entropie, ie 2^49 possibilités)
Note qu'ici, on fait la supposition d'une attaque par dictionnaire: l'attaquant sait que le mot de passe utilisé est composé de 4 mots du dictionnaire.
Pour un mot de passe de 8 caractères (majuscules, minuscules, chiffres = 2*26+10=62 possibilités par caractère): entropie = log_2(62^8) = 47 (bits d'entropie, ie 2^47 possibilités)
Pour un mot de passe de 13 caractères (majuscules, miniscules, chiffres + caractères spéciaux courants = 2*26+10+10 = 72 possibilités par caractère): entropie = log_2(72^13) = 80 (bits d'entropie, ie 2^80 possibilités)
Par définition, chaque bit d'entropie ajouté multiple la durée de l'attaque par deux.
Si le service/site web est correctement configuré (ie pas plus de 1000 essais par seconde, comme dans l'exemple de XKCD), 40-50 bits d'entropie sont largement suffisants. Si la base de données fuite (offline crack) et utilise un hashage faible (par exemple 1 itération de SHA256), alors au minimum 80 bits d'entropie sont nécessaires. Si la base de données fuite et utilise un hashage fort (PBKDF2 avec 10000 itérations), 50-60 bits devraient suffire.
Les schémas que tu proposes ne sont pas recommandés, mais pas très problématiques non plus. La seule propriété utile d'un sel est qu'il ne doit être utilisé qu'une et une seule fois. Avec 64 ou 128 bits aléatoires, tu es sur que jamais deux utilisateurs auront le même sel. Éventuellement en cas de particulière malchance, deux utilisateurs pourraient avoir le même nom civil ET la même date de naissance, et donc le même sel. Ce n'est pas recommandé, mais pas dramatique non plus (du moins de ce que j'en sais, je ne suis pas un expert).
Le plus simple est de sortir 8 ou 16 octets de /dev/urandom (ou autre PRNG équivalent) et de les utiliser directement. Utiliser un uuid4 (random uuid) est également une bonne idée. La principale raison pour laquelle je ne recommanderais pas ce que tu proposes est la première règle de la crypto: "Don't roll your own" (ne faites pas votre propre crypto). Mieux vaut se cantonner à la pratique standard qui consiste à sortir 8 ou 16 octets d'un PRNG.
Posté par X345 .
En réponse à la dépêche Linux Mint a été compromise.
Évalué à 10.
Dernière modification le 07 mars 2016 à 13:55.
Pas mal d'imprécisions dans le paragraphe sur le stockage des mots de passe: confusion entre les hash tables et rainbow tables, méprise sur l'utilité du salt, et pas de mention de l'utilisation des GPU qui sont quand même la méthode à l'état de l'art pour le cassage des mots de passe.
Le problème général avec le stockage des mots de passe est que même si la fonction de hachage h utilisée pour hasher un mot de passe p est robuste, ie il est impossible de déterminer p à partir de h(p), il est (relativement) facile d'énumérer tout les p. En effet l'espace P des mots de passe p est relativement petit: on ne peut pas demander aux utilisateurs de retenir des mots de passe avec 25 caractères aléatoires. En général, on demande 8-15 caractères, ce qui génère un espace petit. Par exemple pour un mot de passe totalement aléatoire de 8 caractères comprenant majuscules, minuscules et chiffres, il y a ~247 possibilités, ce qui est énumérable avec les moyens actuels (une workstation avec un GPU à 1000€ vous permet de casser ça en quelques jours).
Un des premiers moyen utilisés pour accélérer le cassage des mots de passe a été d'utiliser des tables de hash précalculés. L'idée est simple: pour une fonction de hachage h donnée (exemple: h=md5 ou h=sha256), on précalcule h(p) pour tout les mots de passe p de 0-8 caractères. Ensuite, pour un hash h(p) donné, on cherche h(p) dans la table, et on retrouve p. Le problème est que ces tables précalculées ont une taille rédhibitoire: on est déjà à plusieurs téraoctets pour des mots de passe de 5-6 caractères, et la taille augmente exponentiellement avec le nombre de caractères (donc on est à des centaines de teras pour 8 caractères). Les rainbow tables ont été inventées pour résoudre ce problème. Très grossièrement, les rainbow tables permettent d'obtenir les mêmes résultats que les tables de hash précalculés, pour une fraction de l'espace de stockage (dizaines à centaines de gigas). J'ai l'impression que l'auteur confond les rainbow tables, avec les hash tables, une structure de données couramment utilisée qui n'a rien de spécifique à la cryptanalyse. On peut aujourd'hui facilement télécharger des rainbow tables sur internet pour de nombreuses fonctions de hachage (je vous laisse chercher hein…).
Pour se protéger des attaques basées sur les rainbow tables, on utilise un salt ou sel. L'idée est très simple: au lieu de stocker le hash du mot de passe h(p) dans la base de données, on stocke le hash de concaténation du mot de passe p et du sel s : h(s.p). La rainbow table qui stocke les correspondances h(p) -> p n'est donc plus utilisable, il faut recalculer une rainbow table pour chaque sel s. Plusieurs informations érronées dans l'article: les sels ne pas des information secrètes, vous pouvez les stocker dans la base de données, avec les hash. Même si le sel n'est pas secret, et leake avec les hashs, vous êtes protégés contre les attaques basées sur les rainbow tables. La seule contrainte est que le sel doit être de taille suffisante (64-128 bits c'est très bien), et différent pour chaque utilisateur. Il ne faut pas utiliser un sel unique pour toute la base de données, parce qu'à ce moment il devient possible de calculer une rainbow table pour votre base de données. Si le sel est différent pour chaque utilisateur, il faut calculer une rainbow table par utilisateur (ce qui la rend inutile, évidemment). Je le répète: un sel différent pour chaque utilisateur, et stockez-le dans la base de données et vous êtes protégés des rainbow tables.
Bon, malheureusement, les rainbow tables ne sont plus la méthode à l'état de l'art pour le cassage des mots de passe. C'était le cas il y a dix ans, mais depuis on utilise des GPUs. Les GPUs sont très efficaces pour calculer des fonctions de hashage: une machine avec 8 GPU (~8000€) peut calculer plus de 14 milliards de hash SHA256 par seconde (voir Performance hashcat). En d'autres termes, ce genre de machine peut bruteforcer 4 milliards de mot de passes par seconde. En quelques semaines/mois, vous pouvez casser n'importe quel mot de passe de 10 caractères (Speed Hashing). Pour 9 caractères, c'est quelques heures/jours. Et ce même si un sel a été utilisé.
Pour répondre à ce problème, une des techniques utilisés est le key stretching (mais malheureusement seuls peu de systèmes/sites utilisent cette technique). L'idée est simple: au lieu de hasher une seule fois h(s.p), on hashe itérativement un nombre configurable de fois (de l'ordre de quelques dizaines de milliers à quelques centaines de milliers) h(h(h(…h(s.p))). Parmi les algorithmes qui utilisent le key stretching on trouve PBKDF2 et sha512crypt. Par exemple, cryptsetup (utilisé pour le chiffrement disque sous Linux) hashe les mots de passe en utilisant sha256 pendant 2 secondes (sur ma machine, ça fait ~50000 itérations de sha256), GPG hashe les mots de passe en faisant 65536 itérations de SHA1. PAM (sha512crypt) fait 5000 itérations de sha512 (d'ailleurs de nos jours, 5000 itérations de sha512, c'est un peu léger). L'uilisation de PBKDF2 ou sha512crypt est aujourd'hui chaudement recommandée pour atténuer les attaques utilisant des GPUs.
Le problème du key stretching est que les GPUs restent toujours très efficaces pour casser les mot de passe. Même si vous réduisez le nombre d'essais de 4 milliards/s à 100 000/s, ça reste toujours beaucoup, surtout si vos utilisateurs ont des mots de passe "normaux": par exemple 8 caractères alphabétiques lower-case. Il est aussi possible de construire du hardware spécialisé (FPGA, ASIC) pour accélérer encore plus le cassage des mot de passage. Ça se voit avec les ASIC pour miner du bitcoin (qui calcule plein de fois des hash sha256) qui sont capables de calculer des centaines de milliards de sha256 par seconde.
Pour répondre à ce problème, on est en train d'inventer des fonctions de hashage memory-hard: le hash d'un mot de passe doit non seulement être couteux en temps mais aussi utiliser une certaine quantité de mémoire (par exemple 64Mo-1Go. Pour info, pour sha512 ou sha256, on est <1Ko). Ça permet de réduire à néant l'efficacité des GPU et du hardware spécialisé. Pour un GPU avec 16Go, il n'y a que "250 blocks" de 64Mo, ce qui l'empêche de calculer plus de 250 hash par seconde. Même chose pour les ASIC: des grandes quantité de mémoire restent couteuses en espace silicium, et aussi en complexité d'adressage. Ces fonctions de hashage memory-hard restent à l'état de recherche/prototype. En Juin 2015 a eu lieu la Password Hashing Competition dont le but était de sélectionner pour standardisation une fonction de hashage de mot de passe memory-hard. Le gagnant a été argon2 dont le code source est distribué sous CC0.
En résumé :
Si vous êtes administateur ou développeur: utilisez un sel différent pour chaque utilisateur et stocké en base de données. Utilisez sha512crypt ou PBKDF2 1 avec le nombre maximal d'itérations que vous pouvez supporter. Si un délai de 0.5-1s pour une vérification de mot de passe est acceptable, utilisez 100000 itérations. Suivez l'évolution de argon2 (par exemple l'auteur de cryptsetup a annoncé sa volonté de l'utiliser), et implémentez-le lorsqu'il sort de sa phase de beta. Je fais partie de ceux qui pensent que ce n'est pas aux utilisateurs de retenir des mots de passe de 20 caractères aléatoires: c'est au admins de rendre les attaques par bruteforce impraticables.
Si vous êtes utilisateur, et que vous voulez protéger votre mot de passe quoi qu'il arrive (ie même si l'administateur d'un site n'utilise pas de sel ni de key stretching), alors il faut un mot de passe d'au moins 13 caractères aléatoires. Sinon, éviter de partager les mots de passe entre différents service, éventuellement en utilisant un wallet ou keepass (les conseils données dans l'article sont tout à fait valides sur ce domaine).
[1]: Je connais mal bcrypt et scrypt mais ce sont probablement des alternatives correctes. Gardez à l'esprit qu'elles ne sont cependant pas standardisées.
[^] # Re: Tiptop le sexisme
Posté par X345 . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 0.
Plus que le fait que tu rédiges des messages insultants, ce qui me désole le plus c'est qu'il se trouve des gens pour les plusser. Ton opinion et ta véhémence seraient donc représentatives… J'attire quand même ton attention sur le fait que tu utilises beaucoup d'insultes : "répugnants bricolages d’adolescents", tu m'accuses de souhaiter "semer le chaos et la confusion" (rien que ça), de n'avoir "rien à taper" des conséquences de mes actes, d'être un "égoïste" de "mauvaise volonté nuisible" etc. C'est difficile de répondre en restant zen (je fais ce que je peux), ça ne facilite pas le débat et du coup ne facilite pas l'émergence de la vérité.
Je ne penses pas que tu (vous) sois malveillant, ni même que tu sois un "méchant", pas plus que je ne crois être le "gentil". Je crois que chacun défend les idées qui lui semblent justes ou vraies, mais que nous ne sommes pas d'accord sur ce qui est juste ou vrai, tout simplement. Évidemment, je pense avoir raison (ici, parce que je pense avoir un éclairage plus large que celui proposé jusqu'ici), mais si on réfute mes arguments, je peux changer d'avis. J'espère qu'il en va de même pour toi, raison pour laquelle je discute avec toi.
Sur le fond, je commence par ton meilleur argument
Exact. Il aurait fallu que j'écrive "Accepter l'écriture non-genrée implique d'accepter l'idée qu'il pourrait y avoir un privilège masculin". Un manque de rigueur dans la rédaction, c'est une implication, pas une équivalence.
Je crois que cette idée de "transgresser la règle" rentre bien dans le modèle cout/bénefice. C'est juste que tu estimes le coût de l'écriture non-genrée comme très élevé, à cause du fait qu'il nécessite de "transgresser une règle". Tu sembles penser que "transgresser une règle" est forcément dramatique. La transgression de certaines règles à des conséquences dramatiques (e.g. transgresser la règle: tu ne tueras point), mais transgresser d'autres règles en a beaucoup moins (e.g. tondre à 9h le matin le dimanche alors que ta commune l'interdit avant 11h). D'autres part les règles évoluent en permanence (on écrit de nouvelles loi en permanence), parfois suite à des transgressions. C'est d'ailleurs le cas du vocabulaire français (on ajoute des nouveaux mots en permanence dans le dictionnaire), et même de la grammaire (on n'écrit plus comme au temps de molière). Bref, rien de dramatique à changer un peu le français.
Pour ce qui est des conséquences, à quoi penses-tu ? Qu'est-ce qu'une "conséquence récursive" ? Quelles conséquences "stratégiques" ? Comment va-t-on "dans le mur" exactement ? Tu n'es pas très loin de nous prédire l'apocalypse pour de bon…
Pas vraiment. On te demande pas de changer ta manière d'écrire. On te demande juste d'autoriser les gens qui écrivent de manière non-genrée à le faire sur Linuxfr. Le changement ne vient pas de linuxfr, il s'agit d'accepter (ou non) ce changement (qui vient d'ailleurs) sur linuxfr.
Et dernier truc: "C'est quoi au juste un linuxfrien (on dit une moule, au fait)"
J'utilise linuxfrien pour désigner un lecteur de linuxfr. J'ai pas utilisé moule parce qu'à mon sens ça désigne plutot ceux qui glandent sur la tribune (ou le bouchot). Donc les moules c'est un subset des linuxfriens. Et puis bon tu vas pas me faire la leçon, si j'en crois les dates de création de profil, je me suis inscrit pas loin de 7 ans avant toi, hein.
[^] # Re: Tiptop le sexisme
Posté par X345 . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 2.
Je rentre pas directement dans le débat mais je voulais juste vous faire remarquer qu'àmha vous tournez autour de votre point de désaccord sans vraiment le nommer.
Ici, on a deux hypothèses:
Hyp. A: Le langage genré renforce les discriminations envers les femmes
Hyp. Non-A: Le langage genré ne renforce pas les discriminations envers les femmes.
Ariasuni a apporté quelques éléments (que je n'ai pas lus) en faveur de A semble-t-il. Jc-32 les juge plutot bons et pense que A est plus probable que Non-A (sans dire que c'est une certitude). Michaël et kantien les jugent invalides, et pensent donc qu'il n'y pas de preuve en faveur de A. Vous n'êtes pas d'accord certes sur ce point, mais votre divergence est ici légère.
Nos actions (ici agir = changer notre manière d'écrire) ne dépendent pas seulement de la probabilité qu'on nos actions d'être bénéfiques, mais aussi de l'ampleur (ampleur au sens magnitude) supposée du bénéfice et du cout.
En fait, vos métaphores du médicament, du parapluie et du juge sont excellentes pour illustrer ça.
Le médicament, supposons deux cas.
Cas 1. Bénéfice faible (e.g. atténuer les symptomes d'un mal de gorge), Cout moyen (e.g. possibilité d'une atteinte hépatique). Dans ce cas, je vais exiger une probabilité très faible de payer le cout (e.g. moins d'une chance sur 10000 de mourir).
Cas 2. Bénéfice très élévé (e.g. soigne le cancer du pancréas), Cout élevé (e.g. peut causer la mort). Dans, ce cas, je vais accepter une probabilité élevée de payer le cout (e.g. même si j'ai 1 chance sur 100 de mourir, je vais prendre le médoc vu le bénéfice et le cout).
Le parapluie
Supposons qu'il y a 9 chances sur 10 qu'il fasse beau demain. Vous pouvez quand même décider de prendre un parapluie, parce que ça ne vous coute rien d'en prendre un (bénefice élevé: pas être mouillé, cout nul). Si en revanche vous détestez trimbaler un parapluie pour rien, vous ne le prendrez pas (bénéfice élevé: pas être mouillé, cout élevé: vous détestez être encombré).
Le juge
Cout extrêmement élevé: Enfermer un innocent c'est extrêmement grave (en tous cas, c'est ce qu'on pense dans nos sociétés)
Bénefice élevé: Enfermer un coupable, ça a un bénéfice élevé (protège la société, effet dissuasif etc.).
Du coup, on exige une probabilité très élévée (présomption d'innocence, le parquet doit prouver avec certitude la culpabilité).
Et l'écriture non-genrée dans tout ça ? Il me semble que jc-32 trouve le coût faible (impact faible sur la grammaire), et le bénéfice élevé (il me semble assez convaincu que les femmes ne puissent pas se sentir bienvenues sur linuxfr). Michael et kantien pensent le coût élevé (changement d'une règle établie, validée par une instance de normalisation, l'académie française), et le bénéfice faible (j'interprète peut-être mal, mais il me semble qu'ils pensent qu'il n'y pas de raison particulière que les femmes se sentent malvenues sur linuxfr).
Vous l'aurez peut-être deviné de part mes précédents commentaires, je suis plutôt de l'avis de jc-32. Je ne pense pas pouvoir vous convaincre (Michael et kantien), mais je voudrais apporter quelques éléments qui montrent que vous pourriez sur-estimer le cout et sous-estimer le bénéfice.
Il me semble que ce n'est pas un changement profond de la grammaire/structure de la langue; il n'y a pas besoin de l'expliquer: les linuxfriens comprennent directement ce que veut dire utilisateurices ou tout-es. Surtout, on ne demande même pas aux linuxfriens de changer leur manière d'écrire, on demande juste à accepter qu'on puisse écrire de manière non-genrée. C'est une demande très limitée, tout de même.
Aussi, et ce sera mon argument principal, dans le cas de l'écriture non-genrée, nous (les hommes sur linuxfr) devons payer une partie du coût (accepter de lire un texte un peu plus difficile à décoder, et surtout accepter l'idée que peut-être les femmes ne pourraient pas se sentir bienvenues sur linuxfr et donc qu'il y aurait une forme de privilège masculin), mais nous n'en tirerons aucun bénéfice (si jamais il y a un bénéfice, ce sera pour les femmes, donc difficile à évaluer pour nous). Il me semble que cette situation (cout pour moi et bénéfice pour les autres) introduit un biais inconscient (et naturel) sur la manière dont nous estimons l'ampleur du bénéfice et du cout.
Si je ne vous ai pas convaincu du bien fondé de l'écriture non-genrée, j'espère vous avoir encouragé a essayer de prendre conscience de certains biais de raisonnement que vous pourriez (notez le conditionnel) avoir. Accepter l'écriture non-genrée c'est accepter l'idée qu'il pourrait y avoir un privilège masculin. Rien que le principe de demander des preuves scientifiques (donc un très haut niveau de preuve) à quelqu'un juste pour qu'il puisse écrire comme il veut, ça dit quelquechose de nos représentations (conscientes ou inconscientes).
[^] # Re: Qu'en pensez-vous ?
Posté par X345 . En réponse au message Comment j'ai fabriqué un DRM pour la gestion de mon password.. Évalué à 8.
Trop gros, passera pas.
[^] # Re: savon
Posté par X345 . En réponse au journal Retour sur le « No poo ». Évalué à 9. Dernière modification le 25 juillet 2016 à 13:24.
C'est encore ce même argument que si c'est ancien et simple, ça doit être plus naturel donc meilleur pour la santé.
En plus dire que les produits pour fabriquer du savon sont relativement naturels, ça me laisse un peu songeur. La soude caustique, relativement naturelle ? Vraiment ?
Alors oui, c'est plus simple de synthétiser de la soude, puis de fabriquer du savon que de synthétiser du sodium laureth sulfate et de fabriquer un gel douche. Et ça fait plus longtemps qu'on maitrise le procédé de fabrication de la soude et du savon. Mais en quoi c'est naturel ?
[^] # Re: Bicarbonate
Posté par X345 . En réponse au journal Retour sur le « No poo ». Évalué à 10.
Pour être absolument clair, le bicarbonate de soude, le bicarbonate de cuisine et le bicarbonate de sodium, c'est exactement la même chose. Tous les trois désignent l'hydrogénocarbonate de sodium (NaHCO3).
D'ailleurs au passage la soude, ou soude caustique c'est de l'hydroxyde de sodium (NaOH).
[^] # Re: "Pas de caca" ?
Posté par X345 . En réponse au journal Retour sur le « No poo ». Évalué à 8.
Alors, si ça peut te rassurer, tu n'es pas le seul. En lisant le titre, j'avais supposé qu'il s'agissait d'un nouveau régime alimentaire à la mode ayant pour objectif de réduire la quantité… d'excréments produits par le corps humain.
[^] # Re: Non à l'obscurantisme
Posté par X345 . En réponse au journal Retour sur le « No poo ». Évalué à 10.
Alors je ne sais pas tu faisais du second degré, mais je vais faire l'explication de texte, quitte à ruiner la blague initiale.
Donc l'image décrit les molécules composant une fraise 100% naturelle. Les fraises de ton jardin contiennent exactement ça. Certains colorants et additifs (oui les fameux EXXX qui-font-peur), sont extraits de produits naturels. Par example si vous aspergez un guacamole de jus de citron pour pas que les avocats noircissent, alors vous avez utilisé l'additif E330 (acide critique). La fraise contient naturellement du beta-carotène (qui lui donne en partie sa couleur), donc elle contient du E160a.
Un truc intéressant à noter est que la fraise naturelle contient un très longue liste d'arômes (flavors). En effet, les gout naturels sont en général très complexes. Le gout fraise fait intervenir plusieurs dizaines de molécules. Même chose pour certaines odeurs de fleurs qui nécessitent plusieurs centaines de molécules. C'est pour ça qu'on a du mal à les synthétiser. Si vous avez déjà mangé un yaourt ou un bonbon à la cerise, vous aurez remarqué que c'est assez loin du gout d'une cerise. C'est parce que l'arome de synthèse utilisé dans ce yaourt ou ce bonbon ne comporte qu'une ou quelques molécules (qui d'ailleurs ne sont pas forcément les mêmes que les naturelles, mais suffisamment proches pour faire illusion). Donc l'arome de synthèse fraise contient moins de noms de molécules qui font peur que l'arome naturel.
Bref, c'est assez facile de se faire peur pour rien juste parce qu'on lit des noms chimiques qu'on ne comprends pas… Tu savais que 100% des personnes ayant déclaré un cancer avait consommé du monoxyde de dihydrogène ? Pire, la seule consommation d'une trop grande quantité de monoxyde de dihydrogène peut entrainer la mort ! Pire encore, ce produit est en ventre libre en supermarché, et est présent comme additif dans de très nombreuses préparations industrielles. Tu penses qu'on devrait interdire le monoxyde de dihydrogène ?
[^] # Re: savon
Posté par X345 . En réponse au journal Retour sur le « No poo ». Évalué à 10.
Ça ne fait toujours pas du savon un produit naturel. Il est issu d'une synthèse chimique, comme le gel douche.
En fait je m'oppose à cette idée fausse que simple = naturel = sain. Ce n'est pas parce qu'on ne comprend pas quelquechose que c'est dangereux, et inversement ce n'est pas parce qu'on croit comprendre quelquechose que ce n'est pas dangereux. Ce n'est parce qu'on peut fabriquer du savon dans son garage (simple) que c'est un produit naturel. Et ça ne veut pas dire non plus que c'est plus sain qu'un autre produit de synthèse (le gel douche).
Enfin vraiment, écrire "savon naturel", c'est un oxymore…
[^] # Re: savon
Posté par X345 . En réponse au journal Retour sur le « No poo ». Évalué à 10.
Honnêtement le savon de Marseille n'a rien de "naturel". En tous cas, rien de plus naturel que le sodium laureth sulfate des gels douches et savons. C'est un produit de synthèse, obtenu par une réaction chimique qui-fait-peur (saponification). Une réaction chimique exothermique (au secours !) impliquant de l'hydroxyde de sodium, un produit corrosif qui peut causer des brûlures chimiques, rendez-vous compte !
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par X345 . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 4.
Et il utilise un interconnect spécifique (pas de l'ethernet standard…), comme une bonne partie des supercalculateurs. Bref, il est tout sauf standard (interconnect spécifique, processeur manycore spécifique, jeu d'instruction spécifique etc.).
Quand à la remarque sur le prix, m'étonnerai pas que la Chine soit prête à lacher des masses de pognon pour gagner le concours de celui qui a le plus gros supercalculateur avec les USA. Donc si ça se trouve le processeur SW26010 est hors de prix.
[^] # Re: Assembleur
Posté par X345 . En réponse au journal Code source de Apollo 11. Évalué à 10.
Dites, vous avez regardé la date avant de réagir avec vos réflexes de 2016 ?
Appollo 11, ça date de 1969. La première version du langage C date de 1972. Donc clairement, ça aurait pas pu être du pseudo C.
À l'époque, y'avait quelques langages de haut niveau (Fortran, Cobol), mais les compilateurs n'étaient pas aussi fiables qu'actuellement. Si vous discutez avec des ingénieurs qui ont fini leur études dans les années 70, certains vous expliquent qu'ils ont du recommencer leur projet de fin d'études en assembleur parce que le compilateur Algol ne marchait pas finalement. C'est inimaginable de nos jours. Alors ça ne m'étonnerai pas qu'en 1969, on ait décidé que les compilateurs n'étaient pas assez fiables pour leur confier la compilation d'un code qui fait atterrir un engin lunaire.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par X345 . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 10.
Non. Sur les processeurs Intel, les instructions AES-NI ne sont ni exécutées par un coprocesseur, ni par un core dedié. Elles sont exécutées comme n'importe qu'elle autre instruction. En particulier, elles utilisent les registres SIMD (1) (donc pas de registres spécifiques), elles sont décodées et pipelinées exactement comme toutes les autres instructions, et sont dispatchées sur les ports d'éxecution du processeur (2). En fait, tout laisse à penser qu'elles ont été implémentées dans l'ALU SIMD, comme n'importe quelle autre instruction SIMD.
(1) Voir Intel Manual Volume 2A, Instruction Set Reference, page AESENC
(2) Voir Agner Fog, Instruction Tables, page(s) AESENC.
Honnêtement, je vois pas trop ce que les instructions SIMD des processeurs Intel récents (genre AVX) ont de RISC (ou de simple). Elles sont probablement parmi les plus complexes à décoder: le schéma de codage (VEX) supporte entre 2 et 4 opérandes, des registres de 128 bit ou 256 bit (3). Au passage les opérandes peuvent parfois être en mémoire, parfois dans des registres. Une partie de ces instructions est microcodée, et certaines font le café…
Et malgré le fait qu'elles soient complexes, ces instructions permettent souvent des gros gains de performance.
(3) Voir Intel Manual Volume 2A, Instruction Set Reference, section 2.3 Intel Advanced Vector Extensions
Le problème est que tu manipules un concept tellement flou "la philosophie RISC" qu'on arrive pas à discuter. Tu nous dit que le philosophie RISC, c'est: un core simple, des instructions simple, et du KISS. On a montré que que RISC != core simple. Aujourd'hui le décodage d'instruction CISC, ça consomme que dalle en silicium comparé aux caches, pipeline et autre. Après, "instruction simple", ça ne veut rien dire. C'est quoi une instruction simple ? c'est une instruction pas microcodée ? c'est une instruction qui ne fait qu'une seule opération ? La seule chose qu'on peut dire c'est que RISC, c'est Reduced Instruction Set Computing, dont ça suppose un jeu d'instruction réduit, donc peu d'instructions, donc que des instructions généralistes. La multiplication actuelle des instructions SIMD, des plus en plus spécifiques, c'est pas très RISC parce que ça augmente la taille du jeu d'instruction. Pareil, le concept de "KISS", y'a rien de plus flou.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par X345 . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 10.
Je réinsiste, mais encore une fois, je pense que t'es a côté de la plaque dans des interpretations. C'est pas un problème de Intel vs ARM (ou CISC vs RISC), c'est un problème de CPU versus GPU (ou proco manycore). Les trois premiers calculateurs ont tous des GPU/manycore: SW26010, Xeon Phi ou Nvidia Tesla. Les GPU (ou manycore) offrent 5-10 fois plus de performance à consommation équivalente par rapport au processeurs multicore classiques, mais uniquement sur des workload très parallèles (et sans branchements, et sans accès aléatoire à de la mémoire). Les GPU ont pas mal révolutionné le monde du HPC: aujourd'hui personne n'entraine des réseaux de neurones sans GPU. Les GPU sont devenu l'outil d'exécution standard pour une partie des workload scientifiques. Donc encore une fois, le monde des processeurs n'est pas divisé entre CISC/RISC mais entre CPU/GPU.
Ensuite, c'est une erreur de tirer des conclusion générales sur la performance d'un processeur. Oui le SW26010 marche très bien pour faire du calcul scientifique, mais pour faire tourner nginx + RoR + PostgreSQL, il sera problablement très mauvais (oui plus mauvais qu'un bon vieux Xeon). Ça n'a pas vraiment de sens de parler de la performance "en général" d'un processeur. Un processeur est bon ou mauvais sur une workload donnée. S'il s'agit de multiplier des matrices, le SW26010 sera très bon, il va bénéficier de toutes les unités SIMD qu'on a fourré sur le chip. S'il s'agit d'exécuter ta page RoR et que la base données a besoin d'aller chercher des trucs partout dans la mémoire, mieux vaut un Xeon avec son gros pipeline, son caché énorme, et ses 3 controlleurs mémoire par cœur qui vont permettre d'extraire de l'IPC.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par X345 . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 3.
En fait je crois qu'on peut dire que ça dépend. Effectivement pour AES-NI, les implémentations hardware sont très efficaces. Pour d'autres instructions, type VGATHER, j'ai déjà eu des pertes de performance en comparaison à l'utilisation d'un ensemble d'instructions plus simples. Pareil dans certains cas, pour faire un pop count, les instructions SIMD "simples" sont plus efficaces que l'instruction "complexe" POPCNT microcodée (SSE3: fast popcount). Mais dans l'ensemble, je suis plutot d'accord avec toi, les instructions "qui font le café" microcodées sont souvent très efficaces.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par X345 . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 7.
Si tu as une référence relativement récente (c'est à dire qui date pas de 1995 avec des processeurs gravés en 250nm) sur la consommation d'énergie des architectures CISC vs RISC, je suis intéressé. Intel arrive à faire des processeurs avec un TDP très faible (voir par exemple, List of Intel Atom processors), qui pourtant supportent tout un tas d'instructions CISC à la FCOS ou FSIN.
En fait, j'ai l'impression qu'aujourd'hui, le fait qu'un core soit RISC ou CISC a peu d'impact sur sa performance, et sur sa consommation énergétique. Dans les années 1990, un core RISC était un core simple (= consommant peu de silicium), et un core CISC était un core complexe (= consommant beaucoup de silicium). C'était du au fait que le core CISC utilisait du silicium pour implémenter des instructions complexes à la FCOS. Depuis ce temps, on a gagné un facteur 10 en finesse de gravure (dans les années 90, on faisait du 250nm, maintenant on est vers 25nm). Aujourd'hui implémenter les instructions CISC consomme une quantité de silicium négligeable. D'autres facteurs, comme la taille et la configuration des caches, la taille du pipeline, ou le nombre d'unités redondantes vont avoir plus d'impact sur la consommation de silicium et consommation d'énergie que le fait d'être RISC ou CISC. Il y a moins de différence (en terme de conso. énergie et silicium) entre un core d'IBM Power7 et un core de Intel Xeon (deux processeurs multicore, l'un RISC et l'autre CISC) qu'entre un core de Intel Xeon et un core de Intel Xeon Phi (un processeur multicore, un manycore, les deux CISC). Sur un processeur moderne, les caches utilisent une grosse partie du silicium (voire par exemple, Haswell-E processor features, 6e slide, Intel Core 5960X Processor Die Map), pas l'implémentation des instructions CISC.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par X345 . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 5.
Il y a quand même quelques éléments qui ont fuité, et qui expliquent pas mal la perf obtenue. Voir par exemple
Report on the Sunway TaihuLight System, par Jack Dongarra.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par X345 . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 10.
Tu as raison de faire remarquer l'architecture très particulière de ce nouveau super calculateur; c'est la première fois qu'on voit calculateur n'incluant aucun processeurs connu: Intel Xeon, IBM Power ou Sparc. Par contre, tu sembles (en tous cas, c'est mon interprétation) en tirer la conclusion d'une victoire du RISC sur le CISC, et par extention des architectures historiquement RISC (e.g. ARM) sur les architectures historiquement CISC (e.g. x86).
Ça me semble être une erreur parce que la distinction RISC/CISC a de moins en moins de sens. Les processeurs Intel actuels (typiquement labelés CISC) découpent les instructions en micro-opérations (notés µops) élémentaires qu'ils exécutent ensuite. Inversement, les processeurs ARM ont maintenant des instructions qu'on pourrait qualifier de complexes (e.g. instructions SIMD qui opèrent sur des vecteurs). Aujourd'hui, on appelle CISC les jeux d'instructions qui distinguent les opérations mémoires des opérations arithmétiques. Par exemple, les processeurs Intel (CISC) offrent une instruction ADD qui peut prendre une opérande en mémoire. En interne, le processeur exécute une instruction de chargement mémoire, suivie d'une addtion entre deux registrees. Sur un processeur ARM (RISC), il faut d'abord . En fait, de nos jours, la différence entre un processeur CISC et un processeur RISC est assez minime, et surtout n'a que peu d'impact sur la performance du processeur. D'autres facteurs influencent plus la performance comme la taille du pipeline d'exécution, la taille et la configuration des caches, la fréquence, et la répartition des unités de calculs.
J'ai l'impression qu'on peut distinguer trois grandes familles de "processeurs" (je note processeurs entre guillemets car certains "processeurs" commencent à ne plus ressembler beaucoup à l'idée qu'on se fait d'un processeur).
Depuis quelques années, les supercalculateur tirent le gros de leur puissance de calcul soient de processeurs manycore, soit de GPU. Ce type de processeur offre de meilleurs performances que les multicores sur des workload très parallèles, mais moins bonnes sur des workload plus séquentielles. En général, les workload HPC sont bien parallélisables (le en général est quand même à prendre avec des pincettes). Du coup, les manycore ou GPU sont avantagés parce qu'il n'y a pas de silicium "gaché" pour avoir une performance séquentielle élevée (long pipeline, unité redondantes, cache inutilement gros). À ce titre, le Sunway TaihuLight n'est pas si étonnant et entérine juste le fait que les manycore et GPU sont avantageux en HPC. Par contre, c'est quand même la première fois qu'on voit un supercalculateur sans aucun processeur multicore.
La Chine entérine aussi sa supériorité technologique naissante, avec non seulement les deux premiers calculateurs du TOP500, mais aussi avec un processeur de conception maison.
# École post-bac ?
Posté par X345 . En réponse au message Réorientation après une PT. Évalué à 2.
Certaines écoles qui sont normalement "post-bac" prennent des étudiants de prépa en 3ème année pour remplir leurs départements de spécialité. C'est au moins vrai pour certains INSA, tu peux peut-être regarder de ce côté.
[^] # Re: choix de dossier
Posté par X345 . En réponse à la dépêche LibreSSL 2.3.3. Évalué à 10.
Tu es nouveau ici ?
# Trenz Electronic
Posté par X345 . En réponse au message Boutique pour acheter une carte Zybo ?. Évalué à 3.
Y'a quelques années j'avais aussi acheté une carte Digilent (une Nexys 3 à l'époque) chez Trenz Electronic. Je n'avais eu aucun problème particulier, la livraison s'était faite par UPS et s'était bien passée (même si lacher 40€ pour faire venir un truc d'Allemagne, j'avais trouvé ça cher).
[^] # Re: Quelques règles de base pour vos mots de passe
Posté par X345 . En réponse à la dépêche Linux Mint a été compromise. Évalué à 10. Dernière modification le 07 mars 2016 à 18:24.
Non, ton calcul d'entropie est erroné et tu fais la même erreur que Nairwolf.
Dans le calcul de nombre de bits d'entropie pour quatre mots du dictionnaire (5000 mots), je calcule 50004 (49 bits) et non pas: 2624 (112 bits) ce qui correspondrait à 4 mots aléatoires de 6 caractères chacun (ie 24 caractères aléatoires).
Il n'y pas de problème particulier à utiliser des mots du dictionnaire, c'est juste que le dictionnaire est un ensemble de petite taille et donc génère une entropie assez faible. Si vous faites suffisamment (4-5) de tirages dans cet ensemble, l'entropie générée est satisfaisante.
C'est exactement l'idée du XKCD: mieux vaut tirer trois mots aléatoirement du dictionnaire qu'un mot de passe alphabétique lowercase aléatoire de 6 caractères. C'est peut-être contre intuitif parce qu'on nous répète de craindre les attaques par dictionnaire depuis des années. Mais en faisant les calculs d'entropie, on voit que la première alternative est largement supérieure.
Il n'y a pas de différence fondamentale entre une attaque bruteforce et une attaque dite par dictionnaire: dans les deux cas l'attaquant énumère un ensemble de mots de passe possible. La seule chose qui importe est la taille de cet ensemble.
[^] # Re: Quelques règles de base pour vos mots de passe
Posté par X345 . En réponse à la dépêche Linux Mint a été compromise. Évalué à 5.
Tu te trompes, le nombre de bits d'entropie définit complètement la sécurité d'un mot de passe. Si un mot de passe a b bits d'entropie, alors il faut essayer 2b mot de passes pour le deviner, quelque soit le type d'attaque.
La nombre de bits d'entropie d'un mot de passe est le log_2 du nombre de possibilités.
Par exemple, pour 4 mots choisis au hasard dans un dictionnaire de 5000 mots (vocabulaire courant):
entropie = log_2(5000^4) = 49 (bits d'entropie, ie 2^49 possibilités)Note qu'ici, on fait la supposition d'une attaque par dictionnaire: l'attaquant sait que le mot de passe utilisé est composé de 4 mots du dictionnaire.
Pour un mot de passe de 8 caractères (majuscules, minuscules, chiffres = 2*26+10=62 possibilités par caractère):
entropie = log_2(62^8) = 47 (bits d'entropie, ie 2^47 possibilités)Pour un mot de passe de 13 caractères (majuscules, miniscules, chiffres + caractères spéciaux courants = 2*26+10+10 = 72 possibilités par caractère):
entropie = log_2(72^13) = 80 (bits d'entropie, ie 2^80 possibilités)Par définition, chaque bit d'entropie ajouté multiple la durée de l'attaque par deux.
Si le service/site web est correctement configuré (ie pas plus de 1000 essais par seconde, comme dans l'exemple de XKCD), 40-50 bits d'entropie sont largement suffisants. Si la base de données fuite (offline crack) et utilise un hashage faible (par exemple 1 itération de SHA256), alors au minimum 80 bits d'entropie sont nécessaires. Si la base de données fuite et utilise un hashage fort (PBKDF2 avec 10000 itérations), 50-60 bits devraient suffire.
[^] # Re: Mots de passe et imprécisions...
Posté par X345 . En réponse à la dépêche Linux Mint a été compromise. Évalué à 6.
Les schémas que tu proposes ne sont pas recommandés, mais pas très problématiques non plus. La seule propriété utile d'un sel est qu'il ne doit être utilisé qu'une et une seule fois. Avec 64 ou 128 bits aléatoires, tu es sur que jamais deux utilisateurs auront le même sel. Éventuellement en cas de particulière malchance, deux utilisateurs pourraient avoir le même nom civil ET la même date de naissance, et donc le même sel. Ce n'est pas recommandé, mais pas dramatique non plus (du moins de ce que j'en sais, je ne suis pas un expert).
Le plus simple est de sortir 8 ou 16 octets de /dev/urandom (ou autre PRNG équivalent) et de les utiliser directement. Utiliser un uuid4 (random uuid) est également une bonne idée. La principale raison pour laquelle je ne recommanderais pas ce que tu proposes est la première règle de la crypto: "Don't roll your own" (ne faites pas votre propre crypto). Mieux vaut se cantonner à la pratique standard qui consiste à sortir 8 ou 16 octets d'un PRNG.
# Mots de passe et imprécisions...
Posté par X345 . En réponse à la dépêche Linux Mint a été compromise. Évalué à 10. Dernière modification le 07 mars 2016 à 13:55.
Pas mal d'imprécisions dans le paragraphe sur le stockage des mots de passe: confusion entre les hash tables et rainbow tables, méprise sur l'utilité du salt, et pas de mention de l'utilisation des GPU qui sont quand même la méthode à l'état de l'art pour le cassage des mots de passe.
Le problème général avec le stockage des mots de passe est que même si la fonction de hachage h utilisée pour hasher un mot de passe p est robuste, ie il est impossible de déterminer p à partir de h(p), il est (relativement) facile d'énumérer tout les p. En effet l'espace P des mots de passe p est relativement petit: on ne peut pas demander aux utilisateurs de retenir des mots de passe avec 25 caractères aléatoires. En général, on demande 8-15 caractères, ce qui génère un espace petit. Par exemple pour un mot de passe totalement aléatoire de 8 caractères comprenant majuscules, minuscules et chiffres, il y a ~247 possibilités, ce qui est énumérable avec les moyens actuels (une workstation avec un GPU à 1000€ vous permet de casser ça en quelques jours).
Un des premiers moyen utilisés pour accélérer le cassage des mots de passe a été d'utiliser des tables de hash précalculés. L'idée est simple: pour une fonction de hachage h donnée (exemple: h=md5 ou h=sha256), on précalcule h(p) pour tout les mots de passe p de 0-8 caractères. Ensuite, pour un hash h(p) donné, on cherche h(p) dans la table, et on retrouve p. Le problème est que ces tables précalculées ont une taille rédhibitoire: on est déjà à plusieurs téraoctets pour des mots de passe de 5-6 caractères, et la taille augmente exponentiellement avec le nombre de caractères (donc on est à des centaines de teras pour 8 caractères). Les rainbow tables ont été inventées pour résoudre ce problème. Très grossièrement, les rainbow tables permettent d'obtenir les mêmes résultats que les tables de hash précalculés, pour une fraction de l'espace de stockage (dizaines à centaines de gigas). J'ai l'impression que l'auteur confond les rainbow tables, avec les hash tables, une structure de données couramment utilisée qui n'a rien de spécifique à la cryptanalyse. On peut aujourd'hui facilement télécharger des rainbow tables sur internet pour de nombreuses fonctions de hachage (je vous laisse chercher hein…).
Pour se protéger des attaques basées sur les rainbow tables, on utilise un salt ou sel. L'idée est très simple: au lieu de stocker le hash du mot de passe h(p) dans la base de données, on stocke le hash de concaténation du mot de passe p et du sel s : h(s.p). La rainbow table qui stocke les correspondances h(p) -> p n'est donc plus utilisable, il faut recalculer une rainbow table pour chaque sel s. Plusieurs informations érronées dans l'article: les sels ne pas des information secrètes, vous pouvez les stocker dans la base de données, avec les hash. Même si le sel n'est pas secret, et leake avec les hashs, vous êtes protégés contre les attaques basées sur les rainbow tables. La seule contrainte est que le sel doit être de taille suffisante (64-128 bits c'est très bien), et différent pour chaque utilisateur. Il ne faut pas utiliser un sel unique pour toute la base de données, parce qu'à ce moment il devient possible de calculer une rainbow table pour votre base de données. Si le sel est différent pour chaque utilisateur, il faut calculer une rainbow table par utilisateur (ce qui la rend inutile, évidemment). Je le répète: un sel différent pour chaque utilisateur, et stockez-le dans la base de données et vous êtes protégés des rainbow tables.
Bon, malheureusement, les rainbow tables ne sont plus la méthode à l'état de l'art pour le cassage des mots de passe. C'était le cas il y a dix ans, mais depuis on utilise des GPUs. Les GPUs sont très efficaces pour calculer des fonctions de hashage: une machine avec 8 GPU (~8000€) peut calculer plus de 14 milliards de hash SHA256 par seconde (voir Performance hashcat). En d'autres termes, ce genre de machine peut bruteforcer 4 milliards de mot de passes par seconde. En quelques semaines/mois, vous pouvez casser n'importe quel mot de passe de 10 caractères (Speed Hashing). Pour 9 caractères, c'est quelques heures/jours. Et ce même si un sel a été utilisé.
Pour répondre à ce problème, une des techniques utilisés est le key stretching (mais malheureusement seuls peu de systèmes/sites utilisent cette technique). L'idée est simple: au lieu de hasher une seule fois h(s.p), on hashe itérativement un nombre configurable de fois (de l'ordre de quelques dizaines de milliers à quelques centaines de milliers) h(h(h(…h(s.p))). Parmi les algorithmes qui utilisent le key stretching on trouve PBKDF2 et sha512crypt. Par exemple, cryptsetup (utilisé pour le chiffrement disque sous Linux) hashe les mots de passe en utilisant sha256 pendant 2 secondes (sur ma machine, ça fait ~50000 itérations de sha256), GPG hashe les mots de passe en faisant 65536 itérations de SHA1. PAM (sha512crypt) fait 5000 itérations de sha512 (d'ailleurs de nos jours, 5000 itérations de sha512, c'est un peu léger). L'uilisation de PBKDF2 ou sha512crypt est aujourd'hui chaudement recommandée pour atténuer les attaques utilisant des GPUs.
Le problème du key stretching est que les GPUs restent toujours très efficaces pour casser les mot de passe. Même si vous réduisez le nombre d'essais de 4 milliards/s à 100 000/s, ça reste toujours beaucoup, surtout si vos utilisateurs ont des mots de passe "normaux": par exemple 8 caractères alphabétiques lower-case. Il est aussi possible de construire du hardware spécialisé (FPGA, ASIC) pour accélérer encore plus le cassage des mot de passage. Ça se voit avec les ASIC pour miner du bitcoin (qui calcule plein de fois des hash sha256) qui sont capables de calculer des centaines de milliards de sha256 par seconde.
Pour répondre à ce problème, on est en train d'inventer des fonctions de hashage memory-hard: le hash d'un mot de passe doit non seulement être couteux en temps mais aussi utiliser une certaine quantité de mémoire (par exemple 64Mo-1Go. Pour info, pour sha512 ou sha256, on est <1Ko). Ça permet de réduire à néant l'efficacité des GPU et du hardware spécialisé. Pour un GPU avec 16Go, il n'y a que "250 blocks" de 64Mo, ce qui l'empêche de calculer plus de 250 hash par seconde. Même chose pour les ASIC: des grandes quantité de mémoire restent couteuses en espace silicium, et aussi en complexité d'adressage. Ces fonctions de hashage memory-hard restent à l'état de recherche/prototype. En Juin 2015 a eu lieu la Password Hashing Competition dont le but était de sélectionner pour standardisation une fonction de hashage de mot de passe memory-hard. Le gagnant a été argon2 dont le code source est distribué sous CC0.
En résumé :
Si vous êtes administateur ou développeur: utilisez un sel différent pour chaque utilisateur et stocké en base de données. Utilisez sha512crypt ou PBKDF2 1 avec le nombre maximal d'itérations que vous pouvez supporter. Si un délai de 0.5-1s pour une vérification de mot de passe est acceptable, utilisez 100000 itérations. Suivez l'évolution de argon2 (par exemple l'auteur de cryptsetup a annoncé sa volonté de l'utiliser), et implémentez-le lorsqu'il sort de sa phase de beta. Je fais partie de ceux qui pensent que ce n'est pas aux utilisateurs de retenir des mots de passe de 20 caractères aléatoires: c'est au admins de rendre les attaques par bruteforce impraticables.
Si vous êtes utilisateur, et que vous voulez protéger votre mot de passe quoi qu'il arrive (ie même si l'administateur d'un site n'utilise pas de sel ni de key stretching), alors il faut un mot de passe d'au moins 13 caractères aléatoires. Sinon, éviter de partager les mots de passe entre différents service, éventuellement en utilisant un wallet ou keepass (les conseils données dans l'article sont tout à fait valides sur ce domaine).
[1]: Je connais mal bcrypt et scrypt mais ce sont probablement des alternatives correctes. Gardez à l'esprit qu'elles ne sont cependant pas standardisées.
[^] # Re: MD5
Posté par X345 . En réponse au journal Attention si vous avez téléchargé l'ISO Linux Mint 17.3 sur leur site depuis le 20-02 !. Évalué à 6.
Oui, enfin, apparemment, gcc se paye aussi le luxe de signer ses releases avec des clés de DSA 1024 bits.