Yusei a écrit 4649 commentaires

À une époque, j'avais utilisé http://elj.sourceforge.net/ et dans mon souvenir c'était pas mal.

J'ajoute aussi que lorsque le mot de passe est hashé par MD5, je me fiche royalement de trouver le vrai mot de passe, si je trouve un autre mot de passe qui a le même hash, c'est aussi bien. Du point de vue du processus d'identification c'est la même chose, puisqu'il ne connaît que le hash.

Mais de toutes façons, j'ai bien précisé que je cherchais un mot de dix lettres dans un alphabet de 62, et 62^10 est très inférieur aux nombres de hashes possibles de MD5 (2^128), donc la probabilité de trouver deux chaînes valides qui ont le même hash est faible.

1/Modèle propriétaire [...] Finition : Excellente, car le projet est pensé en amont.

Mouais, ça dépend hein. J'ai souvenir d'avoir utilisé un certain nombre de logiciels propriétaires qui affichaient fièrement un numéro de version élevé, et qui n'étaient clairement pas finis. L'exemple le plus énorme était Windows Me, mais il y en a eu pas mal d'autres.

Parmis les inconvénients, du point de vue de la finition, des logiciels propriétaires, je dirais qu'il y a:
- la nécessité de sortir un produit relativement rapidement, pour ne pas investir 10 ans sans rentrée d'argent
- la peur de briser la compatibilité avec les versions antérieures, qui fait qu'on se traîne longtemps les mauvaises décisions de design
- le fait qu'il est plus rentable d'ajouter une fonction qui plaise à 95% des gens que corriger un bug qui touche 0,1% des gens

On dirait que j'ai encore parlé un peu trop vite, apparemment RainbowCrack ne génère pas de tables complètes, mais une forme condensée qui ne garantit pas de trouver le pass, mais qui le permet avec une bonne probabilité. Sur un alphabet de 36 lettres ils s'en sortent avec 36 GB, c'est impressionant.

En dehors des cas les plus simples, il n'est pas tellement envisageable de précalculer une table de hashes. Prenons par exemple un mot de passe alphanumérique (alphabet de 62 caractères) de 8 lettres de long. Il y a 62^8 mots de passes différents. Stocker un élément prend 8 octets pour la chaîne et 16 octets pour le hash. Ce qui nous fait en gros, si je ne me trompe pas dans mes calculs, 4 880 281 Go d'espace pour stocker la table.

Bien sûr, il faut aussi stocker la table pour les mots de passe de 7, 6, 5... caractères.

Si on se limite à un alphabet de 26 caractères, toujours pour des mots de passe d'exactement 8 lettres, il faut 4 668 Go. Ça devient raisonnablement envisageable, mais utiliser un mot de passe sur un alphabet de 26 lettres, c'est chercher les ennuis.

Je précise, bien sûr, qu'ils ne parlent certainement pas de cracker des mots de passe hashés par MD5, puisqu'ils parlent d'Office ou de disques Zip. Mais c'est plus intéressant de regarder combien de temps il faut pour cracker un mot de passe hashé, puisque c'est ce qui est le plus largement utilisé.

Je n'avais rien d'urgent à faire, alors j'ai essayé la même chose sans faire appel à openssl. La différence avec avant, c'est:
- On ne crée plus la structure MD5_CTX à chaque appel
- J'ai inliné une partie des fonctions en espérant que gcc inline les autres
- Je ne remet plus à zéro la structure inutilement "pour des raisons de sécurité".

Toujours à 663 MHz:
Avant: 420 000 mots par seconde
Après: 550 000 mots par seconde

C'est mieux, mais ça reste loin du million de mots par seconde pour le Pentium 100.

Je suis un peu surpris par les chiffres qu'ils donnent. En voilant voir à quelle vitesse un PC un peu récent peut faire ça, j'ai fait un programme tout simple:

- Je suis parti du principe que j'avais un mot de passe haché par MD5, et que je voulais à partir du hash retrouver le mot
- J'ai énuméré des chaînes de 10 caractères dans un alphabet de 62
- J'ai calculé le hash MD5 de ces chaînes (avec OpenSSL)
- J'ai comparé ce hash avec un autre hash, à chaque fois

Sur un Athlon MP à 663 MHz, je peux tester environ 400 000 mots de passe par seconde. En passant le même processeur à 1.66 GHz, je peux en calculer environ 1 100 000. Un million de clés par seconde, c'est ce qu'ils donnent pour un Pentium 100, donc j'ai eu quelques doutes.

Je me suis dit que ma méthode d'énumération était assez bête, mais en fait le truc qui prend du temps, c'est de calculer les hash. Si je ne calcule plus les hash, l'Athlon à 663 MHz "teste" environ 67 millions de mots par seconde. Du coup, j'ai un peu l'impression que dans leurs tests, ils ne font que générer des mots de passe, mais sans les tester (ou alors la fonction de transformation qu'ils utilisent est beaucoup plus rapide à calculer que MD5, ou alors l'implémentation d'OpenSSL est lente).

