Sur les Google captcha, je ne sais jamais s'il faut cliquer sur la case qui a une poignée de moto ou un bout de passage piétons. Je n'arrive jamais à les passer du premier coup, ça m'énerve.
Mention spéciale à MonPeupleDoc (à traduire en anglais), site choisi par ma société pour déposer les bulletins de salaire, qui met le captcha après avoir validé le mot de passe …
Je vais sûrement dire une bêtise mais pour définir un produit vectoriel qui tient la route il ne faut pas présupposer, à la base d'un référentiel pré-existant ? Le produit vectoriel se définit intrinsèquement ?
Dans un espace vectoriel quelconque, tu dois d'abord définir une orientation pour définir un produit vectoriel. Par contre, tu n'as pas besoin d'avoir défini une base au préalable : une fois l'orientation définie, le produit vectoriel est le même quelque soit la base.
Poussons le pinaillage, c'est le jeu ici : il te faut 4 points pour définir un référentiel. Or, tu es mou et la distance entre ces quatre points n'est jamais la même !
C'est vrai, tu as raison. La distance entre les points importe peu, mais le fait qu'ils peuvent bouger avec des rotations peut tout fausser.
Si tu es immobile par rapport à toi même ça a l'air difficile de base de se déplacer avec la gravité ambiante, il te faut un véhicule roulant a proximité très proche dans tout référentiel raisonnable.
« Quel est le référentiel d’étude ? ». Et surtout, « Pourquoi avoir choisi celui-là et pas un autre ? ».
Je vais prendre le référentiel le plus naturel qui soit : moi. Et dans ce référentiel, les ordinateurs à bord des sondes voyager décrivent grosso modo tous les jours un cercle de rayon 23 milliards de km. Soit une petite vitesse moyenne de 6 milliards de km/h.
« incertaine » me semble un doux euphémisme (les euphémismes sont toujours doux, c’est comme ça, la liaison adoucit la phonation, faites le test vous entendrez).
De toute façon, c'est pas non plus comme si leurs objectifs étaient à la mesure de l'enjeu. C'est en grande partie du greenwashing avec toujours les mêmes rengaines :
On utilise de l'énergie verte -> la magie de l'énergie renouvellable produite en été qu'on consomme en hiver
On va investir dans des puits carbone -> comme on est les plus riches, on peut s'approprier ces ressources négatives en carbone. Il n'y en a plus pour les autres ? Tant pis pour eux. Sans compter que dans le lot, il y a toujours les mêmes niches de reforestation (ha une partie de ces arbres ne va pas survivre à cause du réchauffement climatique ? Désolé, on a essayé)
Pour le reste, on est sûr que la techno va s'améliorer et on en profitera donc en temps et en heure.
Ha et évidemment, si à un moment on trouve que c'est plus rentable de faire semblant, ne vous inquiétez pas, on va arrêter tout de suite.
Combien de temps pourrait tenir les réserves si l'intégralité de l'electricité mondiale était produite avec du nucléaire ?
Ce site fait un calcul basé :
- sur les réserves identifiées en 2019 et accessibles à un prix raisonnable
- la consommation annuelle de 2014
Il y aurait de quoi tenir 100 ans. La France de son côté, détiendrait tenir 6-7 ans sans approvisionnement (source à prendre avec des pincettes).
Après il faut tenir compte d'une part d'une augmentation de la consommation et d'autre part le fait que les ressources comptées plus haut ne tiennent compte que de celles à prix raisonnables. Dès que le prix de l'énergie augmente, mathématiquement les réserves augmentent aussi. Il faut rajouter à ça que le décompte ne prend en compte que l'énergie produite par l'utilisation directe de l'uranium, alors qu'on sait aujourd'hui extraire du plutonium des déchets et l'utiliser pour produire à nouveau de l'énergie.
Bref, la réponse exacte n'est pas évidente, mais tu as un ordre de grandeur d'une borne minimum.
L'uranium est un des minerais les plus présents dans le monde.
En quantité, oui il y en a beaucoup (plus que de l'or ou d'argent). Mais il est loin d'être dans le haut du classement
Par ailleurs, il faut prendre en compte que ce qui est important ce n'est pas la quantité d'uranium naturel, mais la quantité d'uranium 235, qui représente 0.007% de l'uranium naturel.
Ceci dit même avec ça, c'est vrai qu'il y en a largement suffisamment. Mais c'est pas parce qu'il y en a assez que c'est une bonne idée d'en utiliser pour tout et n'importe quoi.
Et sinon il y a le Plutonium qui est encore plus présent
Le plutonium n'existe pas à l'état naturel, il est créé à partir d'uranium. Donc le jour où il sera encore plus présent, c'est qu'on aura consommé la majeure partie de l'uranium présent.
Si je comprends bien, tu cherches à te proposer d'un attaquant qui arriverait à accéder à la RAM d'un smartphone à jour, verrouillé à partir du port USB en moins de 18h. Donc concrètement un attaquant qui a en sa possession un exploit 0-Day.
Un attaquant qui serait assez motivé aussi pour réparer/changer des pièces dans le même délai si besoin.
Et pour ça, tu demandes sur un forum publique comment faire.
Je pense qu'il y a un sacré fossé entre les moyens que tu prêtes à ton attaquant et les moyens que tu te donnes de te défendre. Si c'est juste pour le challenge comme évoqué plus haut, très bien. Si c'est pour répondre à un vrai besoin, tu as plus de chance d'arriver à un sentiment de sécurité qu'à une vraie réponse.
Une faille permettant un accès à un Android à partir d'un accès physique, ça doit tourner aux alentours d'1 million d'euros. Donc tu cherches à te protéger d'un organisme qui est prêt à mettre 1 million d'euros pour obtenir tes secrets. Tous tes correspondants et toi-même êtes bien entourés de gardes du corps jour et nuit ?
Par ailleurs, partir de chez Gandi se fait pour différentes raisons ; le prix en est une mais il y a d'autres critères qui reviennent.
Je suis passé de Gandi vers Galae, mais on va dire que le prix est une raison indirecte. C'est surtout l'approche foutage de gueule qui m'a incité à partir et à aller voir ailleurs. Si ça avait été annoncé plus longtemps à l'avance, que ça n'impactait pas les noms de domaine renouvelés récemment, je serais sûrement resté.
J'arrive un peu un retard, mais si tu n'es pas encore sûr de tes usages/besoins, tu peux envisager la location dans un premier temps.
Si tu habites en IDF, la région a une offre limitée dans le temps mais intéressante : https://www.iledefrance-mobilites.fr/le-reseau/services-de-mobilite/velo/veligo-location. C'est en passant par eux que j'ai testé mon premier cargo, et ça m'a permis de me faire une idée de ce que j'aimais ou j'aimais pas.
Si tu compares par rapport à un dual boot c'est :
* 1 fonctionnalité qui ne marche qu'avec une version spécifique de Windows et un linux allégé (et probablement un matériel spécifique)
* Les 2 OS ne tournent pas en même temps, mais doivent quand même se partager la mémoire
* Les documents utilisateurs sont dupliqués
* Ce n'est plus possible de passer en veille
Le seul avantage, c'est que la bascule d'un OS à l'autre est peut-être plus rapide (et encore dans l'article, l'auteur mentionne que c'est pas super rapide quand même).
Bref, de très jolis hacks mais un apport très faible pour des inconvénients conséquents.
Il va falloir que je relise ça à tête reposée. Mais en (très) gros, ça consiste à bidouiller l'ACPI pour intercepter la veille de l'un afin de réveiller l'autre. On saupoudre de grub caché pour isoler les partitions afin que les OS ne se voient pas et on obtient une machine au complètement étrange, qui ressemble à un hyperviseur faisant tourner 2 OS (mais pas en même temps).
En admettant qu'un dé qui rebondit soit un système chaotique, ça n'implique pas qu'un lancer de dé soit nécessairement imprédictible ou non reproductible. Avec des conditions initiales suffisamment bien contrôlées, l'imprédictibilité apparaît peut-être au bout d'1 millions de rebonds et ça voudrait dire qu'en première approximation un lancer de dé (quelques dizaines de rebonds grand maximum) n'est pas chaotique.
Note: je n'affirme pas du tout qu'il faut un million de rebonds, je n'en ai aucune idée. Peut-être que 3 rebonds suffisent. Je dis juste qu'il ne suffit pas de brandir la théorie du chaos pour écarter l'hypothèse de Faya.
Vu la conséquence j'aurais du mal à dire que c'est du bonus.
Dans le pire des cas il est prédictible et ça ne change rien.
L'histoire lui a donné tord. Surtout qu'il me semble qu'il existait à minima des patch pour qu'une page donnée par l'OS soit mise à 0.
Attention, le bug n'a pas été causé par ce bonus. Si l'OS ou n'importe quoi d'autre avait juste mis le contenu de ce buffer à 0, ça n'aurait eu aucune conséquence notable dans la plupart des situations, juste le bonus aurait disparu.
Le bug a été causé par quelqu'un qui a voulu corriger le code en se disant que l'intérêt du bonus est faible par rapport au fait que ça lève des warnings. Et il y a eu une erreur dans la correction. Je ne me souviens plus des détails mais je crois qu'au lieu de mettre le buffer à 0 avant sa première utilisation, il a été mis à 0 après qu'il ait été rempli avec la vraie source d'entropie. Ce qui a rendu facilement prédictible tous les nombres aléatoires générés.
OpenSSL avait besoin d'entropie pour initialiser son générateur de nombres aléatoires. Il se basait évidemment sur des sources réputées sures (notamment /dev/random si disponible). La fonction qui ajoutait l'entropie avait besoin d'utiliser un buffer. Le raisonnement de l'auteur de l'époque c'était "Pourquoi s'embêter à le mettre à zéro avant de l'utiliser ?". Dans le pire des cas il est prédictible et ça ne change rien. Dans le meilleur des cas, ça rajoute encore un peu d'entropie à moindre coût (à coût négatif même puisque ça évite une opération).
Le souci de ce raisonnement c'est que le résultat faisait crier les analyseurs de code. Du coup, il y a eu tentative de correction, mais celle-ci a introduit un bug. La conséquence de celui-ci a fait que plus aucune source d'entropie n'était utilisée, sauf la toute première (le PID du process en cours, donc très peu d'entropie).
Moi j'aimerais bien avoir une explication technique, comment est-il possible d'ignorer une année bissextile ?
Je n'ai aucune statistique, mais je pense qu'une grosse part des bugs sont des cas stupides qui ont été ignorés pour aller plus vite ou parce que pas pertinent à une époque puis ça l'est devenu, ou parce que cachés au fond d'une complexité de code.
Ceux qui concernent les années bissextiles sont plus exposés médiatiquement mais au final ça reste des bugs comme des millions d'autres qui ont lieu tous les jours mais qui sont moins accessibles au grand public.
j’avoue ne pas comprendre d’où viennent les chiffres de 228 (dans le premier cas) et 244 (dans le second).
Ce n'est pas évident mais c'est plus ou moins expliqué dans la 1ère bulle. Chaque petit carré correspond à un bit. Et la position du carré donne une indication d'où ça vient.
Pour le premier cas :
- L'utilisateur choisit un mot peu commun => 16 bits. Ici Randall suppose donc une liste de 65536 mots dans laquelle on choisit.
- L'utilisateur choisit de mettre la 1ère lettre en majuscule ou non => 1 bit
- Pour chaque lettre où c'est faisable, l'utilisateur choisit d'écrire en leet ou pas => 3 bits (le calcul est un peu simpliste ici car les 3 bits dépendent en fait du mot initial)
- L'utilisateur rajoute un caractère spécial => 4 bits (donc dans une liste de 16 caractères)
- L'utilisateur rajoute un chiffre => 3 bits (c'est un peu plus, mais c'est arrondi)
- L'utilisateur peut choisir d'inverser le caractère spécial et le chiffre => 1 bit
Au total, on retrouve bien les 28 bits module quelques approximations.
Dans le deuxième cas :
- L'utilisateur choisit un mot commun => 11 bits. Ici Randall suppose cette fois une liste plus réduite de 2048 mots
- Il répète 4 fois => 44 bits
Un point important des 2 méthodes, c'est que les choix doivent tous être des choix au hasard (donc pas l'utilisateur qui sort de sa tête un mot). Sinon, l'entropie diminue fortement.
En tous cas une chose est sûre, me semble-t-il, c’est que dans les deux cas l’entropie est plus faible qu’un mot de passe de la même longueur utilisant le même ensemble de caractères et qui serait vraiment aléatoire
Oui complètement. On parle souvent pour simplifier de l'entropie d'un mot de passe, mais en vrai on devrait parler de l'entropie d'une méthode de génération de mot de passe. Je ne rentre pas dans les détails, car il faudrait un journal pour ça, mais l'idée c'est de la mesurer dans le pire des cas, en supposant que l'attaquant connaisse parfaitement la méthode de génération et les biais de l'humain qui l'utilise. Ça permet d'avoir une idée de la robustesse d'une méthode qu'on communique massivement pour être appliquée par un grand monde.
Et du coup, si ta méthode c'est de générer un mot de passe de la même longueur qu'un des précédents, oui ton entropie va être beaucoup plus importante, même si théoriquement tu pourrais retomber sur les même mots de passe.
On devrait peut-être enseigner les méthodes de choix d’un mot de passe vers le CE2-CM1.
Il faudrait surtout enseigner qu'un mot de passe, même très robuste, ce n'est pas la panacée, et que le minimum pour protéger un service non trivial c'est du MFA.
Le 44 bit d’entropie est évidemment à relativiser si l’attaquant sais que cette méthode est utilisée
L'entropie est de 44 bits si l'attaquant sait que cette méthode est utilisée, qu'il connaît la liste de mots initiale et le nombre de mots choisis.
Ce qui est discutable, c'est si 44 bits suffisent ou pas. Mais cet algorithme s'adapte bien, il suffit de prendre une plus grande liste de mots et/ou plus de mots pour augmenter l'entropie jusqu'à la valeur désirée.
# Tous les sites utilisant Google Captcha
Posté par NicolasP . En réponse au journal La Macsf assure, mais pas leurs développeurs web. Évalué à 10 (+10/-0).
Sur les Google captcha, je ne sais jamais s'il faut cliquer sur la case qui a une poignée de moto ou un bout de passage piétons. Je n'arrive jamais à les passer du premier coup, ça m'énerve.
Mention spéciale à MonPeupleDoc (à traduire en anglais), site choisi par ma société pour déposer les bulletins de salaire, qui met le captcha après avoir validé le mot de passe …
[^] # Re: Chaud devant !
Posté par NicolasP . En réponse au lien L'ordinateur le plus rapide du monde : Parker Solar Probe. Évalué à 2 (+1/-0).
Dans un espace vectoriel quelconque, tu dois d'abord définir une orientation pour définir un produit vectoriel. Par contre, tu n'as pas besoin d'avoir défini une base au préalable : une fois l'orientation définie, le produit vectoriel est le même quelque soit la base.
[^] # Re: Chaud devant !
Posté par NicolasP . En réponse au lien L'ordinateur le plus rapide du monde : Parker Solar Probe. Évalué à 2 (+1/-0).
C'est vrai, tu as raison. La distance entre les points importe peu, mais le fait qu'ils peuvent bouger avec des rotations peut tout fausser.
Par contre là j'ai pas compris.
[^] # Re: Chaud devant !
Posté par NicolasP . En réponse au lien L'ordinateur le plus rapide du monde : Parker Solar Probe. Évalué à 4 (+3/-0).
Les axes n'ont pas beaucoup d'importance tant qu'ils sont fixes par rapport à moi, mais oui c'est l'idée.
Tu veux dire que quand un manège arrive sous moi, ça va plus vite :).
[^] # Re: Chaud devant !
Posté par NicolasP . En réponse au lien L'ordinateur le plus rapide du monde : Parker Solar Probe. Évalué à 2 (+1/-0). Dernière modification le 03 janvier 2025 à 12:13.
Ben non, dans mon référentiel, je suis immobile, par définition.
[^] # Re: Chaud devant !
Posté par NicolasP . En réponse au lien L'ordinateur le plus rapide du monde : Parker Solar Probe. Évalué à 2 (+1/-0).
Je vais prendre le référentiel le plus naturel qui soit : moi. Et dans ce référentiel, les ordinateurs à bord des sondes voyager décrivent grosso modo tous les jours un cercle de rayon 23 milliards de km. Soit une petite vitesse moyenne de 6 milliards de km/h.
[^] # Re: Quelques propriétés mathématiques de 2025
Posté par NicolasP . En réponse au journal Vœux mathématiquement douteux mais. Évalué à 2 (+1/-0).
Si ça t'intéresse, Choux romanesco, … publie tous les ans une analyse des propriétés de l'année.
[^] # Re: cool
Posté par NicolasP . En réponse au journal Meta persiste à chercher du nucléaire pour ses datacenters IA.. Évalué à 2.
De toute façon, c'est pas non plus comme si leurs objectifs étaient à la mesure de l'enjeu. C'est en grande partie du greenwashing avec toujours les mêmes rengaines :
[^] # Re: cool
Posté par NicolasP . En réponse au journal Meta persiste à chercher du nucléaire pour ses datacenters IA.. Évalué à 7.
Ce site fait un calcul basé :
- sur les réserves identifiées en 2019 et accessibles à un prix raisonnable
- la consommation annuelle de 2014
Il y aurait de quoi tenir 100 ans. La France de son côté, détiendrait tenir 6-7 ans sans approvisionnement (source à prendre avec des pincettes).
Après il faut tenir compte d'une part d'une augmentation de la consommation et d'autre part le fait que les ressources comptées plus haut ne tiennent compte que de celles à prix raisonnables. Dès que le prix de l'énergie augmente, mathématiquement les réserves augmentent aussi. Il faut rajouter à ça que le décompte ne prend en compte que l'énergie produite par l'utilisation directe de l'uranium, alors qu'on sait aujourd'hui extraire du plutonium des déchets et l'utiliser pour produire à nouveau de l'énergie.
Bref, la réponse exacte n'est pas évidente, mais tu as un ordre de grandeur d'une borne minimum.
[^] # Re: cool
Posté par NicolasP . En réponse au journal Meta persiste à chercher du nucléaire pour ses datacenters IA.. Évalué à 6.
En quantité, oui il y en a beaucoup (plus que de l'or ou d'argent). Mais il est loin d'être dans le haut du classement
Par ailleurs, il faut prendre en compte que ce qui est important ce n'est pas la quantité d'uranium naturel, mais la quantité d'uranium 235, qui représente 0.007% de l'uranium naturel.
Ceci dit même avec ça, c'est vrai qu'il y en a largement suffisamment. Mais c'est pas parce qu'il y en a assez que c'est une bonne idée d'en utiliser pour tout et n'importe quoi.
Le plutonium n'existe pas à l'état naturel, il est créé à partir d'uranium. Donc le jour où il sera encore plus présent, c'est qu'on aura consommé la majeure partie de l'uranium présent.
# Adresse perso dans un contexte prp
Posté par NicolasP . En réponse au message Utilisation forcée d'une adresse personnelle dans le cadre pro. Évalué à 7.
Oui.
Tu n'as pas à en fournir. C'est à ton employeur de justifier qu'il a une base légale pour te forcer à faire quoi que ce soit.
# Modèle de menace ?
Posté par NicolasP . En réponse au journal Sécurisation du port USB-C sur smartphone pour moules barbares. Évalué à 4.
Si je comprends bien, tu cherches à te proposer d'un attaquant qui arriverait à accéder à la RAM d'un smartphone à jour, verrouillé à partir du port USB en moins de 18h. Donc concrètement un attaquant qui a en sa possession un exploit 0-Day.
Un attaquant qui serait assez motivé aussi pour réparer/changer des pièces dans le même délai si besoin.
Et pour ça, tu demandes sur un forum publique comment faire.
Je pense qu'il y a un sacré fossé entre les moyens que tu prêtes à ton attaquant et les moyens que tu te donnes de te défendre. Si c'est juste pour le challenge comme évoqué plus haut, très bien. Si c'est pour répondre à un vrai besoin, tu as plus de chance d'arriver à un sentiment de sécurité qu'à une vraie réponse.
Une faille permettant un accès à un Android à partir d'un accès physique, ça doit tourner aux alentours d'1 million d'euros. Donc tu cherches à te protéger d'un organisme qui est prêt à mettre 1 million d'euros pour obtenir tes secrets. Tous tes correspondants et toi-même êtes bien entourés de gardes du corps jour et nuit ?
[^] # Re: 99%
Posté par NicolasP . En réponse au message Question aux gestionnaires d'emails qui auraient migré dans les 12 à 18 derniers mois. Évalué à 2.
Je suis passé de Gandi vers Galae, mais on va dire que le prix est une raison indirecte. C'est surtout l'approche foutage de gueule qui m'a incité à partir et à aller voir ailleurs. Si ça avait été annoncé plus longtemps à l'avance, que ça n'impactait pas les noms de domaine renouvelés récemment, je serais sûrement resté.
[^] # Re: Constante de Weiner
Posté par NicolasP . En réponse à la dépêche Y a le Frido 2024 qu'est là. Évalué à 1.
Le rapport entre le logarithme de l'aire d'un carré et le logarithme de son côté
le seul nombre oblong premier
La moyenne géométrique de la suite A007395 tends vers la constante de Weiner (la démonstration est assez ardue).
# Les explications et interrogations du projet Tor
Posté par NicolasP . En réponse au lien Les autorités allemandes ont-elles réussi à compromettre l’anonymat sur Tor ? . Évalué à 7. Dernière modification le 20 septembre 2024 à 20:05.
https://blog.torproject.org/tor-is-still-safe/
# Location ?
Posté par NicolasP . En réponse au message Des e-cyclistes dans le coin ?. Évalué à 1.
J'arrive un peu un retard, mais si tu n'es pas encore sûr de tes usages/besoins, tu peux envisager la location dans un premier temps.
Si tu habites en IDF, la région a une offre limitée dans le temps mais intéressante : https://www.iledefrance-mobilites.fr/le-reseau/services-de-mobilite/velo/veligo-location. C'est en passant par eux que j'ai testé mon premier cargo, et ça m'a permis de me faire une idée de ce que j'aimais ou j'aimais pas.
[^] # Re: Complètement inutile mais très astucieux
Posté par NicolasP . En réponse au lien Passer de Windows à Linux et inversement, sans virtualisation. Évalué à 6.
Si tu compares par rapport à un dual boot c'est :
* 1 fonctionnalité qui ne marche qu'avec une version spécifique de Windows et un linux allégé (et probablement un matériel spécifique)
* Les 2 OS ne tournent pas en même temps, mais doivent quand même se partager la mémoire
* Les documents utilisateurs sont dupliqués
* Ce n'est plus possible de passer en veille
Le seul avantage, c'est que la bascule d'un OS à l'autre est peut-être plus rapide (et encore dans l'article, l'auteur mentionne que c'est pas super rapide quand même).
Bref, de très jolis hacks mais un apport très faible pour des inconvénients conséquents.
# Complètement inutile mais très astucieux
Posté par NicolasP . En réponse au lien Passer de Windows à Linux et inversement, sans virtualisation. Évalué à 5.
Il va falloir que je relise ça à tête reposée. Mais en (très) gros, ça consiste à bidouiller l'ACPI pour intercepter la veille de l'un afin de réveiller l'autre. On saupoudre de grub caché pour isoler les partitions afin que les OS ne se voient pas et on obtient une machine au complètement étrange, qui ressemble à un hyperviseur faisant tourner 2 OS (mais pas en même temps).
[^] # Re: Objection votre Honneur
Posté par NicolasP . En réponse au journal L’IA permet-elle de voir ou entendre le futur proche ? et notre cerveaux, le peut-il ?. Évalué à 4.
En admettant qu'un dé qui rebondit soit un système chaotique, ça n'implique pas qu'un lancer de dé soit nécessairement imprédictible ou non reproductible. Avec des conditions initiales suffisamment bien contrôlées, l'imprédictibilité apparaît peut-être au bout d'1 millions de rebonds et ça voudrait dire qu'en première approximation un lancer de dé (quelques dizaines de rebonds grand maximum) n'est pas chaotique.
Note: je n'affirme pas du tout qu'il faut un million de rebonds, je n'en ai aucune idée. Peut-être que 3 rebonds suffisent. Je dis juste qu'il ne suffit pas de brandir la théorie du chaos pour écarter l'hypothèse de Faya.
[^] # Re: Résumé
Posté par NicolasP . En réponse au lien 16 ans de CVE-2008-0166 (bug OpenSSL Debian) : casser DKIM et BIMI en 2024. Évalué à 3. Dernière modification le 14 mai 2024 à 21:49.
Attention, le bug n'a pas été causé par ce bonus. Si l'OS ou n'importe quoi d'autre avait juste mis le contenu de ce buffer à 0, ça n'aurait eu aucune conséquence notable dans la plupart des situations, juste le bonus aurait disparu.
Le bug a été causé par quelqu'un qui a voulu corriger le code en se disant que l'intérêt du bonus est faible par rapport au fait que ça lève des warnings. Et il y a eu une erreur dans la correction. Je ne me souviens plus des détails mais je crois qu'au lieu de mettre le buffer à 0 avant sa première utilisation, il a été mis à 0 après qu'il ait été rempli avec la vraie source d'entropie. Ce qui a rendu facilement prédictible tous les nombres aléatoires générés.
[^] # Re: Résumé
Posté par NicolasP . En réponse au lien 16 ans de CVE-2008-0166 (bug OpenSSL Debian) : casser DKIM et BIMI en 2024. Évalué à 3. Dernière modification le 14 mai 2024 à 21:08.
De mémoire c'était juste du bonus.
OpenSSL avait besoin d'entropie pour initialiser son générateur de nombres aléatoires. Il se basait évidemment sur des sources réputées sures (notamment /dev/random si disponible). La fonction qui ajoutait l'entropie avait besoin d'utiliser un buffer. Le raisonnement de l'auteur de l'époque c'était "Pourquoi s'embêter à le mettre à zéro avant de l'utiliser ?". Dans le pire des cas il est prédictible et ça ne change rien. Dans le meilleur des cas, ça rajoute encore un peu d'entropie à moindre coût (à coût négatif même puisque ça évite une opération).
Le souci de ce raisonnement c'est que le résultat faisait crier les analyseurs de code. Du coup, il y a eu tentative de correction, mais celle-ci a introduit un bug. La conséquence de celui-ci a fait que plus aucune source d'entropie n'était utilisée, sauf la toute première (le PID du process en cours, donc très peu d'entropie).
[^] # Re: hostname
Posté par NicolasP . En réponse au journal [Message de service] Changement d'adresse IP publique pour le site LinuxFr.org. Évalué à 10.
C'est vraiment dommage qu'on fasse tous la même opération. Il faudrait inventer un système où ça se propage automatiquement.
[^] # Re: Comment est-ce possible ?
Posté par NicolasP . En réponse au lien Un 29 février ? C'est quoi ça ? C'est nouveau ?. Évalué à 5.
Je n'ai aucune statistique, mais je pense qu'une grosse part des bugs sont des cas stupides qui ont été ignorés pour aller plus vite ou parce que pas pertinent à une époque puis ça l'est devenu, ou parce que cachés au fond d'une complexité de code.
Ceux qui concernent les années bissextiles sont plus exposés médiatiquement mais au final ça reste des bugs comme des millions d'autres qui ont lieu tous les jours mais qui sont moins accessibles au grand public.
[^] # Re: Caractère spécial
Posté par NicolasP . En réponse au journal Mon gestionnaire de mots de passe, en 50 lignes de HTML. Évalué à 3.
Ce n'est pas évident mais c'est plus ou moins expliqué dans la 1ère bulle. Chaque petit carré correspond à un bit. Et la position du carré donne une indication d'où ça vient.
Pour le premier cas :
- L'utilisateur choisit un mot peu commun => 16 bits. Ici Randall suppose donc une liste de 65536 mots dans laquelle on choisit.
- L'utilisateur choisit de mettre la 1ère lettre en majuscule ou non => 1 bit
- Pour chaque lettre où c'est faisable, l'utilisateur choisit d'écrire en leet ou pas => 3 bits (le calcul est un peu simpliste ici car les 3 bits dépendent en fait du mot initial)
- L'utilisateur rajoute un caractère spécial => 4 bits (donc dans une liste de 16 caractères)
- L'utilisateur rajoute un chiffre => 3 bits (c'est un peu plus, mais c'est arrondi)
- L'utilisateur peut choisir d'inverser le caractère spécial et le chiffre => 1 bit
Au total, on retrouve bien les 28 bits module quelques approximations.
Dans le deuxième cas :
- L'utilisateur choisit un mot commun => 11 bits. Ici Randall suppose cette fois une liste plus réduite de 2048 mots
- Il répète 4 fois => 44 bits
Un point important des 2 méthodes, c'est que les choix doivent tous être des choix au hasard (donc pas l'utilisateur qui sort de sa tête un mot). Sinon, l'entropie diminue fortement.
Oui complètement. On parle souvent pour simplifier de l'entropie d'un mot de passe, mais en vrai on devrait parler de l'entropie d'une méthode de génération de mot de passe. Je ne rentre pas dans les détails, car il faudrait un journal pour ça, mais l'idée c'est de la mesurer dans le pire des cas, en supposant que l'attaquant connaisse parfaitement la méthode de génération et les biais de l'humain qui l'utilise. Ça permet d'avoir une idée de la robustesse d'une méthode qu'on communique massivement pour être appliquée par un grand monde.
Et du coup, si ta méthode c'est de générer un mot de passe de la même longueur qu'un des précédents, oui ton entropie va être beaucoup plus importante, même si théoriquement tu pourrais retomber sur les même mots de passe.
Il faudrait surtout enseigner qu'un mot de passe, même très robuste, ce n'est pas la panacée, et que le minimum pour protéger un service non trivial c'est du MFA.
[^] # Re: Caractère spécial
Posté par NicolasP . En réponse au journal Mon gestionnaire de mots de passe, en 50 lignes de HTML. Évalué à 3.
L'entropie est de 44 bits si l'attaquant sait que cette méthode est utilisée, qu'il connaît la liste de mots initiale et le nombre de mots choisis.
Ce qui est discutable, c'est si 44 bits suffisent ou pas. Mais cet algorithme s'adapte bien, il suffit de prendre une plus grande liste de mots et/ou plus de mots pour augmenter l'entropie jusqu'à la valeur désirée.