Le 17/05/2017 à 17h 05

Il n’y a pas de nœuds de sortie sur les services cachés.
Le service caché et le client se rencontrent sur un nœud pris au pif (l’introduction point), il y a donc 6 couches de chiffrement, et l’introduction point ne connaît ni l’identité du client (1 circuit de 3 nœuds entre lui et le client) ni le service caché (pareil).
Tu n’as donc aucun moyen de remonter à la source. Même en saisissant toutes les machines.

Le 17/05/2017 à 16h 27

Si tu n’es pas trop bête (les erreurs de SilkRoad & autres étaient humaines, pas techniques), Tor est un excellent moyen de te mettre à l’abri. Certainement le meilleur (sinon le seul d’ailleurs) qui existe aujourd’hui.

Le 17/05/2017 à 16h 19

Le C&C est dans un .onion. Il n’y a pas de guard ni d’exit node dans ce cas. Le trafic reste 100% à l’intérieur de Tor, tu n’auras donc strictement rien à comparer entre avant et après.

Le 17/05/2017 à 16h 18

Les circuits Tor changent toutes les 10min. Et j’ai bien indiqué aussi derrière que j’avais des milliers de connexion ouvertes en permanence sur ma machine.

Donc même en saisissant ma machine, même si j’avais des logs (ce qui n’est pas le cas), tu aurais 1000 machines à aller saisir pour aussi espérer des logs, dans a minima une 10aine de pays, te menant à 1000 machines pour chaque machine saisie. Et donc un bon petit million de machines (soit tout le parc des nœuds Tor en fait) si tu veux espérer remonter à la source des données (3 nœuds par circuit).

Bref, c’est juste peine perdue.

Le 17/05/2017 à 16h 07

Ou pas justement. Ça va être du trafic qui va être reporté aléatoirement dans le réseau Tor. Ça va foutre un bordel pas possible pour recouper tout ça. Et en prime ça suppose que tu aies accès aux méta-données (dont je doute déjà de l’existence…) de l’ensemble des nœuds utilisés (donc de 3 pays différents, obligatoirement), pour chaque connexion. Sur 2 millions de connexion (soit 6 millions de sauts Tor, sans parler qu’ils sont renouvelé toutes les 10min…), c’est l’intégralité des logs du trafic planétaire qu’il te faut…

Et si tu as accès à ces méta-données, tu n’as certainement pas besoin de saisir les machines. Qui ne contiennent aucune info de toute façon.

Le 17/05/2017 à 15h 50

Sauf que les nœuds Tor sont conçus pour que même une correllation de traffic soit assez difficile à réaliser, sauf à avoir VRAIMENT de très gros moyens à disposition.
Mon nœud générait 1To de données par semaine, et avaient des milliers de connexion Tor ouvertes en permanance. Bon courage pour la corrélation.
Bon courage aussi pour la coordination internationale, la sélection des nœuds utilisés pour un circuit Tor impose le passage par 3 pays différents !
Et sachant qu’il n’y a aucun log sur ces machines, leur saisie était de toute façon totalement inutile !

Le 17/05/2017 à 15h 15

Je préfère ne pas compter dessus :P
Il y a certainement une chance non nulle, mais dans trop longtemps et sans garantie. Donc autant considérer les données perdues (et ça sert à ça les backups, se protéger de Wannacry et se protéger de ceux qui ne se sont pas protégés de Wannacry :P)

Le 17/05/2017 à 15h 01

Je ne suis pas hébergeur de contenu. Je n’ai même aucun contenu.
Je suis équivalent ou en tout cas plus proche d’Online (je fournis un réseau dans le réseau, je ne fais que véhiculer des petits paquets dont je n’ai même aucune sorte d’idée de ce que ça peut bien être) que d’un hébergeur (hébergement du contenu). Et aucune loi n’impose de loger quoi que ce soit dans ce cas.

