Projet Caliop : pour Laurent Chemla « le fondamental, c’est la cryptographie »

Interview de l'auteur de « Confessions d'un voleur : Internet, la liberté confisquée »

Le 22 août 2013 à 07h15

6 min

Logiciel

Hier, Laurent Chemla a annoncé qu'il relançait le « projet Caliop », dans l'espoir de fournir à tout un chacun une plateforme de courrier électronique à même de garantir la confidentialité des communications. L'informaticien, auteur de « Confessions d'un voleur : Internet, la liberté confisquée » et co-fondateur de Gandi, a accepté de répondre aux questions de PC INpact.

Laurent Chemla, en 2009 - CC BY-NC 2.0 -chezyann

Qu'est-ce que le « projet Caliop » ?

L'idée, avant que Gmail n'arrive, c'était de se dire qu'il fallait un système de mail un peu plus transparent pour l'utilisateur. À l'époque, on se posait déjà des questions sur les garanties que pouvaient apporter les fournisseurs d'accès à la confidentialité des courriers électroniques. On avait donc lancé ce projet avec des amis il y a une dizaine d'années.

Aujourd'hui, entre les révélations sur Prism et la prise de conscience des gens, je perçois autour de moi un nouveau besoin. Du coup, je relance ce projet qui, au départ, est un projet technique : comment faire en sorte que le mail soit à la fois pérenne, facile d'accès, le plus sécurisé possible - même si on ne pourra jamais sans doute le sécuriser totalement, etc.

Quelles sont vos pistes à l'heure actuelle ?

J'en ai beaucoup ! Maintenant, je me dis que certaines des idées qu'on avait il y a neuf ans doivent être remises au goût du jour. C'est la raison de cet appel : je ne vais pas faire ça tout seul dans mon coin, donc si vous avez des idées, donnez-les ; si vous voulez discuter des miennes, discutons-en et voyons comment on va faire !

Le fondamental, c'est la cryptographie - même si ça ne résout pas toujours tout. Il va y avoir des couches et des surcouches. Par exemple, je pense que même si on n'est pas capables de systématiquement garantir qu'un email n'ait pas été intercepté, on peut indiquer à l'utilisateur quel degré de confidentialité l'on peut garantir pour tel ou tel mail. Ainsi, un mail qui n'aura transité que par Caliop de façon totalement chiffrée de bout en bout entre l'émetteur et le récepteur, l'on pourra l'afficher un degré de sécurité proche de 100 %, alors qu'un mail qu'on aura reçu depuis Gmail sera affecté d'un degré de sécurité bien moindre.

Ce genre de choses permet déjà de garantir pas mal de confidentialité aux gens. J'ai l'impression que le mail, c'est un des seuls trucs qui n'a pas évolué sur Internet depuis 15 ans. Il est peut-être temps de le re-réfléchir aujourd'hui, de repartir de zéro et de retrouver des bases un peu plus sécuritaires.

Comment ce nouveau système pourrait-il échapper à la surveillance potentielle de différentes agences gouvernementales (NSA,...) ?

À partir du moment où c'est l'utilisateur qui a la clé de sa cryptographie, même si la NSA venait saisir tous nos serveurs, elle ne pourrait rien en faire car il lui faudrait les clés des clients. Pour que les clients aient leurs propres clés, il existe déjà des solutions. On pourrait par exemple envisager de distribuer des clés USB qui, en fonction de votre OS, vont vous permettre de créer votre clé privée et de chiffrer tout ce qui viendra de votre ordinateur. Vous, vous vous baladez avec votre clé. Nous, on stocke uniquement du mail chiffré, lequel arrive directement sur nos serveurs. Face à ça, la NSA ne pourra rien en faire.

Au-delà de ça, je remarque qu'en France, toute interception de communication privée est interdite par la loi. Le fait d'être sur un territoire national sur lequel la législation garantit la confidentialité des communications privées permet aussi de s'affranchir d'un certain nombre de choses dans la mesure où l'on ne peut pas nous-même enfreindre la loi, y compris à la demande du gouvernement. Sauf s'il y a des commissions rogatoires ou des volontés judiciaires pour en arriver-là. Mais là, ça signifie qu'il n'y a pas de surveillance, juste des enquêtes de police et des demandes qui sont traitées au cas par cas par les tribunaux.

Justement, comment l'hébergeur de ce service réagirait-il si jamais une autorité gouvernementale lui demandait des comptes, par exemple dans le cadre d'une enquête ?

Nous nous y plierions peut-être dans le cadre d'une enquête de justice, à la demande de la justice. Si c'est l’État qui nous le demande, nous n'avons absolument rien à lui répondre. Si c'est la justice, on peut lui fournir ce que l'on a en fonction des commissions rogatoires et de ce que le juge décide.

Avez-vous également des pistes s'agissant du modèle économique sur lequel pourrait se baser Caliop ?

J'aimerais qu'on puisse offrir un service dont une partie sera proposée aux entreprises et aux professionnels qui le voudront. C'est cette partie professionnelle et commerciale qui paiera pour la partie grand public, qui sera quant à elle gratuite. C'est un modèle pas tout à fait « freemium », mais presque. On va sans doute s'orienter vers quelque chose comme ça.

De toute façon, on va avoir pour commencer le soutien de Gandi [bureau d'enregistrement de noms de domaine et hébergeur français, ndlr], qui est d'accord pour nous prêter une infrastructure et des ressources humaines afin de démarrer le projet. On développera sans doute ce type d'activité économique, dans la mesure où eux proposeront ça en service payant à leur propres clients, pendant que Caliop offrira un service gratuit à ceux qui n'ont pas besoin de services à valeur ajoutée (envoi de mail en marque blanche pour leur entreprise,...).

Concrètement, qu'attendez-vous désormais des internautes ?

Aujourd'hui, c'est vraiment un appel à idées qui est lancé. Ça fait des années que j'y réfléchi, donc on a déjà un peu avancé sur tout ça... Mais je me dis que si moi j'ai plein d'idées, à 30, 40 ou 50, on aura des milliers d'idées et que l'on pourra pour le coup faire quelque chose de vraiment chouette !

Pour l'instant, on a ouvert la mailing list (voir ici). On va voir ! Je vais essayer d'ici lundi de faire un résumé de mes idées sur ce projet, qui seront ensuite à la discussion de tous. Rien n'est figé pour le moment. Ensemble, on va essayer de redéfinir ce projet en partant de zéro, et même si j'ai toutes les propositions, on va les discuter. S'il y a des gens qui veulent participer, ils sont les bienvenus sur la liste. On va s'efforcer de développer le projet le plus possible avant de l'écrire. J'espère qu'on ouvrira quelque chose d'ici la fin de l'année, même si ce n'est pas fini, que ce n'est qu'à l'état d'embryon.

Merci Laurent Chemla.

Commentaires (144)

Commentaire_supprime

Le 22/08/2013 à 07h31

Intéressant !

J’avoue qu’une sécurisation des courriels ne serait pas inintéressante. Et si ça permettait, ce qui est mon dada, d’avoir une gestion par whitelist intelligente (par exemple, avec un sas de décompression qui permettrait de whitelister au cas par cas des expéditeurs, entre autres en fonction du degré de sécurisation du courriel), ça serait un gros plus.

Effectivement, les services courriels d’aujourd’hui ne font guère plus que ce que j’avais avec Wanadoo quand j’ai eu ma première connexion internet en 1997… A suivre !

linkin623 Abonné

Le 22/08/2013 à 07h37

Nous nous y plierions peut-être dans le cadre d’une enquête de justice, à la demande de la justice. Si c’est l’État qui nous le demande, nous n’avons absolument rien à lui répondre. Si c’est la justice, on peut lui fournir ce que l’on a en fonction des commissions rogatoires et de ce que le juge décide.

Mais, mais, cet homme est sensé?! Je suis choqué de voir quelqu’un respecter la Justice et dire d’aller de faire " /> aux services de l’Etat. " />

Sylver---

Le 22/08/2013 à 07h40

Intéressant. Et il y’a clairement du business à faire sur la sécurité des communications/vie privrée !

anonyme_97254becd5c5b064755d6772703ed968

Le 22/08/2013 à 07h41

1 - je n’ai pas lu la news (en entier)

Mais …

On sait que smtp est un protocole “trop” ouvert , on sait qu’ tcp/ip est TOTALEMENT insecure : alors comment bâtir, élaborer quelques choses respectant le privatif et étant sécurisé ?

C’est quasi impossible.

Sans vouloir offenser laurent.

Et pourtant … Personnellement je prépare des surprises pour les mailer et autres vendeurs de liste email.

Il y aura du pénal et+ si affinité : marre d’avoir 90% de mon courriel fait de pub, démarchage, spam, attaque.

Perso. une deuxième partie de la réponse à PRISM …

(car pour moi ca fait pas mal d’année que je considère une box ou autre matos grand public comme un “blackhole sun”, donc c dehors : j’ai mon parefeu qui “protège” ma famille)

… ce sera une bascule du (des ?) poste perso sur du full gnu/linux, là ou TOUT le code peut être auditer par tous : c un gage de transparence donc de sécurité !

Et bien sure les services online, dropbox et autres merderies (on y penses même pas) : on va heberger sur du synology (nas) le seul accès pouvant être SSH , mais la encore pas glop, mais c moins pire.

Yutani

Le 22/08/2013 à 07h45

je ne connaissais pas ce projet, je me coucherais moins con ce soir !

bon courage pour le développement " />

Commentaire_supprime

Le 22/08/2013 à 07h51

ledufakademy a écrit :

1 - je n’ai pas lu la news (en entier)

Mais …

On sait que smtp est un protocole “trop” ouvert , on sait qu’ tcp/ip est TOTALEMENT insecure : alors comment bâtir, élaborer quelques choses respectant le privatif et étant sécurisé ?

Monsieur Chemla propose de rajouter un couche de chiffrement aux protocoles actuels comme base de travail d’après ce que j’ai compris. Mais ce serait un pis-aller, comme il le signale lui-même.

Effectivement, faire ab initio un nouveau protocole mail orienté sécurité, ça serait le plus pertinent. Mais ça poserait la question de la compatibilité ou des passerelles avec l’existant…

Sinon, pour ton problème de spam, j’ai eu le même et j’ai souscrit à l’offre mail de 1and1 parce que c’est la seule, pour un coût modique (15 € TTC/an) qui permet d’avoir une fonction whitelist sur ton inbox. Va comprendre pourquoi TOUS les autres ne le proposent pas…

nlougne

Le 22/08/2013 à 07h52

Motiver le gars :) Allez hop go m’inscrire et proposer un truc même si c’est con " />

Yutani

Le 22/08/2013 à 07h53

Commentaire_supprime a écrit :

Monsieur Chemla propose de rajouter un couche de chiffrement aux protocoles actuels comme base de travail d’après ce que j’ai compris. Mais ce serait un pis-aller, comme il le signale lui-même.

Effectivement, faire ab initio un nouveau protocole mail orienté sécurité, ça serait le plus pertinent. Mais ça poserait la question de la compatibilité ou des passerelles avec l’existant…

Sinon, pour ton problème de spam, j’ai eu le même et j’ai souscrit à l’offre mail de 1and1 parce que c’est la seule, pour un coût modique (15 € TTC/an) qui permet d’avoir une fonction whitelist sur ton inbox. Va comprendre pourquoi TOUS les autres ne le proposent pas…

parce que ça leur ferait du boulot supplémentaire et ça, c’est comme si on invoquait le diable " />

" />

Nnexxus

Le 22/08/2013 à 08h00

ledufakademy a écrit :

On sait que smtp est un protocole “trop” ouvert , on sait qu’ tcp/ip est TOTALEMENT insecure : alors comment bâtir, élaborer quelques choses respectant le privatif et étant sécurisé ?

Je suis loin d’être un expert, mais si tout le chiffrement est fait côté client ça devrait marcher, non ? Que la correspondance soit interceptée en route à cause d’une faille du protocole n’est pas gênant, puisque celui qui intercepte ne récupère que du charabia.

C’est bien sûr en supposant que le chiffrage est suffisamment fort, et le traffic global suffisamment important, pour empêcher la NSA de tout déchiffrer en un temps raisonnable.

Quant à ta remarque sur l’Open-Source : sur le fond je suis tout à fait d’accord avec toi, l’open-source est forcément plus sécurisé car auditable. Mais ce n’est pas la panacée pour autant : même OpenBSD, OS de paranoïaque s’il en est, s’est traîné une backdoor américaine pendant pas mal d’années avant qu’un contributeur ne s’en aperçoive. Le risque avec l’open-source, c’est finalement que n’importe qui (même mal intentionné) peut contribuer du code, et si le développeur qui accepte la contribution ne voit pas le piège (c’est parfois très bien caché !) la faille peut rester dans le code très longtemps.

