Reprise du message précédent :

Il y a donc différents sens du mot crâmé ?
 
edit : Bon après s'il faut débattre des théorèmes ensemblistes. Chacun comprendra ce qu'il voudra.
 
edit2 : Si tu crâmes 99.99993% de ta maison, tu conclus quelle n'a pas crâmé du tout ?

On peut pas cramer 99.9993% du keyspace, tête de noeud

 
Même avec un briquet ?

on va éviter les insultes, merci.

C'est pas une insulte, c'est une constatation

 
Surtout accompagnée d'affirmation gratuite sans explications : on ne peut pas (...) [point]
Ah ouais tu m'aides à me sortir de ma stupidité. Merci.

 
Je pense que ce qu'il veut dire, c'est que les clés sont déjà toutes générables vu qu'il y en a une quantité finie et qu'on sait comment les générer. Mais que même si on les a toutes, le temps nécessaire pour toutes les tester rend la mise en oeuvre très difficile.
Au contraire des 32767 qu'il est simple de tester rapidement.

au revoir

Peut-être en arrêtant d'utiliser le verbe crâmer, on se comprendra mieux sur notre malentendu ?
 

 
Non ?
 
=> []
 
ps : c'est pour cela que je n'aimais pas le français en terminale

Non, c'est juste que si on utilisait 99.9993% du keyspace, ça n'aurait pas été une faille de sécurité, juste un petit problème ... Vu que le nombre de clés générées restait conséquent.
Ici, on a un très très petit nombre de clés générées, donc ces clés sont bien une faille de sécurité et par conséquent il a fallu les blacklister : elles sont donc "crâmées", ou plutôt "désormais inutilisables".

 
 
 
Tu as écrit :  

 
 
La probabilité de tirer une graine blacklistée est de 2^15/2^32 = 1/131072
 
 
Si on réfléchit sur les valeurs pseudo-aléatoires que ces graines nous apportent, je pense que :
- à une graine de 15 bits de longueur correspond une série d´au mieux 2^15 valeurs pseudo-aléatoires (après on boucle)
- à une graine de 32 bits de longueur correspond une série d´au mieux 2^32 valeurs pseudo-aléatoires.
 
Je dis "au mieux 2^n" car le champ des possibles avec x+1 bits est au mieux 2 fois plus grand que le champ des possibles avec x bits.  
Donc si ton générateur est au top il peut monter à 2^15 avec une graine de 15 bits.  
Je wikipedie ici http://en.wikipedia.org/wiki/Pseud [...] _generator et apparement dans la réalité ca commence à 2^15 - 1 (LFSR) et ca peut tomber à 2^(15/2)
 
 
 
 
Bref en se réduisant à des graines de 15 bits, Debian s´est limité à 2^15 séries, chaque série donnant (au mieux) 2^15 valeurs pseudo-aléatoires et pas plus, par manque d'entropie.
Sans le bug, on a des graines de 32 bits, donc 2^32 séries d´au mieux 2^32 valeurs pseudo-aléatoires.
 
 
 