Les seules obligations actuelles que je connaisse sont
1- obligation de log des IP distribuées à leurs clients par les FAI (date, IP et identité du client)
2- obligation de log côté serveur web d’un hébergeur (date, IP du visiteur, contenu visité)

Le 17/05/2017 à 14h 15

Vu que la LCEN date de 2004, et que l’article 1 de la LCEN est la définition de ce qu’est un réseau, je vois mal en quoi un hypothétique article 1 de 2001 imposerait quoi que ce soit à une entité comme Online (qui n’est pas hébergeur de contenu, mais opérateur de réseau).

Le 17/05/2017 à 14h 00

Non. Online n’a aucune obligation de stocker ce genre d’information. Ce niveau de détail serait de toute façon instockable tellement les informations seraient collosales (mon nœud Tor générait 300Mbps de trafic en continu, soit 1To de données par semaine).

Le 17/05/2017 à 13h 58

Ils n’ont pas ce genre de log. Et même s’ils l’avaient, ça ne servirait strictement à rien dans le cadre de l’enquête. Aucune des IP dedans n’est responsable dans l’infection Wanacry (une des machines est la machine infectée, l’autre est juste l’équivalent d’une porte d’entrée publique permettant de communiquer avec le réseau Tor).

Le 17/05/2017 à 13h 42

Je suis un des nœuds saisis. Je te garanti qu’il y a 0 log. Rien n’est tracé, rien n’est stocké. Aucune information utile, aucune IP, aucun journal.
Et même si log il y avait, je n’étais de toute façon que le 1er maillon de la chaîne Tor qui en comporte 3, donc sans aucune information sur la vraie machine liée à l’infection Wannacry. La seule machine que je voyais était la machine infectée en entrée, et un autre nœud Tor (le middle cette fois) en sortie. Rien d’autre.

Le 17/05/2017 à 13h 31

Les logs ? Quels logs ? Il n’y en a juste pas sur les relais Tor.

Le 10/02/2017 à 17h 38

Mihashi a écrit :

mais, j’insiste, ce n’est pas que pour cette raison que c’est non inversible


En fait si, la condition de collision est suffisante pour garantir la non réversibilité d’une fonction.
Tout algo connaissant des collisions est non réversible puisqu’au moins 2 valeurs de départ pointant sur la même valeur d’arrivée, il est impossible de décider quelle est la “bonne” valeur de départ à partir d’une de ces valeurs.

Par contre c’est effectivement une mauvaise idée de se servir de cette propriété en cryptologie et surtout en hashage, puisqu’une bonne fonction de hashage doit justement minimiser les collisions.
Dans le cas de SHA2, on sait qu’il existe forcément des collisions puisque l’ensemble de départ (tout :P) est infiniment plus grand que l’ensemble d’arrivée ([0-2^256]) et donc qu’il existe même une infinité de valeurs possédant le même hash. Et donc que la fonction est mathématiquement non inversible.

 Cryptographiquement, on va plutôt raisonner en restreignant l’ensemble de départ à aussi [0-2^256]. Comme SHA2 est une bonne fonction de hash cryptographique, il se trouve qu’elle va être très proche d’une bijection de [0-2^256] sur [0-2^256], donc n’avoir que peu de points en doublon, et donc être théoriquement inversible (« presque partout » comme diraient les mathématiciens).
 La vraie définition de l’inversibilité en crypto est surtout qu’il n’existe pas de manière plus efficace de calculer cette pseudo-bijection inverse que celle consistant à fabriquer la table inverse par force brute en calculant chaque image pour chaque valeur de [0-2^256]. Et aujourd’hui, en l’état des connaissances, c’est juste physiquement impossible de travailler sur des données aussi collosales qu’un espace de 256 bits (espace de stockage supérieur aux nombres d’atomes constituant l’Univers), temps de calcul dépassant l’âge actuel de l’Univers, …).

Le 10/02/2017 à 17h 23

OlivierJ a écrit :