Titizebioutifoul

Le 22/08/2013 à 08h05

Ce qui me pose souci avec ce genre de projet c’est que ce qui intéresse la NSA n’est pas tant le contenu de l’email (avec PGP on sait déjà crypté) que les méta-données (càd qui envoie un email à qui depuis quelle IP etc). Et ça, je ne sais pas bien comment on pourrait éviter d’avoir ces infos présentes dans un email…

psn00ps

Le 22/08/2013 à 08h06

ledufakademy a écrit :

1 - je n’ai pas lu la news (en entier)

" />" /> go B4 " /> " />

Esod Abonné

Le 22/08/2013 à 08h07

Très bonne idée ce projet ! Et même en temps que particulier, je suis prêt à payer (entre 15€ et 30€/an) pour avoir un tel service =)

Chrisrc01

Le 22/08/2013 à 08h09

Heureusement qu’il y a les “mathématiques” matière que beaucoup de personnes n’aiment pas mais qui pourrait au moins nous permettre d’atténuer les effets de la dictature qui se met lentement en place

ganjo

Le 22/08/2013 à 08h13

Je suis assez peu convaincu en fait, il faut que le correspondant sécurisé également son système pour qu’il y ait une quelconque efficacité…

je me demande si la solution ne serait pas de travailler sur des protos nouveaux, voir des proxy smtp/bitmessage

cyrano2

Le 22/08/2013 à 08h15

http://camlistore.org/ pourrait être un bon point de départ pour partager des informations. Une couche de cryptographie est entrain d’être ajouté.

Parfois, l’intérêt est l’anonymat et non que les informations soient privés. Je pense à tous les lanceurs d’alerte ou aux opposants politiques. De plus, ce genre de système serait plus facilement contrôlable par les fournisseurs de service. OVH a mis le hola sur TOR à cause de problème avec la justice concernant la pédophilie. Il serait plus cool avec un service ou il peut vérifier les fichiers, mais pas l’identité des personnes.

Si il pouvait faire un système P2P au moins en partie, cela raccourcirait les trajets faits par les informations. Il me semble d’ailleurs que des navigateurs web essayent de gérer le protocole bittorrent en natif. Cela pourrait peut être aider.

vermi Abonné

Le 22/08/2013 à 08h18

Le projet commence plutôt mal, je m’inscris à la mailing-list en entrant un mot de passe. Je reçois ensuite un mail :

“Meci pour votre inscription, votre mot de passe est : xxxxx”. Merci de m’envoyer mon mot de passe en clair par mail, bien joué !

Idée n°1 : Sécuriser la mailing-list du projet.

Vellou

Le 22/08/2013 à 08h29

Nnexxus a écrit :

Je suis loin d’être un expert, mais si tout le chiffrement est fait côté client ça devrait marcher, non ? Que la correspondance soit interceptée en route à cause d’une faille du protocole n’est pas gênant, puisque celui qui intercepte ne récupère que du charabia.

C’est bien sûr en supposant que le chiffrage est suffisamment fort, et le traffic global suffisamment important, pour empêcher la NSA de tout déchiffrer en un temps raisonnable.

Quant à ta remarque sur l’Open-Source : sur le fond je suis tout à fait d’accord avec toi, l’open-source est forcément plus sécurisé car auditable. Mais ce n’est pas la panacée pour autant : même OpenBSD, OS de paranoïaque s’il en est, s’est traîné une backdoor américaine pendant pas mal d’années avant qu’un contributeur ne s’en aperçoive. Le risque avec l’open-source, c’est finalement que n’importe qui (même mal intentionné) peut contribuer du code, et si le développeur qui accepte la contribution ne voit pas le piège (c’est parfois très bien caché !) la faille peut rester dans le code très longtemps.

Je ne suis pas d’accord sur un point : le chiffrement cote client pose toujours le probleme des serveurs relais et compagnie qui conservent une copie du mail.

Le jour ou une faille est trouvee dans le moyen de chiffrement, et qu’on peut dechiffrer sans probleme les emails qui ont transite … alors le probleme devient similaire a celui d’aujourd’hui.

Si en revanche le protocole de communication est securise et aneanti le principe des serveurs de cache et autres copies sauvages de nos emails, qu’en plus on chiffre cote client … on devrait etre tranquille durant quelques annees.

Le protocole SMTP actuel me semble totalement inadapte pour cette utilisation.

AlbertSY

Le 22/08/2013 à 08h40

Chiffré ou pas, ce n’est pas ce qui pose problème à la NSA.

Tout ce que la NSA a besoin, c’est avoir accès aux données.

Ils n’ont jamais demandés les mots de passes de qui que ce soit.

Que les données soient chiffrées, cryptées, hashées, mixées, qu’importe, ce n’est pas une barrière pour eux du moment que ce soit fait avec un algorithme légal (c’est ça le truc, si vous savez ce qu’est un algorithme* légal, vous saurez pourquoi ils n’ont pas besoins de votre mdp en clair). " />

* : D’après vous, qui valide et “légalise” les algorithmes (SHA5, AES1024 et compagnies) ? (Wikipedia est ton ami).

smnr

Le 22/08/2013 à 08h40

Mouais pas convaincant le mec quand même.

On va se pencher sur la question avec quelques amis au cours de cette année, je vous tiendrai au courant. " />

uzak

Le 22/08/2013 à 08h41

vermi a écrit :

Le projet commence plutôt mal, je m’inscris à la mailing-list en entrant un mot de passe. Je reçois ensuite un mail :

“Meci pour votre inscription, votre mot de passe est : xxxxx”. Merci de m’envoyer mon mot de passe en clair par mail, bien joué !

Idée n°1 : Sécuriser la mailing-list du projet.

" /> " />

uzak

Le 22/08/2013 à 08h44

Vellou a écrit :

Je ne suis pas d’accord sur un point : le chiffrement cote client pose toujours le probleme des serveurs relais et compagnie qui conservent une copie du mail.

Le jour ou une faille est trouvee dans le moyen de chiffrement, et qu’on peut dechiffrer sans probleme les emails qui ont transite … alors le probleme devient similaire a celui d’aujourd’hui.

Si en revanche le protocole de communication est securise et aneanti le principe des serveurs de cache et autres copies sauvages de nos emails, qu’en plus on chiffre cote client … on devrait etre tranquille durant quelques annees.

Le protocole SMTP actuel me semble totalement inadapte pour cette utilisation.

En effet, il faudrait un autre protocole, peut-être décentralisé, et une (plusieurs) passerelle vers/depuis SMTP (qui anonymiserait plus ou moins en perdant la corrélation adresse email/adresse IP)

Vellou

Le 22/08/2013 à 08h48

uzak a écrit :

En effet, il faudrait un autre protocole, peut-être décentralisé, et une (plusieurs) passerelle vers/depuis SMTP (qui anonymiserait plus ou moins en perdant la corrélation adresse email/adresse IP)

Pour tous les protocoles a venir, je pense qu’il faut de toutes manieres decentraliser … pour palier aux problemes de peering et de filtrage trop facilite.

Je pense que l’adresse email est elle aussi a repenser (plus sur son utilisation dans le protocole que sa forme).

Mais bon, je suis loin d’etre assez cale pour pouvoir pousser la reflexion plus loin " />

uzak

Le 22/08/2013 à 08h50

AlbertSY a écrit :

Chiffré ou pas, ce n’est pas ce qui pose problème à la NSA.

Tout ce que la NSA a besoin, c’est avoir accès aux données.

Ils n’ont jamais demandés les mots de passes de qui que ce soit.

Que les données soient chiffrées, cryptées, hashées, mixées, qu’importe, ce n’est pas une barrière pour eux du moment que ce soit fait avec un algorithme légal (c’est ça le truc, si vous savez ce qu’est un algorithme* légal, vous saurez pourquoi ils n’ont pas besoins de votre mdp en clair). " />

* : D’après vous, qui valide et “légalise” les algorithmes (SHA5, AES1024 et compagnies) ? (Wikipedia est ton ami).

Non….

La NSA recommande cet algo pour chiffrer leur propres données. Si il y avait un moyen de déchiffrer sans clé, même connu d’eux seuls, ils seraient pas assez cons pour l’utiliser.

lateo

Le 22/08/2013 à 08h53

Commentaire_supprime a écrit :

Sinon, pour ton problème de spam, j’ai eu le même et j’ai souscrit à l’offre mail de 1and1 parce que c’est la seule, pour un coût modique (15 € TTC/an) qui permet d’avoir une fonction whitelist sur ton inbox. Va comprendre pourquoi TOUS les autres ne le proposent pas…

Chez o2switch tu as le contrôle de spamassassin, avec filtres personnalisés, liste blanche et liste noire.

Et si tu es plutôt “extrême“ tu peux utiliser Boxtrapper (toute personne ne figurant pas dans ton carnet d’adresse et qui ne confirme pas son adresse mail ne peut pas t’envoyer de message). " />

Ingénieur informaticien

Le 22/08/2013 à 08h53

Il faut du décentralisé pour contrer les analyses de metadonnées.

C’est le minimum.

Le FBI vient d’infiltrer TOR, pourtant chiffré, en exploitant la centralisation des sites.

Les infrastructures de type P2P sont donc indispensables.

D’ailleurs ça existe déjà, avec le système de mail de Freenet : Freemail.

Je ne l’ai pas testé par contre.

Le 22/08/2013 à 11h49

uzak a écrit :

DSK s’est fait piégé par la NSA " />

Va savoir s’ils n’ont pas utilisé son coté queutard? Par exemple pour le mettre la l’écart du FMI avec ses sombres idées de monnaie mondiale (a la place du $)… et y placer une potiche qui avait fait allégeance, phraséologie SM incluse (“utilises moi…”), à “Sarko l’américain”

Le 22/08/2013 à 11h50

uzak a écrit :

Plus sérieusement, faut faire confiance aux repositories debian pour avoir un exé propre.

Je sais pas si il y a des moyens de vérifier que le compilateur n’est pas vérolé. Ça a forcément été exploré cette piste. Je m’en rappelle même l’avoir entendue évoquée en cours…

http://cm.bell-labs.com/who/ken/trust.html

smnr

Le 22/08/2013 à 11h52

Ricard a écrit :

On est là dans la téléphonie, pas sur le ternet. Mais oui, dans ce cas là. Cependant, cela ne tiens pas pour autant dans le cas d’une preuve. La fuite et le journaliste peuvent très bien avoir eu un contact qui n’a rien donné. Et dans le cas des fadettes, c’était illégal puisque contraire à la loi de la protection des sources.

Là, on est clairement plus dans la surveillance des réseaux, mais bel et bien dans un film de Xavier Berne Jason Bourne." />

Surtout que les dirigeants dont il parle bénéficient de la protection nécessaire des services de contre-espionnage. Les français ont appris à le faire à leur dépens. " />

cyrano2

Le 22/08/2013 à 11h53

linkin623 a écrit :

" />

Un PC actuel ne peut faire cela en quelques heures, faut pas déconner.

pas toujours, mais dans une majorité des cas :

Ars Technica

uzak

Le 22/08/2013 à 12h05

yl a écrit :

http://cm.bell-labs.com/who/ken/trust.html

Dans l’os quoi !

dematbreizh Abonné

Le 22/08/2013 à 12h14

Titizebioutifoul a écrit :

Ce qui me pose souci avec ce genre de projet c’est que ce qui intéresse la NSA n’est pas tant le contenu de l’email (avec PGP on sait déjà crypté) que les méta-données (càd qui envoie un email à qui depuis quelle IP etc). Et ça, je ne sais pas bien comment on pourrait éviter d’avoir ces infos présentes dans un email…

passer par un compte tampon pour brouiller les infos?

ou un système comme les VPN?

Le 22/08/2013 à 12h34

uzak a écrit :

Dans l’os quoi !

Ou expertiser tout le code assemblé " />

Bon, y’a des possibilités de vérif par double compilation… mais ca reporte le pb, car il faut un compilateur sûr afin de comparer les binaires produits! Et en pratique sans doute un compilo sûr de même version (utilisé avec les mêmes options) que celui ayant servi à compiler le compilo dont l’intégrité est à vérifier: Un compilo produit toujours un code un peu différent selon les versions.

Bref, ca reste assez théorique et peu applicable en pratique. Sans doute fait pour du logiciel critique (souvent de taille limitée comparé à un OS et son applicatif) mais clairement pas dans les dépots Debian!

smnr

Le 22/08/2013 à 12h40

yl a écrit :

Ou expertiser tout le code assemblé " />

Bon, y’a des possibilités de vérif par double compilation… mais ca reporte le pb, car il faut un compilateur sûr afin de comparer les binaires produits! Et en pratique sans doute un compilo sûr de même version (utilisé avec les mêmes options) que celui ayant servi à compiler le compilo dont l’intégrité est à vérifier: Un compilo produit toujours un code un peu différent selon les versions.

Bref, ca reste assez théorique et peu applicable en pratique. Sans doute fait pour du logiciel critique (souvent de taille limitée comparé à un OS et son applicatif) mais clairement pas dans les dépots Debian!

On peut calculer la signature d’un binaire qui doit être produit, puis vérifier la signature avec ce que le compilateur produit effectivement.

Ingénieur informaticien

Le 22/08/2013 à 12h50

Et l’hypothèse d’un firewall “absolu” qui ne laisserait passer QUE ce qu’on autorise explicitement ?

smnr

Le 22/08/2013 à 13h07

Ingénieur informaticien a écrit :

Et l’hypothèse d’un firewall “absolu” qui ne laisserait passer QUE ce qu’on autorise explicitement ?

Cela existe déjà.

En sécurité informatique (c’est valable partout ailleurs je suppose), on s’attaque aux maillons les plus faibles, non pas aux plus forts.

Commentaire_supprime

Le 22/08/2013 à 13h08

Ricard a écrit :

Effectivement, la DGSE bluff aussi." />

Les tactiques de déception, dont la désinformation fait partie (le bluff en est une des formes), sont aussi vieilles que la notion même de service secret.

Et nous avons de jolis exemples de réussite de ce type d’opérations tout au long de l’histoire militaire.

anonyme_d315e4880a39b8868a0d848ecab05cac

Le 22/08/2013 à 13h22

Ricard a écrit :

Pour l’espionnage de masse qu’ils pratiquent, le chiffrement généralisé les ferait chier au plus haut point." />

100% d’accord avec ça !

Les meta données, ca va 5 minutes. Si Robert envoie un email à Georges pour dire qu’il va tout faire péter demain à 12h, les metadonnées ne serviront à rien !

L’email va évoluer et c’est très bien. Avec la fin de la confiance dans les Google/Apple/Microsoft/Yahoo, on va assister à de nouvelles alternatives. Un peu comme avec la fin de GReader.

C’est parfait !

Ricard

Le 22/08/2013 à 13h50

cyrano2 a écrit :

Ok, je vois que je suis tombé sur un champion du monde. Je détail comment casser un fichier crypté AES256 avec mot de passe d’humain, même si ily a eu déjà plusieurs articles sur le sujet (il suffit de chercher des infos sur l’outil hashcathttp://arstechnica.com/security/2013/03/how-i-became-a-password-cracker/ ).

La clef 256 bits d’un tel fichier provient d’un hash en général SHA256 du mot de passe. Un mot de passe à 8 caractères aléatoires soit en gros 70^8 combinaisons possible., soit ~2^49. C’est équivalent à une clef de 49 bits très loin des 100 bits nécessaire à une vrai protection contre les attaques brutes forces. Pour casser un tel message, il faut tester les 2^49 combinaisons, avec des machines qui tournent autour d’un milliard de hash à la seconde, cela peut aller assez vite.

Si on utilise seulement des mots du dictionnaires, on peut compter sur environ 2000 mot de vocabulaire, soit 2^12 mots. Pour approcher des 100 bits, il en faut donc ¹⁰⁰⁄₁₂ = 8.3, soit 9 mots.

Le champion du monde c’est toi là bonhomme. Déjà, confonfdre AES256 et SHA256, faut vraiment être con. Tu confonds le Hash et la clé. Bref… Retourne étudier un peu le sujet. Et si tu arrives à casser AES256, fais toi vite connaitre, tu seras mondialement célèbre." />

Ricard

Le 22/08/2013 à 13h55

damien_spirale a écrit :

100% d’accord avec ça !

Les meta données, ca va 5 minutes. Si Robert envoie un email à Georges pour dire qu’il va tout faire péter demain à 12h, les metadonnées ne serviront à rien !

L’email va évoluer et c’est très bien. Avec la fin de la confiance dans les Google/Apple/Microsoft/Yahoo, on va assister à de nouvelles alternatives. Un peu comme avec la fin de GReader.

C’est parfait !

" />

Je pense que plus d’une boite sensible va réfléchir à deux fois avant de balancer des infos sensibles par simple mail.

Le_Cha_po

Le 22/08/2013 à 14h18

cyrano2 a écrit :

La NSA s’en fout car, si il ne casse pas encore de l’AES128, il pourront le faire dans 5 ans. Et puis tout chiffrement AES même 256 bits à base de mot de passe est cassable en quelques heure sur un PC. Le nombre de mot de passe possible “humainement” est très largement en dessous de 100 bits d’entropie. Pour info, pour dépasser 100 bits, il faut 8(!) mot du langage courant. Qui fait cela ?

.

On peut imaginer un protocole transparent pour l’utilisateur (pas de mdp à rentrer) avec des chiffrage aussi gros que nécessaire générer (presque) aléatoirement non ?

anonyme_97254becd5c5b064755d6772703ed968

Le 22/08/2013 à 14h26

Commentaire_supprime a écrit :

Ben, faudrait que je puisse avoir un serveur mail chez moi, ce qui est un problème skiant avec la FTTH par le fruit et son absence d’IP fixe…

Mais à terme, j’y pense, merci à Synology pour la partie matérielle et logicielle qui va avec (faut que je pense à me payer un onduleur, cela dit en passant).

ben tu fais comme tout les geek : free.

ip fixe , bridge etc.

" />

linkin623 Abonné

Le 22/08/2013 à 09h49

Commentaire_supprime a écrit :

En fait, cela reposait sur un témoignage unique d’un dev qui, sans apporter de preuves tangibles basées sur des faits (en l’occurrence, un extrait du code litigieux avec un commentaire expliquant son fonctionnement), a prétendu que la backdoor existait.

Témoignage unique, témoignage inique, donc irrecevable. Un gros coup de FUD en d’autres termes.

" /> tu y vas fort mais en substance je me souvenais que ça n’avais pas tenu le coup cette histoire.

Commentaire_supprime

Le 22/08/2013 à 09h53

linkin623 a écrit :

" /> tu y vas fort mais en substance je me souvenais que ça n’avais pas tenu le coup cette histoire.

Un seul témoignage, pas de preuves matérielles et personne derrière pour confirmer, le soufflé s’est vite dégonflé une fois sorti du four.

Quand il y a du biscuit, tu as vite des gens qui viennent derrière pour confirmer la déclaration initiale une fois qu’elle est médiatisée, et qui confirment ou rajoutent souvent des preuves matérielles à l’appui. Là, rien.

linkin623 Abonné

Le 22/08/2013 à 09h57

Commentaire_supprime a écrit :

Un seul témoignage, pas de preuves matérielles et personne derrière pour confirmer, le soufflé s’est vite dégonflé une fois sorti du four.

Quand il y a du biscuit, tu as vite des gens qui viennent derrière pour confirmer la déclaration initiale une fois qu’elle est médiatisée, et qui confirment ou rajoutent souvent des preuves matérielles à l’appui. Là, rien.

" /> maintenant

Blague à part, +1

cyrano2

Le 22/08/2013 à 10h00

AlbertSY a écrit :

Que les données soient chiffrées, cryptées, hashées, mixées, qu’importe, ce n’est pas une barrière pour eux du moment que ce soit fait avec un algorithme légal

ça c’est totalement faux. Il y a plein de source sur le sujet.

La NSA s’en fout car, si il ne casse pas encore de l’AES128, il pourront le faire dans 5 ans. Et puis tout chiffrement AES même 256 bits à base de mot de passe est cassable en quelques heure sur un PC. Le nombre de mot de passe possible “humainement” est très largement en dessous de 100 bits d’entropie. Pour info, pour dépasser 100 bits, il faut 8(!) mot du langage courant. Qui fait cela ?

A quoi sert de péter du HTTPS, quand il suffit de se servir chez Google, Facebook ou autre ? Souvent il suffit d’aller regarder d’un coté du tuyau, c’est assez facile à priori (d’après Snowden).

Ricard

Le 22/08/2013 à 10h01

Commentaire_supprime a écrit :

Intéressant !

J’avoue qu’une sécurisation des courriels ne serait pas inintéressante. Et si ça permettait, ce qui est mon dada, d’avoir une gestion par whitelist intelligente (par exemple, avec un sas de décompression qui permettrait de whitelister au cas par cas des expéditeurs, entre autres en fonction du degré de sécurisation du courriel), ça serait un gros plus.

Thunderbird ne fait pas déjà ça dans les filtres ?

Ricard

Le 22/08/2013 à 10h04

ledufakademy a écrit :

1 - je n’ai pas lu la news (en entier)

Mais …

On sait que smtp est un protocole “trop” ouvert , on sait qu’ tcp/ip est TOTALEMENT insecure : alors comment bâtir, élaborer quelques choses respectant le privatif et étant sécurisé ?

C’est quasi impossible.

Sans vouloir offenser laurent.

Le problème, c’est pas la sécurité du protocole d’échange, c’est la sécurisation des données.

Ricard

Le 22/08/2013 à 10h12

Nnexxus a écrit :

même OpenBSD, OS de paranoïaque s’il en est, s’est traîné une backdoor américaine pendant pas mal d’années avant qu’un contributeur ne s’en aperçoive.

Faux. C’est démenti depuis très longtemps, après plusieurs audits. OpenBSD est l’OS connu le plus sécurisé à ce jour." />

Commentaire_supprime

Le 22/08/2013 à 10h13

Ricard a écrit :

Thunderbird ne fait pas déjà ça dans les filtres ?

Si, mais je préférerais largement gérer cela en amont, au niveau du serveur, avant réception et récupération du courrier par le(s) client(s). D’autant plus que j’ai mes courriels sur mon smartphone en direct, par exemple.

Ricard

Le 22/08/2013 à 10h16

Commentaire_supprime a écrit :

Si, mais je préférerais largement gérer cela en amont, au niveau du serveur, avant réception et récupération du courrier par le(s) client(s). D’autant plus que j’ai mes courriels sur mon smartphone en direct, par exemple.

Sieve avec Dovecot ?" />

uzak

Le 22/08/2013 à 10h17

Ingénieur informaticien a écrit :

Dans l’open source, la faille peut venir du compilateur non ?

Yep !

Et contre ça, le compilateur est open source !

Mais avec quoi tu le compiles ton compilateur open source ?

Commentaire_supprime

Le 22/08/2013 à 10h18

Ricard a écrit :

Faux. C’est démenti depuis très longtemps, après plusieurs audits. OpenBSD est l’OS connu le plus sécurisé à ce jour." />

Et puis, c’est un peu gros. Open BSD, comme son nom l’indique, a son code public dans le sens où tous ceux qui veulent y jeter un coup d’oeil peuvent y aller franco sans se gêner.

Et au bout de plusieurs années d’existence de l’OS, UN SEUL développeur crie au loup en disant qu’il y a une backdoor que personne n’avait vu avant lui, sur plusieurs années, et qu’il a été le seul à voir… " />" />" />" />" />

Après, comme ce monsieur n’a pas montré le moindre code commenté à l’appui de ses dires, et que personne n’a confirmé sa déclaration, surtout après des audits supplémentaires du code fait postérieurement à sa déclaration, ben… Comme théorie de la conspiration, il en a pondu une belle, ledit monsieur…

Commentaire_supprime

Le 22/08/2013 à 10h19

Ricard a écrit :

Sieve avec Dovecot ?" />

Ben, faudrait que je puisse avoir un serveur mail chez moi, ce qui est un problème skiant avec la FTTH par le fruit et son absence d’IP fixe…

Mais à terme, j’y pense, merci à Synology pour la partie matérielle et logicielle qui va avec (faut que je pense à me payer un onduleur, cela dit en passant).

Ingénieur informaticien

Le 22/08/2013 à 10h21

uzak a écrit :

Yep !

Et contre ça, le compilateur est open source !

Mais avec quoi tu le compiles ton compilateur open source ?

Y’a plus qu’à coder le compilateur en langage machine directement.

Même l’assembleur peut-être suspecté !

Ricard

Le 22/08/2013 à 10h22

Titizebioutifoul a écrit :

Ce qui me pose souci avec ce genre de projet c’est que ce qui intéresse la NSA n’est pas tant le contenu de l’email (avec PGP on sait déjà crypté) que les méta-données (càd qui envoie un email à qui depuis quelle IP etc). Et ça, je ne sais pas bien comment on pourrait éviter d’avoir ces infos présentes dans un email…

Faut arrêter de croire la NSA aussi. Ce qui les interesse, c’est aussi (et surtout) le contenu du mail. Faire gober que les meta-données c’est suffisant, c’est faire croire aux gens que le chiffrement n’est pas nécassaire. Surtout pour l’espionnage industriel par exemple. Que Airbus communique avec un sous-traitant par mail, c’est pas un secret et il n’y a rien d’étonnat là dedans, par contre, le contenu du message est important.

Pour le terrorisme, oui, mais imaginons le cas d’un spammeur. Toutes les “victimes’” sont répertoriées et sensées avoir un lien avec le spammeur ? Bah… Du blah blah tout ça. Ce qui les interesse vraiment, c’est bien le contenu du mail, sauf pour les terroristes déjà ciblés. Pour l’espionnage de masse qu’ils pratiquent, le chiffrement généralisé les ferait chier au plus haut point." />

Ricard

Le 22/08/2013 à 10h24

Commentaire_supprime a écrit :

Ben, faudrait que je puisse avoir un serveur mail chez moi, ce qui est un problème skiant avec la FTTH par le fruit et son absence d’IP fixe…

Mais à terme, j’y pense, merci à Synology pour la partie matérielle et logicielle qui va avec (faut que je pense à me payer un onduleur, cela dit en passant).

Un raspberry pi, et c’est parti." />

Ricard

Le 22/08/2013 à 10h25

odoc a écrit :

Euh si je me souviens bien, cette histoire de backdoor était un fake non ? (un audit complet a été fait et rien n’a été trouvé)

" /> Toutafé. Le type à du passer pour un gros guignol en plus. " />

levhieu

Le 22/08/2013 à 15h14

Ricard, bonne remarque au sujet de l’interface chaise clavier. Mais le problème que soulève cyrano2, c’est que le quidam en cause fait une erreur parce qu’il a été mal conseillé. Si un logiciel dit au non-spécialiste “tapez un mot-de-passe et je vais tout chiffrer avec la super-force d’AES256”, le non-spécialiste est berné.

C’est ça que signale cyrano2, sans confusion de sa part, et avec des arguments solides.

uzak

Le 22/08/2013 à 15h16

smnr a écrit :

On peut calculer la signature d’un binaire qui doit être produit, puis vérifier la signature avec ce que le compilateur produit effectivement.

Et cela suppose d’avoir un binaire de référence produit par la même version du compilateur donc, les même options de compilation, et surtout un compilateur que l’on sait être non vérolé. Mais comment le sait-on pour celui-ci ?

Ingénieur informaticien

Le 22/08/2013 à 15h17

Faut être bête aussi pour utiliser toto comme mot de passe.

cyrano2

Le 22/08/2013 à 15h23

Ricard a écrit :

Le champion du monde c’est toi là bonhomme. Déjà, confonfdre AES256 et SHA256, faut vraiment être con. Tu confonds le Hash et la clé. Bref… Retourne étudier un peu le sujet. Et si tu arrives à casser AES256, fais toi vite connaitre, tu seras mondialement célèbre." />

La ou tu n’as rien compris, c’est que la clef utilisé pour crypté est choisi par un humain, qui les aimes courte. Il “suffit” de tester l’espace des clefs typiques d’un humains pour cracker le fichier. Cette espace de clef est bien plus petit que 128 bits.

C’est là tout l’astuce. " />

uzak

Le 22/08/2013 à 15h24

Kyuuzo a écrit :

Je rappel quand même qu’on peut stacker plusieurs algo d’encryption comme par exemple l’AES-Twofish-Serpent, ce qui permet au cas où un cassage de l’AES arrive un jour, d’être protégé puisque tous les ciphers doivent-être cassés avant que l’attaquant puisse accèder aux données.

Ça, faut faire attention.

En combinant les chiffrements, on peut obtenir un biais qui rendrait le chiffrement final plus vulnérable que les deux originaux stackés.

cyrano2

Le 22/08/2013 à 15h26

Ingénieur informaticien a écrit :

Faut être bête aussi pour utiliser toto comme mot de passe.

“TeAµT0!” se casse presque aussi vite (écriture en leet, donc 2 façons d’écrire le o avec 0 ou O, “µ” ou “u” pour u, “eau” à la place de “o”). Cela prend 5s au lieu d ‘une.

uzak

Le 22/08/2013 à 15h26

cyrano2 a écrit :

La ou tu n’as rien compris, c’est que la clef utilisé pour crypté est choisi par un humain, qui les aimes courte. Il “suffit” de tester l’espace des clefs typiques d’un humains pour cracker le fichier. Cette espace de clef est bien plus petit que 128 bits.

C’est là tout l’astuce. " />

Ben ça, c’est tous les chiffrements non ?

Et ça m’étonnerait que des saisies utilisateurs soient utilisées telle quelle comme clef de chiffrement, sans être passé par une moulinette avant…

cyrano2

Le 22/08/2013 à 15h28

uzak a écrit :

Ça, faut faire attention.

En combinant les chiffrements, on peut obtenir un biais qui rendrait le chiffrement final plus vulnérable que les deux originaux stackés.

Il faut absolument que les 2 clefs soit totalement aléatoires pour éviter les biais.

Mais bon 2 codages 128 prennent 2x le temps de cassage d’un 128 bits, soit 129 bits… (si on ne fait pas gaffe)

cyrano2

Le 22/08/2013 à 15h29

uzak a écrit :

Ben ça, c’est tous les chiffrements non ?

Non justement. Tu peux avoir une clef issue d’un générateur aléatoire crypté par clef privé (comme gpg). Tu peux aussi essayer de sauver cette clef aléatoire symétrique sur ton disque.

La différence entre une clef réellement aléatoire (attention au générateur pas crypto, certains n’ont que 32 bits d’état) et un mot de passe humain est énorme.

Et ça m’étonnerait que des saisies utilisateurs soient utilisées telle quelle comme clef de chiffrement, sans être passé par une moulinette avant…

La moulinette, c’est une fonction de hash. Sachant ça, relis mes postes :)

