« 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.
Ce n'est pas pour rien qu'on utilise le SHA256 (et ses cousins comme le SHA512) en cryptographie. Trouver une préimage est complètement hors de portée à l'heure actuelle
Oui SHA256 est utilisé en cryptographie. Oui il est résistant aux attaques de preimage.
Mais non, ça n'en fait pas un algorithme idéal pour le hachage des mots de passe. Ce qui te sauve, c'est qu'en entrée, tu as une partie aléatoire avec une bonne entropie.
Il y a les Tile Trackers aussi qui marchent avec Android.
Ça permet de recevoir une notification sur son téléphone en cas d'éloignement du tracker, ça permet de le faire sonner s'il n'est pas trop loin. Par contre la géolocalisation nécessite qu'il y ait quelqu'un avec l'application Tile pas trop loin. Il n'y a pas de chiffres précis, mais à mon avis on est très très loin du maillage des iPhone. Peut-être que dans un parc d'attractions avec une grande densité de personnes, ça suffit, mais impossible à savoir sans chiffres précis.
Un autre inconvénient, c'est que ça fait une société de plus à qui envoyer en permanence ta géolocalisation.
Il me semble que les métadonnées ne permettent pas d'identifier les personnes qui communiquent puisqu'il s'agit d'une clé générée localement et transmise "de la main à la main" entre elles. Donc même Olvid ne sait pas qui sait
La clef publique du destinataire est stockée sur le serveur. Si le modèle de menace est un geek qui a accès au serveur, on est d'accord : ça ne permet pas d'identifier les personnes qui communiquent. Mais si le modèle de menace c'est la vraie vie et la NSA qui essaye d'identifier les membres du gouvernement français qui communiquent, ça n'est pas très efficace (à moins que d'autres contre mesures ne soient implémentées).
Ils ont peut-être quelques dizaines de personnes à identifier. En notant les moments où ces personnes pianotent sur leurs téléphones, celles où elles ne le font pas et en corrélant avec ce qui passe sur le serveur, ça va aller vite pour identifier à qui est telle clef publique (très très vite pour ceux qui utilisent beaucoup le service, plus long pour ceux qui l'utilisent moins).
A noter que même sans ça, vu que la NSA a sûrement déjà une bonne idée de qui communique avec qui à quel moment/quelle fréquence, elle pourrait arriver à un bon taux de découverte.
Une technique que j'ai vue ailleurs c'est de ne pas utiliser l'alphabet français (et surtout pas l'anglais…). Si l'attaquant sait que tu es français et compte sur une attaque par dictionnaire, prendre des mots de swahili (pas d'accents, peut s'écrire juste avec de l'ASCII), basque, breton ou même d'italien peut aider.
Non, mauvaise idée.
Comme dit plus haut, une bonne technique doit rester fiable y compris si ton attaquant sait ce que tu utilises pour générer tes mots de passe. Avec la technique xkcd, tu peux même donner ta liste de mots à l'attaquant, ça ne pose pas de souci. Si tu as une liste de 2048 mots, tu as 11 bits d'entropie par mot. Tu prends autant de mots que nécessaire pour arrivée à l'entropie totale voulue, et tu as un mot de passe suffisamment fort sans faire aucune hypothèse sur les connaissances ou non de ton attaquant.
Concernant le désalignement de config MX, l'avez-vous remonté ? On a peut-ête qqchose à corriger.
Oui et j'ai eu la réponse du support à l'instant. C'est la config envoyée par email qui est bonne.
Concernant les stickers on les a reçus, mais on ne les a pas encore envoyés. Ça risque d'être plus énergivore de vérifier à qui on doit ou pas les envoyer que de les envoyer à tout le monde.
[^] # 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.
[^] # Re: C'est alléchant mais
Posté par NicolasP . En réponse au journal Mon gestionnaire de mots de passe, en 50 lignes de HTML. Évalué à 3.
Oui SHA256 est utilisé en cryptographie. Oui il est résistant aux attaques de preimage.
Mais non, ça n'en fait pas un algorithme idéal pour le hachage des mots de passe. Ce qui te sauve, c'est qu'en entrée, tu as une partie aléatoire avec une bonne entropie.
[^] # Re: Samsung
Posté par NicolasP . En réponse au message Alternatives aux airtags. Évalué à 2.
Il y a les Tile Trackers aussi qui marchent avec Android.
Ça permet de recevoir une notification sur son téléphone en cas d'éloignement du tracker, ça permet de le faire sonner s'il n'est pas trop loin. Par contre la géolocalisation nécessite qu'il y ait quelqu'un avec l'application Tile pas trop loin. Il n'y a pas de chiffres précis, mais à mon avis on est très très loin du maillage des iPhone. Peut-être que dans un parc d'attractions avec une grande densité de personnes, ça suffit, mais impossible à savoir sans chiffres précis.
Un autre inconvénient, c'est que ça fait une société de plus à qui envoyer en permanence ta géolocalisation.
[^] # Re: Petit joueur
Posté par NicolasP . En réponse au journal Combattre la procrastination en publiant mes travaux non finis. Évalué à 10.
Ça a l'air intéressant, je lirai demain.
[^] # Re: Trolesque
Posté par NicolasP . En réponse au lien Olvid la sécurité à la française c'est chez les américains. Évalué à 2.
La FAQ : https://olvid.io/faq/serveur-et-open-source/.
[^] # Re: Trolesque
Posté par NicolasP . En réponse au lien Olvid la sécurité à la française c'est chez les américains. Évalué à 10. Dernière modification le 17 décembre 2023 à 21:49.
La clef publique du destinataire est stockée sur le serveur. Si le modèle de menace est un geek qui a accès au serveur, on est d'accord : ça ne permet pas d'identifier les personnes qui communiquent. Mais si le modèle de menace c'est la vraie vie et la NSA qui essaye d'identifier les membres du gouvernement français qui communiquent, ça n'est pas très efficace (à moins que d'autres contre mesures ne soient implémentées).
Ils ont peut-être quelques dizaines de personnes à identifier. En notant les moments où ces personnes pianotent sur leurs téléphones, celles où elles ne le font pas et en corrélant avec ce qui passe sur le serveur, ça va aller vite pour identifier à qui est telle clef publique (très très vite pour ceux qui utilisent beaucoup le service, plus long pour ceux qui l'utilisent moins).
A noter que même sans ça, vu que la NSA a sûrement déjà une bonne idée de qui communique avec qui à quel moment/quelle fréquence, elle pourrait arriver à un bon taux de découverte.
[^] # Re: Pas tout compris
Posté par NicolasP . En réponse au lien Collection de sites qui ont des consignes de mots de passe à la noix . Évalué à 3.
Non, mauvaise idée.
Comme dit plus haut, une bonne technique doit rester fiable y compris si ton attaquant sait ce que tu utilises pour générer tes mots de passe. Avec la technique xkcd, tu peux même donner ta liste de mots à l'attaquant, ça ne pose pas de souci. Si tu as une liste de 2048 mots, tu as 11 bits d'entropie par mot. Tu prends autant de mots que nécessaire pour arrivée à l'entropie totale voulue, et tu as un mot de passe suffisamment fort sans faire aucune hypothèse sur les connaissances ou non de ton attaquant.
[^] # Re: Retour d'expérience
Posté par NicolasP . En réponse au journal [publicité] galae, le service email éthique et libre (et français) est désormais ouvert \o/. Évalué à 3.
Oui et j'ai eu la réponse du support à l'instant. C'est la config envoyée par email qui est bonne.
Oui je peux comprendre, pas de souci :).