Je n’avais pas vu ça, car je pensais qu’un sel commun à tout le monde revenait à modifier la fonction de hashage. Tu es sûr que ça revient tout à fait au même ? Qu’on peut obtenir le même hash recherché sans le sel ?


Si le sel est commun, disont SSSS, ça revient à transformer un bruteforce de tous les XXXX vers HHHH en tous les SSSSXXXX vers HHHH. Donc plutôt que de générer des données au pif, de calculer le hash et de vérifier s’il est dans la table, tu vas générer une donnée au pif, lui foutre SSSS devant, hashé et vérifier la base.
Autant dire qu’en terme de complexité pour l’attaquant, tu n’as strictement rien changé, il pourra toujours comparé chacun de ses hashs calculés avec l’ensemble de la base.

Avec un sel par utilisateur, il devra faire la même procédure pour chaque utilisateur, ralentissant son attaque d’un facteur égal au nombre d’utilisateur.

Le problème est bien visible avec un exemple.

 Pas de sel ou un sel partagé
Utilisateur 1 : HHHH
Utilisateur 2 : IIIIII
Utilisateur 3 : JJJJ
Utilisateur 4 : HHHH

Déjà je vois immédiatement que 1 et 4 ont le même pass.
Je génère des tonnes de pass aléatoires, l’un d’eux (pppp) me donne HHHH. J’ai donc le pass de 1 ET de 4.
 Si j’ai un sel partagé SSSS, je calcule juste hash(SSSSpppp) au lieu de hash(pppp), si ça me donne HHHH, j’ai aussi le pass de 1 ET de 4. Durant mon parcours des nombres aléatoires, j’ai aussi très bien pu trouver IIII et JJJJ, et donc avoir casser 2 et 3 au passage.

 Sel unique
Utilisateur 1 : SSSS|HHHH
Utilisateur 2 : TTTT|IIIIII
Utilisateur 3 : UUUU|JJJJ
Utilisateur 4 : VVVV|KKKK

Bien que 1 et 4 utilisent le même mot de passe, je n’ai déjà plus la possibilité de le deviner a priori.
 Je génère des tonnes de pass aléatoires, l’un d’eux (pppp) concaténé avec SSSS me donne HHHH. J’ai donc le pass de 1. Je ne peux pas deviner que j’ai aussi le pass de 4, puisqu’il aurait fallu que je calcule aussi VVVVpppp ce que je n’ai pas fait… Même si au court de mon parcours je tombe sur IIII à partir de iiii, j’ai en fait calculer hash(SSSSiiii) = IIII, et donc ça ne veut absolument pas dire que j’ai trouvé le passe de 2, puisqu’il aurait fallu en fait que je calcule hash(TTTTiiii)…

 Bilan : avec un sel unique pour chaque utilisateur, un attaquant est incapable de casser plus de 1 utilisateur à la fois, alors qu’avec un sel partagé ou pas de sel du tout, il va casser tous les utilisateurs d’un coup. Ou encore dit autrement, en ayant parcouru l’ensemble des valeurs des 2^256 possibilités de SHA2, il n’aura trouvé qu’un seul utilisateur avec un sel unique alors qu’il aura trouvé TOUS les utilisateurs sans sel ou avec un sel partagé.

Le 10/02/2017 à 16h 21

OlivierJ a écrit :

C’est moche non ? En tous cas je ne ferais pas ça vu l’importance du sel.


 Le sel n’est pas critique et n’a aucun intérêt à être caché. Sa publication ne change rien à la sécurité, son objectif est uniquement d’empécher un bruteforce massif de la table et d’obliger un attaquant à travailler par utilisateur.

 Dans tous les cas, comme il doit être unique par utilisateur, ça sera difficile de le garder planquer.
Certains le code en dur, mais il est du coup commun à tous les utilisateurs et ne sert alors à rien (on bruteforcera toute la base comme s’il n’y avait pas de sel).


OlivierJ a écrit :