anonyme_97254becd5c5b064755d6772703ed968

Le 22/08/2013 à 15h33

Kyuuzo a écrit :

Tu crois ? Je sais pas, il est pas clair dans ces propos, surtout que le SHA256 est révolu depuis bien longtemps et qu’on utilise plus l’HMAC-SHA-512 maintenant.

En plus il n’y a pas de relation entre SHA et AES donc j’arrive pas à suivre son propos, la clé AES n’est pas contenue dans un hash, dans aucun cas.

Pour moi il est à pas tout compris à AES et se mélange les pinceaux sur ce coup.

Comme toujours en crypto, y’a ceux qui ont le vocabulaire .. et ceux qui savent ce que veut dire exactement :

authentifier, crypter, chiffrer, négocier …

… et mettre en oeuvre (sans passer par un gui à deux balles)

Cliquer sur “monter” un vpn c’est une chose … faire un “tail -f /var/log/secure” avec un debug en -vvv (sur openssh) en est une autre : la faut comprendre , tout.

Moi perso. j’y arrive , mais je dois réfléchir … au calme … un peu … quand même . Alors les discussions ici … à part un ou deux vous me faites marrer.

Ne parlons pas PKI car on rigole encore plus fort.

bises, car les discussion sont géantes ici.

doom_Oo7

Le 22/08/2013 à 15h34

Le problème, c’est que Mme Michu, elle lit cet article, elle se dit “ok, il faut que je crypte mes mails!”, puis à la radio un chroniqueur lambda dit “le cryptage des mails sert la cause des pédonazis qui violent vos enfants chéris” et Mme Michu va se dire : “il faut interdire le cryptage!”

uzak

Le 22/08/2013 à 15h38

cyrano2 a écrit :

Non justement. Tu peux avoir une clef issue d’un générateur aléatoire crypté par clef privé (comme gpg). Tu peux aussi essayer de sauver cette clef aléatoire symétrique sur ton disque.

La différence entre une clef réellement aléatoire (attention au générateur pas crypto, certains n’ont que 32 bits d’état) et un mot de passe humain est énorme.

La moulinette, c’est une fonction de hash. Sachant ça, relis mes postes :)

Ben si, le comment tu obtiens ta clé, c’est le protocole qui le dit, pas la fonction de chiffrement en elle même.

c’est pas pour ça qu’on introduit un sel dans les hash par hasard ?

Kyuuzo

Le 22/08/2013 à 15h39

cyrano2 a écrit :

HMAC, c’est pour les signatures

HMAC te sert a vérifier l’authenticité d’une signature certe, mais tu peux t’en servir en surcouche de SHA512, permettant d’avoir un double hachage.

Concernant ton histoire de mot de passe AES créé avec un hash, je ne vois absolument pas le problème, ton mot de passe+hash étant transformé par la suite par AES par croisement de tables matricielles, il faudrait que le hacker en question trouve et le bon mot et le bon hash, ce qui est fort peu probable sur 256bit.

N’ayant aucun des deux (mot et hash) en clair nul part il est obligé de bruteforce la totalité des 256bit. Ce n’est pas comme dans ton lien explicatif où le gars à accès au hash directement, dans le cas de l’AES le hash en question serrait crypté.

Bref j’arrive pas à suivre ton raisonnement, mais le problème peut venir de moi hein x)

uzak

Le 22/08/2013 à 15h40

ledufakademy a écrit :

Comme toujours en crypto, y’a ceux qui ont le vocabulaire .. et ceux qui savent ce que veut dire exactement :

…

Comme les frites McCain " />

Kyuuzo

Le 22/08/2013 à 15h46

ledufakademy a écrit :

Comme toujours en crypto, y’a ceux qui ont le vocabulaire .. et ceux qui savent ce que veut dire exactement :

authentifier, crypter, chiffrer, négocier …

… et mettre en oeuvre (sans passer par un gui à deux balles)

Cliquer sur “monter” un vpn c’est une chose … faire un “tail -f /var/log/secure” avec un debug en -vvv (sur openssh) en est une autre : la faut comprendre , tout.

Moi perso. j’y arrive , mais je dois réfléchir … au calme … un peu … quand même . Alors les discussions ici … à part un ou deux vous me faites marrer.

Ne parlons pas PKI car on rigole encore plus fort.

bises, car les discussion sont géantes ici.

Moi j’essaie de comprendre c’est pour ça que j’ai commencer mon poste par “Si je me trompe faut m’expliquer”, je ne cherche pas à étaler ma science. Juste comprendre pourquoi nos raisonnement diffèrent.

Après si tu veux faire des bisous c’est cool mais je suis pas la bonne personne ;)

Je ne dis pas qu’il a tort je dis que je ne comprend pas où il veut en venir et que son lien ne clarifie pas la chose.

Après si ça t’insupporte et que tu préfères bâcher plutôt que d’expliquer libre à toi… mais tu ne m’intéresse pas dans ce cas, log secure ou pas.

uzak

Le 22/08/2013 à 15h47

Kyuuzo a écrit :

HMAC te sert a vérifier l’authenticité d’une signature certe, mais tu peux t’en servir en surcouche de SHA512, permettant d’avoir un double hachage.

…

Ça aussi, c’est le mal !

naemo

Le 22/08/2013 à 09h03

Justement, comment l’hébergeur de ce service réagirait-il si jamais une autorité gouvernementale lui demandait des comptes, par exemple dans le cadre d’une enquête ?

Nous nous y plierions peut-être dans le cadre d’une enquête de justice, à la demande de la justice. Si c’est l’État qui nous le demande, nous n’avons absolument rien à lui répondre. Si c’est la justice, on peut lui fournir ce que l’on a en fonction des commissions rogatoires et de ce que le juge décide.

Quelle réponse de merde " />

ganjo

Le 22/08/2013 à 09h03

AlbertSY a écrit :

* : D’après vous, qui valide et “légalise” les algorithmes (SHA5, AES1024 et compagnies) ? (Wikipedia est ton ami).

En fait non, c’était le cas pour DES, dont de nombreux éléments sont restés longtemps obscur pour le grand public.

Actuellement cela passe par des concours, et une cross validation par différentes entités (agence étatique, mais aussi universitaire voir société privée). Ensuite si la NSA trouve une faille dans un des algos présentés au concours, rien ne les force à le révéler.

maestro321

Le 22/08/2013 à 09h05

Ingénieur informaticien a écrit :

Il faut du décentralisé pour contrer les analyses de metadonnées.

C’est le minimum.

Le FBI vient d’infiltrer TOR, pourtant chiffré, en exploitant la centralisation des sites.

Les infrastructures de type P2P sont donc indispensables.

D’ailleurs ça existe déjà, avec le système de mail de Freenet : Freemail.

Je ne l’ai pas testé par contre.

Heu… la faille (javascript) qu’à exploité le FBI viens de firefox pas de TOR.

smnr

Le 22/08/2013 à 09h06

naemo a écrit :

Quelle réponse de merde " />

Quoi, tu veux qu’ils enfreignent la loi ? " />