Donc je peux me tromper, mais je pense que, Debian nous a privés :  
- de façon certaine de 2^15 graines sur un capital de 2^32.
- d´au pire 2^15*2^15 valeurs pseudo-aléatoires possibles (si on admet que le générateur d´openssl est au top et exploite à fond l'entropie que lui apporte les graines), sur un capital de 2^32*2^32 (avec toujours le même générateur optimal).
 
Soit une privation de 2^30 valeurs sur 2^64, soit 0.000000006%. On a donc une chance sur 17179869184 de tomber sur une clef blacklistée.
 
 
Ca reste une approximation car en réalité :
- le générateur n'est pas optimal
- je ne sais pas trop ce qui se passe quand on stock seulement 15bits utiles dans une graine de 32bits (après tout 4 char c'est 4 char), mais à mon avis les zéros supplémentaires présents sur toutes ces clefs de 15 bits réels apportent peu d'entropie
- il faut supposer qu'en temps normal openssl utilise bien tous les 32 bits pour les graines. S'ils n'ont pas assez d'entropie (à la Debian donc) et qu'il stocke 20-25bits effectifs, c'est différent. Mais pas envie de calculer à partir de combien de bits on est tranquille...

OK. Maintenant je comprends l'argument, mais je suis toujours pas d'accord
 
Bon, je suis très loin d'être un spécialiste des PRNG, mais voici comment je vois les choses : tu peux considérer le PRNG comme une boite noire à laquelle tu fais manger une graine de n bits et qui te renvoit de manière déterministe une série de nombres vérifiant certaines propriétés de pseudo randomness (uniformité par rapport à certains tests). A partir d'une graine de n bits, on génèrera nécessairement une suite d'au plus 2^n nombres avant de boucler.
 
Jusque là on est d'accord, mais je rebondis sur ta remarque :

Rien ne dit effectivement qu'une graine utilisant seulement 15 bits utiles va générer une suite de plus petite taille, puisque le PRNG (boite noire qui ne voit qu'une seule réalisation du tirage de la graine) ne sait pas que cette graine n'a pas été tirée de manière non uniforme dans l'ensemble des graines de 32 bits.
 
En gros, et dit autrement, pourquoi est-ce que la graine "0"  (qui ne contient que des zéros possède donc très peu d'entropie) génèrerait-elle une suite moins aléatoire que la graine "1" (qui possède plus d'entropie dans sa représentation binaire, mais dont le tirage est exactement aussi probable que 0) ? Si c'était le cas, c'est le PRNG lui même qui serait fortement défaillant et on aurait intérêt à biaiser le tirage des graines pour compenser la mauvaise qualité de certaines...
 
 
EDIT: je sais pas si j'ai été très clair alors je reformule encore une fois pour essayer de faire passer mon message :
 
Pour moi, le but n'est pas que la graine elle-même apporte de l'entropie au PRNG. L'objectif est plutôt de disposer d'assez d'entropie pour générer une graine de manière uniforme.

En se limitant à 32768, les graines Debian vont de :
00000000 00000000 00000000 00000000  
à
00000000 00000000 01111111 11111111  
 
Je pense que tu as raison et que les graines doivent avoir la même capacité entropique... faut espérer que le fait que toutes les graines commencent par 17 bits de 0 n'amène pas un biais entropique

Ce n'est pas ça le problème. Le problème c'est qu'un PRNG, par définition, génère une suite de nombre en fonction de la graine: si on met deux fois de suite une graine précise dans un PRNG et qu'à chaque fois on tire une suite de 10 nombres du PRNG, les deux suites vont être strictement identique.
 
Quand le PRNG est seedé avec une valeur aléatoire dans un pool de 2^32, il est matériellement extrèmement long/difficile de générer toutes les clés associées à toutes les seeds, et de toutes les tester.
 
Par contre quand comme à la suite de ce bug le PRNG est seedé à partir d'un pool de 2^15 valeurs, on se retrouve avec moins de 33000 seed, et le temps de génération d'un dictionnaire de toutes les clés (quelques dizaines de milliers pour chaque type de clés) prend quelques heures. Donc premier gros problème, c'est qu'il devient trivial pour un attaquant d'obtenir et de tester relativement rapidement ce jeu de clés, en ayant de forte chances de tomber sur une clé compromise par rapport à un brute force sur l'intégralité du seedspace.
 
2e problème, on se retrouve extrèmement rapidement avec des collisions (e.g. il en est fait mention sur le blog GitHub, donc ce problème a été rencontré), càd des gens qui génèrent la même clé de manière totalement indépendante.

Bien sûr. Mais avec Xavier_OM on parlait d'un autre problème, qui est la probabilité qu'un openSSL non biaisé génère (par un malheureux hasard) une clé compromise.
 
En gros, même parmi les utilisateurs de autres distros, 1 utilisateur sur 130000 en moyenne utilise une clé qui figure maintenant dans le dictionnaire qui risque prochainement d'être massivement utilisé pour brute-forcer.

Ok, j'avais pas percuté

C'est déjà le cas, j'ai vu passer des posts parlant de modifications ayant déjà eu lieu dans les brute-forcers pour commencer par les clés compromises.
 
Je crois que Debian a commencé à altérer le truc pour empêcher la génération des clés compromises, je ne sais pas ce qui va se passer pour les autres distros.
 

Ca me semble bizarre que le PRNG soit seedé avec seulement 32bits, c'est minuscule.

 
 
La testing et la unstable ne sont pas affectées non plus !
 
 
Sauf évidement si les clefs avaient été générées sur un système en etch juste après le dist-upgrade

Si, le problème est fixé dans 0.9.8g-9 pour Sid et Lenny, mais elles étaient toutes les deux affectées.

PS : Et c'est très facilement exploitable !
 
Pour le rsa j'avais genre 65535 combinaison possible de clef.
 
Je suis rentré sur mes serveurs ainsi que sur 2/3 serveurs de potes en moins de 10 minutes...
 
 
Donc pour ceux qui se demandent si c'est exploitable facilement OUI !

Je me suis basé là dessus :
http://www.openssl.org/ source/ openssl-0.9.4.tar.gz/ openssl-0.9.4/ crypto/ evp/

 
J'avoue très humblement que j'ai lu le code très en diagonale, et je n'ai pas cherché à savoir quand étaient définies les macros NO_MD2, NO_MD5, etc. ni ce que représentaient les autres types concernés MD2_CTX, MD5_CTX , etc.
Mais bon il me semble quand même qu'on peut en conclure que la seule garantie qu'on ait sur la taille de la clé est qu'elle fait au moins 4 char, mais pas nécessairement plus.

 
 
Non j'ai des serveurs en testing et les clefs étaient bonnes dessus...
 
Les serveurs en testing avec problème c'était uniquement les vieux qui avaient subits un dist-upgrade c'est tout.

 
   
Dans testing/lenny, les nouveaux packages ne sont arrivés qu'aujourd'hui ...

Bah oui j'ai bien vu mais j'obtiens que des  
 
Not blacklisted: 2048 .....
Not blacklisted: 1024 .....
...
 
Pourtant j'ai rien fait dessus je comprends pas.

Les scripts pour vérifier la solidité d'un serveur sont ils publiquement dispos ?  (ou c'est du warez ?)

 
 