Histoire d’être certain :

• si la base de hash est salée et que le sel n’est pas en possession de l’attaquant, c’est mort non ?
  


• si on dispose du sel, avec une bonne fonction de hash, j’imagine que trouver un mot de passe qui génère le hash recherché, ça peut prendre un temps dingue, non (vu que c’est le but du hash d’empêcher la chose) ?
  
  
   Si le sel n’est pas en possession de l’attaquant, c’est mort, mais pas pour l’attaquant, pour toi. Ça veut dire que tu as raté quelque chose sur le principe du sel :P Cf juste au-dessus.
   
   Si ton algo de hash est correct, tu vas en effet galérer à trouver une collision. Tu auras alors effectivement plutôt intérêt à faire une attaque par dictionnaire que par pure force brute, la probabilité que ton utilisateur ait un mot de passe faible étant bien plus grande (en pratique elle est même proche de 1…) que celle de trouver une collision sur SHA2, scrypt, PBKDF2 ou argon2…
   Après, on trouve dans le commerce pour quelques centaines ou milliers d’euro des machines capables de calculer du SHA2 à plusieurs centaines de terra hash par seconde (Bitcoin s’est même spécialisé là dedans)… Ça prendra toujours quelques 262267361648628767629672630392222738306493224672122028428 d’années à collisionner un hash, mais on fait quand même des progrès spectaculaires en ce moment (les nombres commencent à pouvoir s’écrire sur une seule ligne :P).

Le 10/02/2017 à 15h 29

Faut peut-être arrêter de raconter n’importe quoi à un moment donné hein :)

Le sel est un paramètres qui doit nécessairement être en clair et stocké dans la db. Généralement il est même concaténé en tête du hash avant d’être stocké dans la base.
Il n’y a aucune limite haute à casser un hash, il suffit de trouver un mot de passe (pas forcément le véritable d’ailleurs) qui collisionne sur le même hash que celui indiqué dans la base. Il n’y aura même pas de candidat potentiel, vu que tu as la certitude de pouvoir t’authentifier avec à partir du moment où son hash correspond à celui en base de données.
S’il n’y a pas de sel, je ne me galère du coup même pas à faire une attaque par dictionnaire, mais je génère juste des tonnes de hash sur des tonnes de valeurs totalement aléatoires. En effet, comme ci-dessus, je m’en fous de trouver ton mot de passe, j’ai juste besoin d’en trouver un qui collisionne le hash de la base (il y a de très fortes probabilités que ça soit réellement le bon mot de passe, mais ce n’est pas garanti puisqu’un hash n’est pas bijectif mais uniquement surjectif).  S’il y a un sel, je dois juste procéder utilisateur par utilisateur au lieu d’attaquer tous les hash en même temps.
Et si tu as choisis un mot de passe trop faible (et qu’il n’y a pas de sel), il y a même une chance non négligeable que le hash de ton mot de passe soit déjà connu (rainbow table) et donc que le casser prenne quelque chose comme 50ms.
En plus, ces calculs sont fait offline, donc toute parade anti-bruteforce mise en place par le site en question seront totalement inefficaces. Je bruteforcerais sur ma machine jusqu’à trouver une collision, et je m’authentifierais une seule et unique fois sur le site en question avec le mot de passe trouvé, qui validera obligatoirement l’accès au compte.

Bref, une base de données dans la nature mal hashée ou salée, c’est juste une véritable bombe à retardement et rien ni personne ne peut plus rien y faire. Le seul conseil qui vaille est d’alors changer immédiatement son mot de passe (ou de cesser d’utiliser le service jusqu’à ce qu’ils aient un hash suffisamment sécurisé), et de le changer aussi partout ailleurs où on l’avait utilisé.

On ne devrait jamais utiliser 2× le même mot de passe sur 2 services différents justement parce qu’en cas de fuite d’une base de données, les probabilités sont élevées que le service n’ait pas pris au sérieux la sécurité et ait stocké vos mots de passe au pire en clair au mieux hashé sans sel. Une fois le pass collisionné, soyez sûr qu’un attaquant ira tester le couple login/mot de passe obtenu sur tous les autres services qui lui passeront sous la main !

Le 10/02/2017 à 15h 05

C’est compliqué. Parce que justement, tu n’arrives pas à te connecter au serveur en face. Et que tu n’as strictement aucune idée de pourquoi ça merde…
Tout ce que ton navigateur sait, c’est qu’il n’a pas pu négocier avec le serveur en face. La raison réelle restera éternellement inconnue…

Le 10/02/2017 à 10h 23

Ça existe. Ça s’appelle NO_CYPHER_OVERLAP, mais faudrait juste améliorer la page d’erreur :P
 
https://null.badssl.com/

Pour le pourcentage, on parle de quelques pourcents maximum. À vu de pif je dirais même moins de 1%…Ça ne concerne globalement que IE8 sous XP…

Le 09/02/2017 à 21h 08

Ça sent une énorme faiblesse.
Déjà ça veut dire qu’ils stockent le mot de passe en clair.
Et qu’en plus de ça, ils font un test à la con en ajoutant lettre par lettre jusqu’à arriver à la fin ou à ce que ça passe…
À pleurer…

Le 09/02/2017 à 19h 11

haazheel a écrit :

Pas mal " />
Par contre, celui-ci est plutôt rassurant:
https://www.ssllabs.com/ssltest/analyze.html?d=www.impots.gouv.fr


Et d’ailleurs SSLLabs va bientôt changer leurs notations, et même les impôts vont virer au rouge à cause de 3DES qui n’est actuellement pas sanctionné.
https://blog.qualys.com/ssllabs/2016/11/16/announcing-ssl-labs-grading-changes-f…
 
Si vous voulez vous faire peur :
 
https://imirhil.fr/tls/#Banques%20en%20ligne
https://imirhil.fr/tls/gouv.fr.html

/me va encore se faire gronder par @david_l /o

Le 09/02/2017 à 17h 57

Juju251 a écrit :

Et donc ?

Parce qu’il y a des gens qui ne veulent pas se sortir les doigts (on remets en perspective, Kp2 parle de changer de … navigateur) il faut accepter de rester a des normes de sécurité obsolètes ?!

A un moment donné, ce genre de comportements c’est juste inacceptable … 


 
Surtout que ça met en danger tout le monde, y compris ceux avec des navigateurs plus ou moins à jour.

 Parce que le serveur supporte des trucs pourris, je peux forcer les navigateurs à se rabattre sur ces trucs pourris alors que normalement ils auraient du utiliser quelque chose de plus fort.
Ou encore dans le cas de EBP, un de leur serveur supporte du SSLv2, je peux donc profiter de la faille DROWN même si votre navigateur ne supporte pas cette veille suite de chiffrement.

 Dit autrement, si vous êtes sur le même réseau que moi (au pif au Starbuck du coin ou sur un wifi public), je peux plutôt « facilement » (c’est l’affaire de 2 ou 3 heures voire de quelques minutes pour les trucs les pires) avoir accès à vos cookies ou à votre mot de passe, et ainsi récupérer tous vos plans comptables ou les fiches de paies de tous vos employés. Même si votre navigateur Firefox est le plus à jour disponible…

Le 09/02/2017 à 17h 28

ZoZo a écrit :

Pour la taille, ça vient des administrateurs de base de données qui gardent leurs habitudes des années 80 et essayent d’économiser quelques octets par enregistrement dans une table.
Cela dit, les mots de passe (et tous les champs en fait) doivent quand même avoir une limite, sinon t’as des rigolos qui vont t’envoyer des mots de passe qui prennent plusieurs Mo à stocker, ça va vite s’accumuler.
Quant aux caractères interdits, parfois alors qu’ils sont dans les 128 premiers de la table ASCII et donc ne prenne pas plus de place en base, ça me laisse perplexe.


C’est justement totalement débile si tes mots de passe sont hachés.
Une fois passés à la moulinette d’un sha512, ils feront TOUS 512 bits et ne contiendront que des caractères hexadécimaux (0-9A-F).
Même si en entrée tu lui as mis l’intégral des 2To de ta collection de porn ou que ton mot de passe contient des
sinogrammes encodés en UTF-8…

C’est même pour ça que tu peux être sûr qu’un site qui limite la taille du mot de passe ou les caractères utilisables ne stocke pas de manière sûre ce mot de passe dans sa base de données. Et même très certainement en clair…

Le 09/02/2017 à 16h 09

David_L a écrit :

Je me tâte à modérer pour auto-promo " />


Oh, tu peux remplacer parhttps://gordon.re/developpement/mot-de-passe-pourquoi-comment.html si tu préfères " />

Le 09/02/2017 à 16h 05

gordonzola a écrit :

Le fait que le sel (la chaîne aléatoire en question) soit connue ne représente pas de risque. Par contre, en crypto, ne réinventez pas la roue, et suivez aveuglément les conseils des experts (Aeris, en l’occurrence, est une source sûre)


Pas trop aveuglément quand même :) L’intime compréhension, c’est toujours mieux :P

Le 09/02/2017 à 15h 49

Arrêtez de vous prendre la tête, tout est expliqué ici…
https://blog.imirhil.fr/2015/10/27/stockage-mot-passe.html

Le 23/08/2016 à 18h 33

Mihashi a écrit :

Je suis loin d’être expert, mais le problème c’est pas tout simplement les short-ID ?  

 
C’est exactement ça. Les short-ID c’est le mal.
Et suite au mirroring plus profond de certaines clefs, c’est devenu doublement plus le mal :P

Le 22/08/2016 à 21h 19

KissFC a écrit :

Il n’y a pas bruteforce => tu reforge le certificat racine a la suite. Tu collisione pas toutes les clés, juste une suffit : comme dit au dessus tu reproduis ensuite le certificat racine. 


Il n’y a justement PAS de certificat racine sous GPG. Et récupérer une clef compromise ne compromet pas l’ensemble de la chaîne.

Pour la faille de 2014, le problème est beaucoup plus complexe que tu ne le penses.
Les serveurs de clef ne supportent que les short ou long ID pour récupérer une clef.
Si tu demandais à télécharger une clef à partir de son empreinte complète (par exemple 0x6A68B76126297666 ECF48F03EFB74277ECE4E222), GPG faisait l’accès en réalité par le short ou long ID (selon ta configuration). Ici il réclamait donc la clef 0xEFB74277ECE4E222 ou 0xECE4E222.
Mais il ne vérifiait pas en retour que la clef téléchargée correspondait réellement à l’empreinte complète (cas d’une clef collisionnée).

Les seules personnes vulnérables étaient donc les personnes récupérants leurs clefs en spécifiant une empreinte complète ET qui n’avaient pas configuré leur GPG pour utiliser les long-ID (une collision sur le long-ID (64 bits) est improbable à l’heure actuelle) ET qui ne vérifiaient pas l’empreinte manuellement par la suite (toute signature devrait impliquer la vérification manuelle de l’empreinte complète).
Et en plus pour être exploitable, l’attaquant doit être en mesure de pouvoir intercepter les communications entre les 2 correspondants (et pas que d’un seul côté, sinon le récepteur recevra un message chiffré par la mauvaise clef, donc ne pourra pas le lire, donc détectera l’attaque).

Et même si tu récupérais une mauvaise clef, tout le reste de ton porte-feuille reste 100% safe puisqu’il n’y a pas de racine (l’intérêt de GPG par rapport à X.509/TLS).

Bref, certes c’est une erreur de GPG, mais ça n’était pas exploitable en pratique.