Ingénieur informaticien

Le 22/08/2013 à 09h06

AlbertSY a écrit :

si vous savez ce qu’est un algorithme* légal,

* : D’après vous, qui valide et “légalise” les algorithmes (SHA5, AES1024 et compagnies) ? (Wikipedia est ton ami).

Peux tu nous indiquer à quelle page Wikipedia tu fais référence STP ?

Ingénieur informaticien

Le 22/08/2013 à 09h08

maestro321 a écrit :

Heu… la faille (javascript) qu’à exploité le FBI viens de firefox pas de TOR.

Oui, mais …

Cette opération, qui a été détaillée sur le blog officiel de TOR, aurait ainsi permis de localiser le serveur basé aux États-Unis et géré par Verizon Business pour identifier Marques.

Ils auraient fait fermer 50% des sites .onion, d’après ce que j’avais lu quelque part … juste en ciblant l’hébergeur, d’où la faillibilité d’un système centralisé.

Commentaire_supprime

Le 22/08/2013 à 09h19

naemo a écrit :

Quelle réponse de merde " />

En quoi ?

Répondre à une commission rogatoire ou son équivalent, c’est une obligation légale dans tout état de droit, et ne pas le faire s’appelle de l’entrave à la justice.

Après, dire amen à toutes les demandes de n’importe quel ministère portant sur n’importe quoi, comme ça, de la main à la main, c’est illégal. Un service de l’Etat ne peut demander quelque chose à quelqu’un que si la loi le lui permet. En dehors de cela, c’est passer par la case justice ou niet en toute légalité.

lysbleu

Le 22/08/2013 à 09h30

Nnexxus a écrit :

Je suis loin d’être un expert, mais si tout le chiffrement est fait côté client ça devrait marcher, non ? Que la correspondance soit interceptée en route à cause d’une faille du protocole n’est pas gênant, puisque celui qui intercepte ne récupère que du charabia.

C’est bien sûr en supposant que le chiffrage est suffisamment fort, et le traffic global suffisamment important, pour empêcher la NSA de tout déchiffrer en un temps raisonnable.

Quant à ta remarque sur l’Open-Source : sur le fond je suis tout à fait d’accord avec toi, l’open-source est forcément plus sécurisé car auditable. Mais ce n’est pas la panacée pour autant : même OpenBSD, OS de paranoïaque s’il en est, s’est traîné une backdoor américaine pendant pas mal d’années avant qu’un contributeur ne s’en aperçoive. Le risque avec l’open-source, c’est finalement que n’importe qui (même mal intentionné) peut contribuer du code, et si le développeur qui accepte la contribution ne voit pas le piège (c’est parfois très bien caché !) la faille peut rester dans le code très longtemps.

C’était pas un hoax ça ?

odoc

Le 22/08/2013 à 09h31

Nnexxus a écrit :

Je suis loin d’être un expert, mais si tout le chiffrement est fait côté client ça devrait marcher, non ? Que la correspondance soit interceptée en route à cause d’une faille du protocole n’est pas gênant, puisque celui qui intercepte ne récupère que du charabia.

C’est bien sûr en supposant que le chiffrage est suffisamment fort, et le traffic global suffisamment important, pour empêcher la NSA de tout déchiffrer en un temps raisonnable.

Quant à ta remarque sur l’Open-Source : sur le fond je suis tout à fait d’accord avec toi, l’open-source est forcément plus sécurisé car auditable. Mais ce n’est pas la panacée pour autant : même OpenBSD, OS de paranoïaque s’il en est, s’est traîné une backdoor américaine pendant pas mal d’années avant qu’un contributeur ne s’en aperçoive. Le risque avec l’open-source, c’est finalement que n’importe qui (même mal intentionné) peut contribuer du code, et si le développeur qui accepte la contribution ne voit pas le piège (c’est parfois très bien caché !) la faille peut rester dans le code très longtemps.

Euh si je me souviens bien, cette histoire de backdoor était un fake non ? (un audit complet a été fait et rien n’a été trouvé)

Nnexxus

Le 22/08/2013 à 09h33

C’est pas impossible, j’avoue avoir fait confiance à mon prof de sécurité informatique sur ce coup, sans aller vérifier les sources.

Il n’empêche que, hoax ou pas, le scénario est crédible.

linkin623 Abonné

Le 22/08/2013 à 09h34

Titizebioutifoul a écrit :

Ce qui me pose souci avec ce genre de projet c’est que ce qui intéresse la NSA n’est pas tant le contenu de l’email (avec PGP on sait déjà crypté) que les méta-données (càd qui envoie un email à qui depuis quelle IP etc). Et ça, je ne sais pas bien comment on pourrait éviter d’avoir ces infos présentes dans un email…

Certes, elle récupère ces infos. Mais elles ne sont qu’une première étape, puisque personne ne peut analyser tout le trafic. Mais si le contenu est illisible, l’information qu’à la NSA est bien mince, trop à mon goût mais peu utilisable.

Je pense juste à des journalistes qui eux ont besoin d’une anonymisation totale de leur correspondance ou d’autres personnes “sensibles”. Pour le reste, ces métadonnées ne sont en l’état pas trop exploitables si tu ne peux savoir ce que dis Mme Michu à Kévin.

Ingénieur informaticien

Le 22/08/2013 à 09h35

Dans l’open source, la faille peut venir du compilateur non ?

linkin623 Abonné

Le 22/08/2013 à 09h36

lysbleu a écrit :

C’était pas un hoax ça ?

odoc a écrit :

Euh si je me souviens bien, cette histoire de backdoor était un fake non ? (un audit complet a été fait et rien n’a été trouvé)

De souvenir, la “faille” a été révélée des années plus tard, alors que le code avait été remanié à de nombreuse reprises. Il ne restait plus traces de cette faille.

Pratique diront les complotistes " />

Cr30s Abonné

Le 22/08/2013 à 09h36

Pour ceux qui sont intéressé par le sujet il existe une campagne Indiegogo lancée par des islandais : MailPile

Le principe est assez similaire à celui de Caliop, seulement une étape de la réalisation en avance.

Les fonds récoltés (la limite de funding est déjà atteinte) servent à nourrir les devs et les serveurs.

On peut déjà mettre ses doigts tout gras dans le code sur le GitHub du projet.

iksarfighter

Le 22/08/2013 à 09h38

Commentaire_supprime

Le 22/08/2013 à 09h42

lysbleu a écrit :

C’était pas un hoax ça ?

odoc a écrit :

Euh si je me souviens bien, cette histoire de backdoor était un fake non ? (un audit complet a été fait et rien n’a été trouvé)

linkin623 a écrit :

De souvenir, la “faille” a été révélée des années plus tard, alors que le code avait été remanié à de nombreuse reprises. Il ne restait plus traces de cette faille.

Pratique diront les complotistes " />

En fait, cela reposait sur un témoignage unique d’un dev qui, sans apporter de preuves tangibles basées sur des faits (en l’occurrence, un extrait du code litigieux avec un commentaire expliquant son fonctionnement), a prétendu que la backdoor existait.

Témoignage unique, témoignage inique, donc irrecevable. Un gros coup de FUD en d’autres termes.

Commentaire_supprime

Le 22/08/2013 à 10h26

Ricard a écrit :

Faut arrêter de croire la NSA aussi. Ce qui les interesse, c’est aussi (et surtout) le contenu du mail. Faire gober que les meta-données c’est suffisant, c’est faire croire aux gens que le chiffrement n’est pas nécassaire. Surtout pour l’espionnage industriel par exemple. Que Airbus communique avec un sous-traitant par mail, c’est pas un secret et il n’y a rien d’étonnat là dedans, par contre, le contenu du message est important.

Pour le terrorisme, oui, mais imaginons le cas d’un spammeur. Toutes les “victimes’” sont répertoriées et sensées avoir un lien avec le spammeur ? Bah… Du blah blah tout ça. Ce qui les interesse vraiment, c’est bien le contenu du mail, sauf pour les terroristes déjà ciblés. Pour l’espionnage de masse qu’ils pratiquent, le chiffrement généralisé les ferait chier au plus haut point." />

Et puis, pour avoir des données VRAIMENT sensibles en matière de sécurité, le chiffrement des courriels, ça se contourne avec une bonne dose d’humint : infiltration de réseaux terroristes, retournement d’agents, opérations de déception, surveillance d’individus clefs bien ciblées, écoute des fuites d’information, analyses comportementales…

Tu peux chiffrer tes courriels tant que tu veux, si le destinataire en fait une copie en clair pour ton pire ennemi parce que c’est un agent double, tu l’as dans l’os, point.

Et la surveillance totale de la population, ça ne sert à rien. A part à inciter les criminels à ne pas employer des courriels pour préparer leurs sales besognes…

linkin623 Abonné

Le 22/08/2013 à 10h29

cyrano2 a écrit :

ça c’est totalement faux. Il y a plein de source sur le sujet.

La NSA s’en fout car, si il ne casse pas encore de l’AES128, il pourront le faire dans 5 ans. Et puis tout chiffrement AES même 256 bits à base de mot de passe est cassable en quelques heure sur un PC supercalculateur. Le nombre de mot de passe possible “humainement” est très largement en dessous de 100 bits d’entropie. Pour info, pour dépasser 100 bits, il faut 8(!) mot du langage courant. Qui fait cela ?

A quoi sert de péter du HTTPS, quand il suffit de se servir chez Google, Facebook ou autre ? Souvent il suffit d’aller regarder d’un coté du tuyau, c’est assez facile à priori (d’après Snowden).

" />

Un PC actuel ne peut faire cela en quelques heures, faut pas déconner.

+1, sinon inutile de récupérer le contenu sur le tuyau, autant aller là où il est en clair. A la limite on peut choper les métadonnées facilement (mais voilà la quantité).

Titizebioutifoul

Le 22/08/2013 à 10h29

Ricard a écrit :

Faut arrêter de croire la NSA aussi. Ce qui les interesse, c’est aussi (et surtout) le contenu du mail. Faire gober que les meta-données c’est suffisant, c’est faire croire aux gens que le chiffrement n’est pas nécassaire. Surtout pour l’espionnage industriel par exemple. Que Airbus communique avec un sous-traitant par mail, c’est pas un secret et il n’y a rien d’étonnat là dedans, par contre, le contenu du message est important.

Pour le terrorisme, oui, mais imaginons le cas d’un spammeur. Toutes les “victimes’” sont répertoriées et sensées avoir un lien avec le spammeur ? Bah… Du blah blah tout ça. Ce qui les interesse vraiment, c’est bien le contenu du mail, sauf pour les terroristes déjà ciblés. Pour l’espionnage de masse qu’ils pratiquent, le chiffrement généralisé les ferait chier au plus haut point." />

Ok merci pour les précisions ;)

linkin623 Abonné

Le 22/08/2013 à 10h31

Commentaire_supprime a écrit :

surveillance d’individus clefs bien ciblées,

j’apprécie l’utilisation de cette orthographe, le s étant de trop " />

Commentaire_supprime

Le 22/08/2013 à 10h34

linkin623 a écrit :

j’apprécie l’utilisation de cette orthographe, le s étant de trop " />

" />" />" />" />" />

Déjeuner, boulot, toussa…

Merci pour le nécessaire rappel à l’ordre.

" />" />

Patch Abonné

Le 22/08/2013 à 10h40

Commentaire_supprime a écrit :

" />" />" />" />" />

Déjeuner, boulot, toussa…

Merci pour le nécessaire rappel à l’ordre.

" />" />

" /> on ne croira jamais un fonctionnaire lorsqu’il parle de “boulot” " />

Ingénieur informaticien

Le 22/08/2013 à 10h45

Ricard a écrit :

Faut arrêter de croire la NSA aussi. Ce qui les interesse, c’est aussi (et surtout) le contenu du mail. Faire gober que les meta-données c’est suffisant, c’est faire croire aux gens que le chiffrement n’est pas nécassaire.

Pourtant la DGSE dit exactement la même chose.

Le DPI ne semble utilisé que dans des cas très particuliers.

Ricard

Le 22/08/2013 à 11h14

cyrano2 a écrit :

ça c’est totalement faux. Il y a plein de source sur le sujet.

La NSA s’en fout car, si il ne casse pas encore de l’AES128, il pourront le faire dans 5 ans.

Faux, là aussi. Déchiffrer un mail qui à 5 ans n’a aucun interêt pour eux. Attentat déjà fait ou technologie dépassée.

Et puis tout chiffrement AES même 256 bits à base de mot de passe est cassable en quelques heure sur un PC. Le nombre de mot de passe possible “humainement” est très largement en dessous de 100 bits d’entropie. Pour info, pour dépasser 100 bits, il faut 8(!) mot du langage courant. Qui fait cela ?