J'ai bricolé ça rapidement, donc je ne garantis rien, mais si l'ordre de grandeur est bon, on peut raisonnablement considérer que la "classe D" de l'article correspond à ce qu'on peut faire avec un bi-core moderne.

J'ai eu il y a peu de temps une discussion assez animée avec un commercial de l'INRIA à propos de la licence de Lissac. Il n'a toujours pas compris ce qui fait maintenant l'échec ou le succès d'un logiciel.

Peut-être aussi qu'il s'intéresse moins au succès d'un logiciel qu'à sa rentabilité. Il est relativement facile de démontrer que libérer les sources aide au succès, mais il est quand même un peu plus difficile de convaincre que ça puisse rendre une technologie rentable.

En y réfléchissant mieux, ils ne peuvent pas obliger un soft compilé avec leur compilateur à être GPL, mais si le soft incorpore des éléments de leur bibliothèque standard, et qu'elle est sous GPL, ça doit pouvoir se tenir. Il me semble qu'en Eiffel la liaison avec la bibliothèque standard n'est pas dynamique, le code est recopié. Quelqu'un pour confirmer ?

S'ils ont vraiment utilisé la GPL sans modifications, ils ne vont pas tarder à se rendre compte qu'ils se sont trompés, et ne peuvent pas imposer ce genre de restriction... dommage pour eux, et tant mieux pour ceux qui en profiteront.

C'est l'ordre de grandeur qui est important. Ce qui prendrait 200 ans à casser sur un pentium 100 prendra un peu moins de temps sur un bi-Athlon, mais reste raisonnablement sûr. Et puis si tu veux être sûr, il suffit de considérer que la meilleure classe d'attaques est celle courrament utilisée.

Évidemment, 30 secondes après avoir validé j'ai trouvé un lien qui donne un peu plus de détails: http://www.nodezilla.net/evlarchi.html

Le client graphique a l'air libre (d'après sourceforge, c'est du GPL, mais je n'ai pas vérifié), donc je suppose que c'est le « c½ur » qui n'est pas libre... Si c'est le cas, je me demande si on peut vraiment dire que c'est sécurisé. S'il y a bien un domaine où on ne peut pas se passer de donner ses sources, c'est bien la crypto.

Le site donne singulièrement peu de détails, parle de chiffrement et de signatures avec des "algorithmes modernes", mais je n'ai pas vu de noms cités, ni d'algorithmes, ni rien qui puisse permettre de se convaincre que c'est vraiment "secure". Et même si les algorithmes étaient décrits, il faudrait encore faire confiance au développeur. Pour l'instant, je suis tenté de préférer Freenet si je cherche quelque chose de sûr, bien que Freenet ne prétende pas être sûr à 100%.

Mais... pourquoi c'est drôle ?

('cule un mouton, oui, je sais)

Un petit problème assez pénible: si on va sur ton site, qu'on affiche une image et qu'on clique sur le bouton "Back" du navigateur, on retombe sur le journal.

C'est dû au fait qu'au lieu d'afficher l'image dans une nouvelle page, comme on a l'impression que cela se passe, tu utilises du Javascript pour modifier la page. Du coup, aucune entrée n'est ajoutée à l'historique.

Si tu as aimé "le Maître du Haut Château", tu aimeras probablement "La Séparation" de Christopher Priest, dans lequel un historien essaye de retracer l'histoire deux jumeaux pendant la guerre, et de comprendre pourquoi certains documents d'archive prétendent que la guerre se serait poursuivie jusqu'en 1945.

Caml a un bon succes ...pour un langage fonctionel, je ne pense pas qu'on puisse attendre beaucoup plus.

Mais OCaml est un langage qui permet de code à la fois en fonctionnel, en impératif et en objet (tout comme Common Lisp, d'ailleurs).

+ est un opérateur qui doit s'appliquer aux entiers, comme aux flottants

Tu pas du principe que la surcharge d'opérateurs est quelque chose qui va de soi, malgré le fait que l'opération "addition" est très différente selon le type des données. La surcharge d'opérateur, c'est du sucre syntaxique pour faire plaisir au développeur, rien de plus.

OCaml a fait le choix de renoncer à ce sucre syntaxique pour proposer autre chose qui fait plaisir au programmeur: l'inférence de type. L'inférence de type permet de supprimer la plupart des erreurs de typage à la compilation, donc c'est quelque chose qui apporte un bénéfice évident.

Or toi, au lieu de reconnaître que c'est un choix, avec lequel tu peux être d'accord ou non, tu prétends que c'est de l'incompétence. Il y a des moments où on préfère que son code soit garanti valide, et il y a des moments où on préfère que son code soit facile à écrire. En particulier, il y a des moments où on voudrait se rendre compte à la compilation que l'opérateur "+" n'existe pas pour l'objet manipulé, et pas à l'exécution quand l'exception est levée.

Quand un codeur choisit un langage pour son prochain programme, généralement, il choisit un poil plus en connaissance de cause.

C'est comme pour tout, il y a une minorité de gens qui maîtrisent plusieurs langages et qui sont capables de choisir le plus adapté à la tâche à effectuer, et puis il y a les autres, qui ont appris un ou deux langages et qui partent du principe que c'est la panacée.

"Malheureusement, ça arrive. Mais il faut rester impartial, et condamner chacun de ces débordements. De telles choses ne devrait jamais arriver."

Et je rajouterais, à titre personnel, que je regrette de me dire que ces débordements sont peut-être la seule chose qui va faire réagir le gouvernement et l'inciter à négocier un texte qui déplait tant. Je me sens un peu hypocrite de les condamner "moralement", tout en les trouvant bien pratiques, finalement.

C'est un peu caricaturale comme exemple.

Mon but étant de donner un exemple où une mesure favorisant l'emploi n'est pas forcément souhaitable, ça ne m'a pas semblé dérangeant d'en donner un qui soit un peu extrême. Si tu remplaces "supprimer le SMIC" par "réduire le SMIC de 20%", ça devient tristement réaliste.

Si on supprime l'assurance chomage, ça va booster les jeunes à trouver du boulot

Ce n'est pas pareil. S'il n'y a pas d'emplois disponibles, tu peux motiver les jeunes autant que tu veux à en chercher, ils n'en trouveront pas. Baisser le SMIC ou flexibiliser l'emploi sont deux mesures qui visent à inciter les employeurs à embaucher plus.

Faut savoir faire des compromis.

C'est l'avenir qui nous dira si ce compromis là est acceptable. Pour l'instant, le gouvernement donne l'impression de penser que les compromis peuvent être faits sans consulter l'autre partie.

Si ce contrat peut aider les jeunes à trouver du boulot, à aider les employeurs frileux de franchir le pas, on ne peut pas s'y opposer.

Si, on peut, enfin j'espère. Prenons un autre exemple: beaucoup s'accordent pour dire qu'imposer un salaire minimum produit du chômage. En admettant cette hypothèse, on pourrait dire que supprimer le smic peut aider les jeunes à trouver du boulot, et aider les employeurs frileux à franchir le pas. J'espère quand même que beaucoup trouveraient des raisons pour s'y opposer, arguant qu'un salaire minimum garantit un certain niveau de vie.

Pour le CPE c'est le même principe, pas au niveau du salaire mais de la flexibilité des emplois. Même en admettant que ça crée des emplois, c'est encore à nous, en tant que société, de décider si ce genre d'emplois (précaires ou flexibles, selon le point de vue) est acceptable.

Ce qui est condamnable dans le CPE est les mauvaises utilisations qui peuvent en être faite.

En principe, le droit du travail, et plus généralement la loi, est là pour protéger contre les abus, pas contre les gens sympas. Quand la loi permet des "mauvaises utilisations", c'est qu'elle ne joue pas son rôle. Or, l'argumentation de beaucoup des patrons qui défendent le CPE c'est « on est gentils, on n'a pas envie de virer les gens ». C'est prendre le problème à l'envers.

le gouvernement en place a été élu démocratiquement. [...] je ne défend pas le gouvernement pour lequel je n'ai pas trop de sympatie, je défend seulement sa légitimité

Néanmoins, ce n'est pas parce qu'on est dans une démocratie représentative qu'on peut se foutre de la gueule du monde une fois qu'on est élu. Ils ont été élus pour représenter le peuple, alors quand les sondages (résultats sur une chaîne publique, pas dans des tracts de militants) donnent plus de 70% d'opposants à quelque chose, le minimum est d'accepter l'éventualité d'une remise en question. Le gouvernement actuel ne donne pas cette impression.

Comme tu le dis, un référendum permettrait de s'assurer de l'opinion des français plus sûrement qu'un sondage, mais typiquement ce sont les sondages qui devraient donner l'idée au gouvernement de faire un référendum. Le feront-ils ? S'ils ne le font pas, c'est qu'ils refusent de vérifier qu'ils représentent toujours leurs électeurs.

Question perfs...je sais pas si c'est moi mais la navigation a l'air plus fluide que sous la version 1.5.

Sur ma machine toute lente, c'est beaucoup mieux qu'avant, tant au niveau du scrolling (qui était très saccadé sur les versions post 1.5) qu'au niveau de l'ouverture des onglets.

Pourvu que ça continue dans cette voie...