Le 22/08/2016 à 18h 55

edrin17 a écrit :

Question: À qui profite le crime la faille ?
Vu la débauche de moyens mis en œuvre c’est pas Jean-Paul dans sa cave de geek qui fait ça… " />


La question à 10 balles…

 Surtout que cette faille est connue depuis 2011 et que toute personne faisant de la crypto a depuis longtemps désactivé les short-ID… Et donc seul un nœud-nœud pourrait se laisser berner.

Reste les logiciels mal configurés par défaut, qui pouvaient du coup récupérer la mauvaise clef auprès des serveurs de clef quand on précisait le short-ID (par exemple lors du rafraîchissement de la clef correcte).
Je me suis personnellement fait avoir sur ce cas-là.

 Mais les fausses clefs étant et révoquées et non utilisables (elles ne permettent pas le chiffrement), elles n’étaient pas réellement dangereuses. Un proof-of-concept à taille réelle peut-être ?

Le 22/08/2016 à 18h 32

KissFC a écrit :

Rajoute aussi qu’il y a une volonté de recréer l’emprunte par captation de messages “legit” envoyés aux serveurs : le cassage du certif ne se fait pas par brute force mais par compilation de réponses.
La volonté n’étant pas plus de casser que d’avoir une emprunte valide durable dans le système.

Pour la puissance de calcul, elle est toute relative, ça fait un certain temps que les puces AMD sont devenues très bonnes pour faire ce genre d’opérations sha/ash + guess, restait qu’a monter un POC pour montrer que PGP était faillible de la sorte sur certaines configs.
Se qui m’étonne, c’est le nombre de bits nécessaires relativement faible pour reforger une clé valide, ça veux dire que derrière reforger une empreinte complète devient possible en relativement peu de temps. :/


 Euh… E_TOO_MUCH_NO_SENSE

1- Je ne vois pas où il y a la moindre interception de message « legit »…
Il suffit d’utiliser un annuaire de clef pour trouver celle qu’on veut cibler, puis générer une collision de short-ID, puis itérer sur les signatures, etc
Et l’attaque est par bruteforce (il n’y a pas d’autre moyen de collisionner un ID de toute façon).

2- Les puces ont beau être effectivement très efficace pour faire du calcul de hash, aucune ne l’est pour générer rapidement des clefs RSA de 2048 bits comme celles collisionnées, qui est basé sur de la recherche de nombres premiers aléatoires (processus non accélérable, il faut bruteforcer pour trouver de tels nombres…).
Les meilleurs CPU ne génèrent que quelques centaines de clefs GPG par seconde.

3- Un short ID fait 8 octets hexadécimaux soit 20 bits de sécurité. Ça se casse donc en « seulement » 4 milliards de tentative. C’est ridiculement petit en terme de crypto (on conseille actuellement au moins 128 bits de sécurité).
Ramené à la centaine de clefs par seconde, ça donne quand même une 50aine de jour de calcul pour collisionner une clef…
Pour générer le faux graph de Torvald, ça a donc été l’équivalent d’années de calcul qu’il a fallu paralléliser massivement (donc avoir accès à des ressources importantes) pour arriver à collisionner autant.

Le 22/08/2016 à 17h 00

le podoclaste a écrit :

Je comprend pas trop la première faille. C’est davantage une faille d’un site qui collecte les clés publiques plutôt que de PGP lui-même, non ?


Non. Le problème vient que des personnes s’amusent à générer des clefs dont l’ID court sur 8 octets est le même.
Par exemple la vraie clef de Torvald est 0x79BE3E4300411886, et la fausse 0x6211AA3B00411886 (même short-ID 0x00411886).
Cette « faille » n’est pas nouvelle. Voir par exemplehttp://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html qui date de 2011.

Là où est la nouveauté, c’est qu’un attaquant s’amuse à générer un ensemble de fausses clefs et à recréer la chaîne de certifications des vraies clefs.
Par exemple, Torvald (0x79BE3E4300411886) est signé par Alan Cox (0x7EEBC095B516BAEF), et l’attaquant recrée cette chaîne avec un faux Torvald (0x6211AA3B00411886, même short-ID 0x00411886) signé par un faux Cox (0xD8C912C0B516BAEF, même short-ID 0xB516BAEF).
Et ceci sur des centaines de clefs reliées les unes aux autres.

Tu peux donc te faire doublement avoir maintenant :

• si tu t’arrêtes sur la comparaison du short-ID
  


• si tu vérifies en plus la chaîne de confiance
  
  Bref, short-ID c’est cassé (depuis 2011) et on passe aux long-ID (16 octets) voire aux empreintes complètes (40 octets).
  
  Cryptographiquement parlant, il n’y a donc rien de neuf. Mais là, ça montre une réelle volontée de nuire (mirrorer des centaines de signatures comme ça, ça demande une puissance de calcul relativement importante).

Le 22/08/2016 à 15h 14

J’ai ajouté des couleurs histoire de pouvoir distinguer les clefs collisionnées (même short-ID = même couleur (mais la réciproque est fausse :P))

Le 22/08/2016 à 14h 28

Oui, sinon tu passes à côté du vrai problème :P Le short-id tout seul est connu depuis des lustres.

Le 22/08/2016 à 13h 40

linconnu a écrit :

C’est le problème du libre ça. Comme le source est disponible les failles sont visibles facilement.
En gros c’est comme si une banque installait un super système de sécurité mais laissait les plans sur internet.
N’importe qui qui travaille dans la sécurité sait que le secret est primordial.
Donc il ne faut jamais utiliser du libre quand on veut faire de la sécurité à cause du manque de secret, ce qui s’applique à la vie réelle s’applique aussi à l’informatique.


Dans le monde privateur, cette faille n’aurait jamais été détectée, faute de relecteur/auditeur.
Et jamais publiée si elle l’avait quand même été.
Et sûrement jamais patchée si elle n’avait pas été publiée.

 Ça n’aurait pas empéché les petits malins de s’en servir.
 Les failles 0-days, c’est bien connu que ça n’existe pas…

Le 10/06/2016 à 20h 21

D’un autre côté, rien ne t’empêche de monter plusieurs machines virtuelles (ou prochainement raspi/olimex/pine64), avec un Cozy pour chaque utilisateur. Techniquement, ça ne pose aucun soucis.
LXC me semble tout indiqué pour gérer ça, mais effectivement, ce n’est pas forcément à la portée du 1er venu et il faut maîtriser un peu la ligne de commande :P

C’est même presque l’idéal, le jour où tes mioches quittent le cocon familial (ou ton·a conjoint·e :P), tu leurs rends leurs données !

Le 10/06/2016 à 10h 51

> Que ca sorte ou non ,ca reviendrait presque à lier ton compte avec tel ou tel entreprise

Toute la stack étant libre, tu peux monter ton instance chez toi dans tous les cas.
 Ou sortir de chez ton hébergeur quand tu le souhaites.

Le 10/06/2016 à 08h 45

C’est pour ça que Cozy te permet l’auto-hébergement, et bientôt de tourner sur Raspi et autres cartes équivalentes. Au pied de ton lit !

Le 10/06/2016 à 07h 59

Ça va même encore plus loin.
Rien ne sort du Cozy. Tout est calculé en local et EDF n’aura jamais accès aux données NEST par exemple.
Ça permet à EDF de fournir au propriétaire du Cozy des services qu’il n’aura pas pu avoir autrement.

Le 12/04/2016 à 18h 52

Novakin a écrit :

Ça ne mange pas de pain de générer un certificat 4096 bits et de virer les ciphers les moins sécurisés.


Surtout 3DES qui est déprécié depuis un bail… Et les suites non PFS qui ne changent rien à la compatibilité mais ajoute de la non sécurité