" />" />" />

Ricard

Le 22/08/2013 à 11h15

Ingénieur informaticien a écrit :

Pourtant la DGSE dit exactement la même chose.

Le DPI ne semble utilisé que dans des cas très particuliers.

Effectivement, la DGSE bluff aussi." />

Le 22/08/2013 à 11h16

Ricard a écrit :

Faut arrêter de croire la NSA aussi. Ce qui les intéresse, c’est aussi (et surtout) le contenu du mail. Faire gober que les meta-données c’est suffisant, c’est faire croire aux gens que le chiffrement n’est pas nécessaire

Le scandale des “fadettes” pour le téléphone démontre pourtant bien que c’est important: Pareil, c’est les métadonnée de l’appel (heure/durée/appelant-appelé/adresse ou géoloc approximative par la cellule en mobile) qui étaient visées en masse et non les conversations qui donnaient lieu au plus d’abus.

Ensuite, pour des cas ciblés (fleurons industriels etc…) il est clair que descendre plus bas peut avoir un intérêt. Mais savoir que tel dirigeant utilise son laptop de tel hotel à pétaouchnoc peut s’avérer bien plus intéressant pour aller en copier à l’heure du repas l’intégralité du contenu, voire lui foutre un call-girl dans le plumard (ayant laissé une caméra en tapant le HDD) pour lui faire chanter la clef de chiffrement du disque ensuite au besoin! " />

Ricard

Le 22/08/2013 à 11h22

yl a écrit :

Le scandale des “fadettes” pour le téléphone démontre pourtant bien que c’est important: Pareil, c’est les métadonnée de l’appel (heure/durée/appelant-appelé/adresse ou géoloc approximative par la cellule en mobile) qui étaient visées en masse et non les conversations qui donnaient lieu au plus d’abus.

On est là dans la téléphonie, pas sur le ternet. Mais oui, dans ce cas là. Cependant, cela ne tiens pas pour autant dans le cas d’une preuve. La fuite et le journaliste peuvent très bien avoir eu un contact qui n’a rien donné. Et dans le cas des fadettes, c’était illégal puisque contraire à la loi de la protection des sources.

Ensuite, pour des cas ciblés (fleurons industriels etc…) il est clair que descendre plus bas peut avoir un intérêt. Mais savoir que tel dirigeant utilise son laptop de tel hotel à pétaouchnoc peut s’avérer bien plus intéressant pour aller en copier à l’heure du repas l’intégralité du contenu, voire lui foutre un call-girl dans le plumard (ayant laissé une caméra en tapant le HDD) pour lui faire chanter la clef de chiffrement du disque ensuite au besoin! " />

Là, on est clairement plus dans la surveillance des réseaux, mais bel et bien dans un film de Xavier Berne Jason Bourne." />

cyrano2

Le 22/08/2013 à 11h40

Ricard a écrit :

Faux, là aussi. Déchiffrer un mail qui à 5 ans n’a aucun interêt pour eux. Attentat déjà fait ou technologie dépassée.

C’est le but d’avoir un cryptage qui dure longtemps. Mais il y a un tas de communication qui garde leur valeur longtemps.

" />" />" />

Ok, je vois que je suis tombé sur un champion du monde. Je détail comment casser un fichier crypté AES256 avec mot de passe d’humain, même si ily a eu déjà plusieurs articles sur le sujet (il suffit de chercher des infos sur l’outil hashcathttp://arstechnica.com/security/2013/03/how-i-became-a-password-cracker/ ).

La clef 256 bits d’un tel fichier provient d’un hash en général SHA256 du mot de passe. Un mot de passe à 8 caractères aléatoires soit en gros 70^8 combinaisons possible., soit ~2^49. C’est équivalent à une clef de 49 bits très loin des 100 bits nécessaire à une vrai protection contre les attaques brutes forces. Pour casser un tel message, il faut tester les 2^49 combinaisons, avec des machines qui tournent autour d’un milliard de hash à la seconde, cela peut aller assez vite.

Si on utilise seulement des mots du dictionnaires, on peut compter sur environ 2000 mot de vocabulaire, soit 2^12 mots. Pour approcher des 100 bits, il en faut donc ¹⁰⁰⁄₁₂ = 8.3, soit 9 mots.

Le 22/08/2013 à 11h42

Ricard a écrit :

On est là dans la téléphonie, pas sur le ternet.

(…)

Là, on est clairement plus dans la surveillance des réseaux, mais bel et bien dans un film de Xavier Berne Jason Bourne." />

Aucune différence: La voix est numérisée, souvent de la VoIP circulant sur les mêmes backbones… et traitable tout autant automatiquement. Et les métadonnées étaient l’essentiel des abus donc a priori pas inintéressantes. Les données, c’est trop gros à analyser de manière systématique.

Un film? Pour la pute, peut-être (et encore!), mais en général c’est dès la douane de l’aéroport que ça peut se passer… Les problèmes c’est si courant que des machines de voyage systématiquement remastérisées avant chaque départ et configurées pour juste permettre de se connecter via le VPN du site local ou l’on se rends, cela devient le standard de toute boite sensible… en plus de formations de sensibilisation à ce risque et les conduites à tenir face aux autorités de certains riants pays (Chine, Israël…): En gros, filer le mdp et laisser pomper! Si les consignes précédentes ont été respectées c’est pas un problème et évite de moisir en taule (fou le nb de pays qui n’ont aucune législation sur la durée max d’une garde à vue!) .

Tiens, petit tuyau parmi d’autres: Depuis les JO de Pékin chaque taxi est sonorisé et relié à un central (avec moult traducteurs) pouvant tous les écouter discrètement à volonté. Comme il faut un visa et une adresse locale pour se rendre dans ce pays, facile de cibler quel tacot se rends à telle heure (arrivée avion) a tel endroit… avec probablement telle personne dedans. Gare a la tentation d’y faire une pré-réunion d’affaire! Mais dit toi qu’a l’hôtel c’est sans doute pire…

uzak

Le 22/08/2013 à 11h42

yl a écrit :

Le scandale des “fadettes” pour le téléphone démontre pourtant bien que c’est important: Pareil, c’est les métadonnée de l’appel (heure/durée/appelant-appelé/adresse ou géoloc approximative par la cellule en mobile) qui étaient visées en masse et non les conversations qui donnaient lieu au plus d’abus.

Ensuite, pour des cas ciblés (fleurons industriels etc…) il est clair que descendre plus bas peut avoir un intérêt. Mais savoir que tel dirigeant utilise son laptop de tel hotel à pétaouchnoc peut s’avérer bien plus intéressant pour aller en copier à l’heure du repas l’intégralité du contenu, voire lui foutre un call-girl dans le plumard (ayant laissé une caméra en tapant le HDD) pour lui faire chanter la clef de chiffrement du disque ensuite au besoin! " />

DSK s’est fait piégé par la NSA " />

uzak

Le 22/08/2013 à 11h43

Ricard a écrit :

Un raspberry pi, et c’est parti." />

" /> Ça faisait longtemps.

uzak

Le 22/08/2013 à 11h47

Ingénieur informaticien a écrit :

Y’a plus qu’à coder le compilateur en langage machine directement.

Même l’assembleur peut-être suspecté !

Plus sérieusement, faut faire confiance aux repositories debian pour avoir un exé propre.

Je sais pas si il y a des moyens de vérifier que le compilateur n’est pas vérolé. Ça a forcément été exploré cette piste. Je m’en rappelle même l’avoir entendue évoquée en cours…

anonyme_97254becd5c5b064755d6772703ed968

Le 22/08/2013 à 14h28

Ricard a écrit :

Faut arrêter de croire la NSA aussi. Ce qui les interesse, c’est aussi (et surtout) le contenu du mail. Faire gober que les meta-données c’est suffisant, c’est faire croire aux gens que le chiffrement n’est pas nécassaire. Surtout pour l’espionnage industriel par exemple. Que Airbus communique avec un sous-traitant par mail, c’est pas un secret et il n’y a rien d’étonnat là dedans, par contre, le contenu du message est important.

Pour le terrorisme, oui, mais imaginons le cas d’un spammeur. Toutes les “victimes’” sont répertoriées et sensées avoir un lien avec le spammeur ? Bah… Du blah blah tout ça. Ce qui les interesse vraiment, c’est bien le contenu du mail, sauf pour les terroristes déjà ciblés. Pour l’espionnage de masse qu’ils pratiquent, le chiffrement généralisé les ferait chier au plus haut point." />

je confirme.

je peux pas te citer mes sources, mais je te confirme. " />

Commentaire_supprime

Le 22/08/2013 à 14h29

ledufakademy a écrit :

ben tu fais comme tout les geek : free.

ip fixe , bridge etc.

" />

Et FTTH = DMC…

C’est le fruit qui s’est bougé pour mon immeuble.

Ou alors, je prends une ligne ADSL classique chez OVH en plus, avec IP fixe en série…

levhieu

Le 22/08/2013 à 14h31

Je voudrais répondre au commentaire 86 mais je ne sais pas quoter en version mobile…

J’invite Ricard à bien relire le post dont il se moque pour enfin comprendre ce qui y est dit. Et non, il n’y a pas de confusion entre AES256 et SHA256. Et non, il n’y est pas dit que cracker AES256 est faisable, mais que cracker un chiffrement AES256 mal utilisé est faisable.

anonyme_97254becd5c5b064755d6772703ed968

Le 22/08/2013 à 14h31

yl a écrit :

Le scandale des “fadettes” pour le téléphone démontre pourtant bien que c’est important: Pareil, c’est les métadonnée de l’appel (heure/durée/appelant-appelé/adresse ou géoloc approximative par la cellule en mobile) qui étaient visées en masse et non les conversations qui donnaient lieu au plus d’abus.

Ensuite, pour des cas ciblés (fleurons industriels etc…) il est clair que descendre plus bas peut avoir un intérêt. Mais savoir que tel dirigeant utilise son laptop de tel hotel à pétaouchnoc peut s’avérer bien plus intéressant pour aller en copier à l’heure du repas l’intégralité du contenu, voire lui foutre un call-girl dans le plumard (ayant laissé une caméra en tapant le HDD) pour lui faire chanter la clef de chiffrement du disque ensuite au besoin! " />

Tu penses à qui en particulier ?

DSK , Dominique SkywalKer ?

" />

Ingénieur informaticien

Le 22/08/2013 à 14h36

La réponse de Google arrive …

Kyuuzo

Le 22/08/2013 à 14h43

cyrano2 a écrit :

Ok, je vois que je suis tombé sur un champion du monde. Je détail comment casser un fichier crypté AES256 avec mot de passe d’humain, même si ily a eu déjà plusieurs articles sur le sujet (il suffit de chercher des infos sur l’outil hashcathttp://arstechnica.com/security/2013/03/how-i-became-a-password-cracker/ ).

La clef 256 bits d’un tel fichier provient d’un hash en général SHA256 du mot de passe. Un mot de passe à 8 caractères aléatoires soit en gros 70^8 combinaisons possible., soit ~2^49. C’est équivalent à une clef de 49 bits très loin des 100 bits nécessaire à une vrai protection contre les attaques brutes forces. Pour casser un tel message, il faut tester les 2^49 combinaisons, avec des machines qui tournent autour d’un milliard de hash à la seconde, cela peut aller assez vite.

Si on utilise seulement des mots du dictionnaires, on peut compter sur environ 2000 mot de vocabulaire, soit 2^12 mots. Pour approcher des 100 bits, il en faut donc ¹⁰⁰⁄₁₂ = 8.3, soit 9 mots.

Sauf erreur de ma part (je veux bien qu’on m’explique si j’ai tort) :

Une clé symétrique de 256bits (comme AES par exemple, à l’opposé des clés asymétriques comme les clé publique RSA) est incassable par brute force. Déjà une clé de 128bits symétrique est incassable par brute force (il te faudrait toute la puissance du système solaire pendant un bon moment pour casser une clé de 128 bits) et il te faudrait une puissance “universelle” pour casser une clé de 256bits.

Seules les clés de 64bits sont cassables avec des calculateurs quantiques pour le moment.

SHA = Hash

AES = Algo d’ecryption de blocs symétrique

donc le fait de récup un contenu non crypté dans un hash SHA256 (comme dans le pseudo hack de ton lien) n’implique absolument pas de faille ni de cassage de l’AES256.

Je rappel quand même qu’on peut stacker plusieurs algo d’encryption comme par exemple l’AES-Twofish-Serpent, ce qui permet au cas où un cassage de l’AES arrive un jour, d’être protégé puisque tous les ciphers doivent-être cassés avant que l’attaquant puisse accèder aux données.

anonyme_97254becd5c5b064755d6772703ed968

Le 22/08/2013 à 14h48

Ingénieur informaticien a écrit :

Et l’hypothèse d’un firewall “absolu” qui ne laisserait passer QUE ce qu’on autorise explicitement ?

on passe tout par du http ou smtp , voir des tunnels en icmp … alors

le parefeu de nos jours … il est là, il fait ce qu’il peut.

Mais seul , il n’est rien qu’un bloc de titanium avec quelques trous béant pour voir au travers.

levhieu

Le 22/08/2013 à 14h49

Pour Kyuuzo:

Effectivement, AES256 reste OK, mais ce que dit cyrano2, c’est que si on l’utilise mal, on perd sa résistance au “cassage”

anonyme_97254becd5c5b064755d6772703ed968

Le 22/08/2013 à 14h50

damien_spirale a écrit :

100% d’accord avec ça !

Les meta données, ca va 5 minutes. Si Robert envoie un email à Georges pour dire qu’il va tout faire péter demain à 12h, les metadonnées ne serviront à rien !

L’email va évoluer et c’est très bien. Avec la fin de la confiance dans les Google/Apple/Microsoft/Yahoo, on va assister à de nouvelles alternatives. Un peu comme avec la fin de GReader.

C’est parfait !

oui c bien.

Ricard

Le 22/08/2013 à 14h53

levhieu a écrit :

Je voudrais répondre au commentaire 86 mais je ne sais pas quoter en version mobile…

J’invite Ricard à bien relire le post dont il se moque pour enfin comprendre ce qui y est dit. Et non, il n’y a pas de confusion entre AES256 et SHA256. Et non, il n’y est pas dit que cracker AES256 est faisable, mais que cracker un chiffrement AES256 mal utilisé est faisable.

Alors je t’invite à bien relire le post auquel j’ai répondu (#69). Je le cite ici au cas où:

Je détail comment casser un fichier crypté AES256 avec mot de passe d’humain, même si ily a eu déjà plusieurs articles sur le sujet (il suffit de chercher des infos sur l’outil hashcahttp://arstechnica.com/security/2013/03/how-i-became-a-password-cracker/ ).

Lire aussi le lien, ou on parle bien de Hash et non d’AES." />

Je confirme qu’il confonds bien les deux." />

Ricard

Le 22/08/2013 à 14h54

Sans déconner." />

Ricard

Le 22/08/2013 à 14h56

levhieu a écrit :

Pour Kyuuzo:

Effectivement, AES256 reste OK, mais ce que dit cyrano2, c’est que si on l’utilise mal, on perd sa résistance au “cassage”

C’est donc une faiblesse dans l’interface chaise clavier, et non pas d’AES. On est loin de ce que cyrano à dit.

Kyuuzo

Le 22/08/2013 à 15h02

levhieu a écrit :

Pour Kyuuzo:

Effectivement, AES256 reste OK, mais ce que dit cyrano2, c’est que si on l’utilise mal, on perd sa résistance au “cassage”

Tu crois ? Je sais pas, il est pas clair dans ces propos, surtout que le SHA256 est révolu depuis bien longtemps et qu’on utilise plus l’HMAC-SHA-512 maintenant.

En plus il n’y a pas de relation entre SHA et AES donc j’arrive pas à suivre son propos, la clé AES n’est pas contenue dans un hash, dans aucun cas.

Pour moi il est à pas tout compris à AES et se mélange les pinceaux sur ce coup.

cyrano2

Le 22/08/2013 à 15h07

Ricard a écrit :

Alors je t’invite à bien relire le post auquel j’ai répondu (#69). Je le cite ici au cas où:

Lire aussi le lien, ou on parle bien de Hash et non d’AES." />

Je confirme qu’il confonds bien les deux." />

Je confirme tu en tiens une bonne couche.

Alors tu as ton algo AES256 bits qui a besoin d’une clef 256 bits. Comme personne ne veux retenir “ER4DGT04FODfFg33()àDRG3569571245678FGOPVLDKdjkfgndprotjer” comme clef écrite ici en base64 (si tu me réponds que l’on ne peut avoir que des caractères 0-9A-F (hexadécimal) pour ce genre de clef, parce que tu ne regardes même pas ce qu’est du base 64, je vais encore me foutre de ta gueule d’une bonne force).

Donc comme ce genre de clef est immonde à retenir, on te laisse mettre “toto” comme clefs, que l’on appel “mot de passe”, ce mot de passe est trituré, avec du sel, ou avec un paquet de hash (genre sha256, md5, bcrypt, scrypt…), pour éviter les attack par rainbow table, et paf, on a une clef 256 bits.

Là, ou tu est vraiment stupide, c’est que l’article parle de casser des mots de passe de site web salé et protégé par hash. C’est différent de la protection d’un fichier. Mais le processus de cassage de la clef est exactement le même : généré plein de clef, passer le hash dessus, dans le cas des sites web, si le hash est le même, tu as le bon mots de passe du site web, dans le cas d’un fichier, si tu arrives à décrypter, tu as aussi le bon mot de passe du fichier.

Use your brain ! " />

cyrano2

Le 22/08/2013 à 15h09

Kyuuzo a écrit :

Tu crois ? Je sais pas, il est pas clair dans ces propos, surtout que le SHA256 est révolu depuis bien longtemps et qu’on utilise plus l’HMAC-SHA-512 maintenant.

En plus il n’y a pas de relation entre SHA et AES donc j’arrive pas à suivre son propos, la clé AES n’est pas contenue dans un hash, dans aucun cas.

Pour moi il est à pas tout compris à AES et se mélange les pinceaux sur ce coup.

HMAC, c’est pour les signatures, ici je parle de génération de clef.

cyrano2

Le 22/08/2013 à 15h13

Le_Cha_po a écrit :

On peut imaginer un protocole transparent pour l’utilisateur (pas de mdp à rentrer) avec des chiffrage aussi gros que nécessaire générer (presque) aléatoirement non ?

Oui tu peux. Le problème revient à stocker la clef que tu n’arrives pas à retenir. Si tu crypte avec gpg, ta clef 256 bits est protégé par le cryptage à clef publique RSA ou DSA dans le fichier crypté.

Maintenant le problème est de ne pas se faire voler sa clef privé. En général, elle est crypté par une “passe phrase”, justement pour rendre difficile l’attaque brute force. Mais on revient au problème précédent.

cyrano2

Le 23/08/2013 à 10h12

uzak a écrit :

Ben si, le comment tu obtiens ta clé, c’est le protocole qui le dit, pas la fonction de chiffrement en elle même.

Je sais bien. Je parlais du cas du fichier crypté utilisant un mot de passe.

c’est pas pour ça qu’on introduit un sel dans les hash par hasard ?

Non, le sel, évite de pourvoir utiliser un dictionnaire de hash précalculé. Mais les PC sont assez rapide pour recalculer tout à la volé.

cyrano2

Le 23/08/2013 à 10h13

Ricard a écrit :

Ca n’a rien de nouveau, c’est du brute force par dictionnaire. Ca n’en affaiblit pas pour autant l’AES256 comme tu le prétends.

Apprend à lire. J’ai juste dis que l’AES ne protégait pas suffisamment si le mot de passe provenait d’un humain. C’est mon 1er poste, et c’est toi qui le contredisait alors que tu n’essayes même pas de comprendre.

Ricard a écrit :

Inutile de te raccrocher au branches. Tu as bien dit que tu pouvais casser l’AES256 facilement avec un PC (menteur) en me filant un lien foireux qui explique comment s’y prendre avec un hash qui est réputé non sûr depuis au moins 10 ans (incompétent).

Regarde comment fonctionne hashcat, il gère aussi les sha1 et pas seulement md5. Et je n’ai jamais parler de casser AES, mais de trouver le mot de passe ce qui n’a rien à voir. Apprend à lire.

Quand à tes suppositions (avec des si, on en fait des choses) sur le hash d’un mot de passe, il est possible avec le MD5 d’avoir le même hash pour deux fichiers différents. Ha ben oui, c’est codé sur 32 bits, pour un mdp de 8 caractères, je te laisse faire le calcul, c’est effectivement pas compliqué du tout, mais là, ta tentative de mettre sur une fausse piste ne fonctionne pas. Tu confonds AES256 et MD5. (stupide)

Mouhahahahaaaa." />

hashcat fait du brute force, il n’utilise pas les faiblesse de md5. Apprend à lire.

md5 fait 128 bits. Apprend à utiliser google, tu passera moins pour une andouille.

Tu n’a toujours pas compris ce qu’est une fonction de génération de clef (hash) à partir d’un mot de passe. L’article pointé l’explique pourtant. Apprends à lire.

ganjo a écrit :

Enfin il ne fait que retrouver un pass correspondant à un md5, ce qui est en effet simple sur tout les pc d’aujourdhui, même avec du sha1 en utilisant les solutions cloud qu’offrent certains sites. Mais actuellement un double sha1+sel ne se casse pas aisément, encore mieu en sha256.

Mais on s’éloigne du sujet, ici la solution proposée est un système de chiffrement

La puissance de calcul des PC et autre GPU fait que l’on a plus besoin des rainbow table. Les hashs sont calculés à la volé. Le sel ne sert donc presque plus à rien.

ganjo a écrit :

Ca n’a pas grand chose à voir, dailleurs aujourdhui c’est de moins en moins un humain qui choisit un clé de chiffrement, ta clé pour aes est générée aléatoirement et est elle même chiffré par une clé rsa (de préférence sur un token), ce qui semble être la solution avancée dans l’article.

On est d’accord. J’ai juste évoqué les mots de passe d’humain pour le cryptage de fichier en symétrique sans clef public/privé, et Ricard n’a rien compris et l’a fait savoir bruyamment.

cyrano2

Le 23/08/2013 à 10h21

levhieu a écrit :

La discussion a un peu continué pendant qu’on m’invitait au restaurant, mais c’est quand-même étonnant de voir qu’en gros tout le monde pense la même chose et ne s’en rend pas compte.

Et pour finir ganjo décrit la solution au problème soulevé par cyrano2. Tout en se faisant ( à mon avis) des illusions sur la diffusion des bonnes pratiques en ce domaine, comme dans tout domaine à la fois incompris et utilisable par le pékin moyen

La gestion de la clef privé, c’est tout de même pas simple du tout. Même si elle ne circule pas, il y a un risque de vol. Et vu que c’est le sommet de la chaine de confiance, sa valeur est disproportionné, je trouve. Et la gestion de la révocation semble encore plus complexe.

Tout le monde ne jure que par TLS, mais il ne semble pas si difficile de faire de vrai faux certificat, et des tas d’entreprise font des proxy menteurs HTTPS en déployant de faux certificat racine maison sur les navigateurs, sans qu’ils aient de problème.

ganjo

Le 23/08/2013 à 10h32

cyrano2 a écrit :

Non, le sel, évite de pourvoir utiliser un dictionnaire de hash précalculé. Mais les PC sont assez rapide pour recalculer tout à la volé.

Non le sel éxistait bien avant ce problème, et n’est pas utilisé que dans les algos de hash. Le sel est là pour augmenter la taille de clé. Tant qu’il n’est pas connu tu complique le brute force

Et si une clé de - de 10 caractères en md5 ou sha1 simple n’a en effet plus grande valeur en brute force, au dessus il faut encore des fermes, et l’on est pas obligé d’utiliser des algos facilement vectorisable.

cyrano2

Le 23/08/2013 à 12h34

ganjo a écrit :

Non le sel éxistait bien avant ce problème, et n’est pas utilisé que dans les algos de hash. Le sel est là pour augmenter la taille de clé. Tant qu’il n’est pas connu tu complique le brute force.

Je ne vois pas comment, vu que le sel est connu, fournis dans le fichier. Il évite l’utilité des précalculs.

Si il augmente la taille de la clef, ou se trouve-il ? Il est forcément fournis pour le décodage.

picoteras

Le 23/08/2013 à 17h57

Ricard a écrit :

Faut arrêter de croire la NSA aussi. Ce qui les interesse, c’est aussi (et surtout) le contenu du mail. Faire gober que les meta-données c’est suffisant, c’est faire croire aux gens que le chiffrement n’est pas nécassaire. Surtout pour l’espionnage industriel par exemple. Que Airbus communique avec un sous-traitant par mail, c’est pas un secret et il n’y a rien d’étonnat là dedans, par contre, le contenu du message est important.

Pour le terrorisme, oui, mais imaginons le cas d’un spammeur. Toutes les “victimes’” sont répertoriées et sensées avoir un lien avec le spammeur ? Bah… Du blah blah tout ça. Ce qui les interesse vraiment, c’est bien le contenu du mail, sauf pour les terroristes déjà ciblés. Pour l’espionnage de masse qu’ils pratiquent, le chiffrement généralisé les ferait chier au plus haut point." />

Bof, encore un qui n’a pas vraiment suivi l’évolution des applis militaires de cartographie (mapping) des réseaux relationnels (la NSA, la DGSE et autres, c’est statutairement ou contractuellement des militaires, surprise! )

Titizebioutifoul avait parfaitement raison de signaler que les métadonnées restent le talon d’Achille de toute tentative de “sécuriser” l’email (quelque soit le protocole standard utilisé).

levhieu

Le 23/08/2013 à 19h59

Pour une fois ya quelque chose que je connais: un des intérêts ( le seul?) du sel, c’est de permettre que passer 2 fois le même texte au chiffrement donne 2 résultats différents

levhieu

Le 22/08/2013 à 15h49

Kyuuzo, le point que tu manque dans le raisonnement, c’est qu’augmenter la longueur de la pass-phrase fournie ne rend pas plus compliquée la tentative de cassage.

Par exemple, si je sais ( cas stupide) que quelqu’un a utilisé un mot de 4 caractères comme pass-phrase pour générer une clef pour AES256, et si je connais la méthode pour aller de 4 à 256 caractères, je n’ai pas à essayer toutes les longues clefs mais seulement tous les mots (courts), ce qui diminue considérablement le temps nécessaire pour tout essayer.

En pratique, c’est plus dur que pour mon exemple stupide, parce que la longueur n’est pas connue mais “estimée”, parce que le salt complique le travail, mais ce n’est pas hors de portée du matériel actuel

Kyuuzo

Le 22/08/2013 à 15h54

levhieu a écrit :

Kyuuzo, le point que tu manque dans le raisonnement, c’est qu’augmenter la longueur de la pass-phrase fournie ne rend pas plus compliquée la tentative de cassage.

Par exemple, si je sais ( cas stupide) que quelqu’un a utilisé un mot de 4 caractères comme pass-phrase pour générer une clef pour AES256, et si je connais la méthode pour aller de 4 à 256 caractères, je n’ai pas à essayer toutes les longues clefs mais seulement tous les mots (courts), ce qui diminue considérablement le temps nécessaire pour tout essayer.

En pratique, c’est plus dur que pour mon exemple stupide, parce que la longueur n’est pas connue mais “estimée”, parce que le salt complique le travail, mais ce n’est pas hors de portée du matériel actuel

Enfin une explication ! x)

Merci " />

Mais ça soulève une question dans ma ptite tête :P :

même si t’as tous les dicos qui faut pour lancer ton bruteforce etc, comment tu détermine la fonction qui gènère ta clef ?

Y en a plein non ? Du coup nbre de caractère + méthode ça fait beaucoup d’inconnues non?

uzak

Le 22/08/2013 à 15h57

levhieu a écrit :

Kyuuzo, le point que tu manque dans le raisonnement, c’est qu’augmenter la longueur de la pass-phrase fournie ne rend pas plus compliquée la tentative de cassage.

Par exemple, si je sais ( cas stupide) que quelqu’un a utilisé un mot de 4 caractères comme pass-phrase pour générer une clef pour AES256, et si je connais la méthode pour aller de 4 à 256 caractères, je n’ai pas à essayer toutes les longues clefs mais seulement tous les mots (courts), ce qui diminue considérablement le temps nécessaire pour tout essayer.

En pratique, c’est plus dur que pour mon exemple stupide, parce que la longueur n’est pas connue mais “estimée”, parce que le salt complique le travail, mais ce n’est pas hors de portée du matériel actuel

En gros, c’est un question de protocole.

Par exemple, dans le SSL/TLS, AES est un bon chiffrement et la clé est générée aléatoirement.

Pour chiffrer du mail, j’irais plus vers un asymétrique perso…

smnr

Le 22/08/2013 à 15h58

uzak a écrit :

Et cela suppose d’avoir un binaire de référence produit par la même version du compilateur donc, les même options de compilation, et surtout un compilateur que l’on sait être non vérolé. Mais comment le sait-on pour celui-ci ?

Non, ce n’est pas ce que je voulais dire. Je reformule, en précisant que je ne sais pas si c’est techniquement réalisable : on écrit une fonction qui donne une signature du future binaire (donc avant compilation), on compile (sans les optimisations), et on compare la signature (elles ne doivent pas forcément être identiques, mais proches, et voir quel est le taux de confiance).

levhieu

Le 22/08/2013 à 16h06

Kyuuzo, je ne sais toujours pas citer en version mobile ( mais bientôt …)

Pour ce qui est de la fonction de transformation de la pass-phrase, je suppose que regarder ce que font les logiciels populaires doit couvrir un max de cas avec pas trop d’efforts.

(au passage, je signale que je ne suis pas un spécialiste du domaine, je ne fais que dire ce que j’ai compris de posts précédents)

levhieu

Le 22/08/2013 à 16h07

Et m…, je me suis fait bouffer ma balise fin des vacances dans mon précédent commentaire

uzak

Le 22/08/2013 à 16h10

smnr a écrit :

Non, ce n’est pas ce que je voulais dire. Je reformule, en précisant que je ne sais pas si c’est techniquement réalisable : on écrit une fonction qui donne une signature du future binaire (donc avant compilation), on compile (sans les optimisations), et on compare la signature (elles ne doivent pas forcément être identiques, mais proches, et voir quel est le taux de confiance).

Ah ouais !

Je doute que ce soit possible " />

Kyuuzo

Le 22/08/2013 à 16h15

levhieu a écrit :

Kyuuzo, je ne sais toujours pas citer en version mobile ( mais bientôt …)

Pour ce qui est de la fonction de transformation de la pass-phrase, je suppose que regarder ce que font les logiciels populaires doit couvrir un max de cas avec pas trop d’efforts.

(au passage, je signale que je ne suis pas un spécialiste du domaine, je ne fais que dire ce que j’ai compris de posts précédents)

Oki doki, merci quand même d’essayer d’apporter des précisions, au moins j’me coucherais peut-être pas moins bête mais plus cultivé " />

Merci à vous tous pour toutes ces précisions " />

smnr

Le 22/08/2013 à 16h26

uzak a écrit :

Ah ouais !

Je doute que ce soit possible " />

Je ne sais pas, l’idée m’a juste traversé l’esprit, mais je pense que c’est possible avec de l’analyse statistique et de la proba, si j’arrive à faire la démo technique (pas tout de suite hein, j’ai d’autres chats à fouetter pour le moment), je vous tiens au courant.

Ricard

Le 22/08/2013 à 17h01

cyrano2 a écrit :

La ou tu n’as rien compris, c’est que la clef utilisé pour crypté est choisi par un humain, qui les aimes courte. Il “suffit” de tester l’espace des clefs typiques d’un humains pour cracker le fichier. Cette espace de clef est bien plus petit que 128 bits.

C’est là tout l’astuce. " />

Ca n’a rien de nouveau, c’est du brute force par dictionnaire. Ca n’en affaiblit pas pour autant l’AES256 comme tu le prétends.

Ricard

Le 22/08/2013 à 17h09

cyrano2 a écrit :

Je confirme tu en tiens une bonne couche.

Alors tu as ton algo AES256 bits qui a besoin d’une clef 256 bits. Comme personne ne veux retenir “ER4DGT04FODfFg33()àDRG3569571245678FGOPVLDKdjkfgndprotjer” comme clef écrite ici en base64 (si tu me réponds que l’on ne peut avoir que des caractères 0-9A-F (hexadécimal) pour ce genre de clef, parce que tu ne regardes même pas ce qu’est du base 64, je vais encore me foutre de ta gueule d’une bonne force).

Donc comme ce genre de clef est immonde à retenir, on te laisse mettre “toto” comme clefs, que l’on appel “mot de passe”, ce mot de passe est trituré, avec du sel, ou avec un paquet de hash (genre sha256, md5, bcrypt, scrypt…), pour éviter les attack par rainbow table, et paf, on a une clef 256 bits.

Là, ou tu est vraiment stupide, c’est que l’article parle de casser des mots de passe de site web salé et protégé par hash. C’est différent de la protection d’un fichier. Mais le processus de cassage de la clef est exactement le même : généré plein de clef, passer le hash dessus, dans le cas des sites web, si le hash est le même, tu as le bon mots de passe du site web, dans le cas d’un fichier, si tu arrives à décrypter, tu as aussi le bon mot de passe du fichier.

Use your brain ! " />

Inutile de te raccrocher au branches. Tu as bien dit que tu pouvais casser l’AES256 facilement avec un PC (menteur) en me filant un lien foireux qui explique comment s’y prendre avec un hash qui est réputé non sûr depuis au moins 10 ans (incompétent).

Quand à tes suppositions (avec des si, on en fait des choses) sur le hash d’un mot de passe, il est possible avec le MD5 d’avoir le même hash pour deux fichiers différents. Ha ben oui, c’est codé sur 32 bits, pour un mdp de 8 caractères, je te laisse faire le calcul, c’est effectivement pas compliqué du tout, mais là, ta tentative de mettre sur une fausse piste ne fonctionne pas. Tu confonds AES256 et MD5. (stupide)

Mouhahahahaaaa." />

Jarodd Abonné

Le 22/08/2013 à 18h20

Mais je me dis que si moi j’ai plein d’idées, à 30, 40 ou 50, on aura des milliers d’idées et que l’on pourra pour le coup faire quelque chose de vraiment chouette !

Ah ouais ! Ou alors si le projet n’est pas clair pour une personne, il deviendra bordélique à 30, 40 ou 50. Un projet informatique classique, en somme " />

ganjo

Le 22/08/2013 à 21h07

cyrano2 a écrit :

pas toujours, mais dans une majorité des cas :

Ars TechnicaEnfin il ne fait que retrouver un pass correspondant à un md5, ce qui est en effet simple sur tout les pc d’aujourdhui, même avec du sha1 en utilisant les solutions cloud qu’offrent certains sites. Mais actuellement un double sha1+sel ne se casse pas aisément, encore mieu en sha256.

Mais on s’éloigne du sujet, ici la solution proposée est un système de chiffrement

ganjo

Le 22/08/2013 à 21h13

cyrano2 a écrit :

La ou tu n’as rien compris, c’est que la clef utilisé pour crypté est choisi par un humain, qui les aimes courte. Il “suffit” de tester l’espace des clefs typiques d’un humains pour cracker le fichier. Cette espace de clef est bien plus petit que 128 bits.

C’est là tout l’astuce. " />

Ca n’a pas grand chose à voir, dailleurs aujourdhui c’est de moins en moins un humain qui choisit un clé de chiffrement, ta clé pour aes est générée aléatoirement et est elle même chiffré par une clé rsa (de préférence sur un token), ce qui semble être la solution avancée dans l’article.

levhieu

Le 23/08/2013 à 07h33

La discussion a un peu continué pendant qu’on m’invitait au restaurant, mais c’est quand-même étonnant de voir qu’en gros tout le monde pense la même chose et ne s’en rend pas compte.

Et pour finir ganjo décrit la solution au problème soulevé par cyrano2. Tout en se faisant ( à mon avis) des illusions sur la diffusion des bonnes pratiques en ce domaine, comme dans tout domaine à la fois incompris et utilisable par le pékin moyen

cyrano2

Le 23/08/2013 à 10h11

Kyuuzo a écrit :

HMAC te sert a vérifier l’authenticité d’une signature certe, mais tu peux t’en servir en surcouche de SHA512, permettant d’avoir un double hachage.

Tu utilises le mot de passe directement dans le calcul du HMAC, avec le message pour rajouter des choses à ton hash ?

Mais quand tu veux decrypté ton fichier, comment le décodeur peut connaitre le message pour retrouver la partie H(key||message) du calcul du HMAC. C’est crypté.

Concernant ton histoire de mot de passe AES créé avec un hash, je ne vois absolument pas le problème, ton mot de passe+hash étant transformé par la suite par AES par croisement de tables matricielles, il faudrait que le hacker en question trouve et le bon mot et le bon hash, ce qui est fort peu probable sur 256bit.

N’ayant aucun des deux (mot et hash) en clair nul part il est obligé de bruteforce la totalité des 256bit. Ce n’est pas comme dans ton lien explicatif où le gars à accès au hash directement, dans le cas de l’AES le hash en question serrait crypté.

Bref j’arrive pas à suivre ton raisonnement, mais le problème peut venir de moi hein x)

Ton erreur provient du fait de vouloir brute forcé la clef AES256 bits. C’est juste idiot. Tu sais comment ton mot de passe d’humain à été transformé pour devenir ta clef AES. Tu pars donc de ce qu’un humain peut penser, tu le transforme avec ton hash, et tu testes la clef trouvé. Un mot de passe courant a moins de 2^40 possibilité, ce qui se casse en quelques instant (3 mot un peu bidouillé).