Du warez ???      

Me suis trompé de mot  ca arrive !
 
Bref t'aurais pas un lien sous le coude ? j'ai la flemme de faire le tour de 50 sites la

 
 
Tu as tous les outils ici :
 
http://metasploit.com/users/hdm/tools/debian-openssl/

Clés générées avec une autre distro ou bien clés générées avant la dist-upgrade qui a amené le openssl compromis?

Premier post, premier lien

Ouais je l'ai déja vu et utilisé
 
Heu bon bref laissez tombé c'est vendredi je fatigue la

 
 
merci

Une note un peu plus légère :
 
http://xkcd.com/424/
 

je vois bien comment la faille est exploitable via SSH.
mais je ne pige pas l'impact sur les clé d'un serveur http
si qqn peut m'en dire plus
merci

Sur un serveur http, rien ne change.
Sur une connexion https, l'attaquant peut théoriquement décoder les échanges entre le client et le serveur, la connexion n'est donc plus sécurisée

Et les certificats clients ...

Je sais pas si ça a été dit mais pour vérifier ses clef il y a une commande toute simple:
ssh-vulnkey
 

tu penses que les certificats fournis par les impôts sont touchés ?

Spa mon problème

J'avais plusieurs serveurs en prod avec une clé blacklistée dans l'authorized_keys de root

Moi y avait la clef d'un collègue qui etait installée sur certains serveurs et compromises.
 
Mais comme je m'étais déjà fait chier à me coder un script pour installer/supprimer des clefs en lot, ca a été vite réglé

Un patch du patch:
http://lists.debian.org/debian-sec [...] 00155.html
\o/

Au niveau des réactions officielles qui émanent suite à la faille introduite dans OpenSSL, Steve McIntyre, Chef de Projet de Debian (DPL) s'est récemment exprimé: