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

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 »

Avatar de l'auteur
Xavier Berne

Publié dans

Logiciel

22/08/2013 6 minutes
144

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

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.

chemla CC

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.

 

caliop

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.

Écrit par Xavier Berne

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

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

Quelles sont vos pistes à l'heure actuelle ?

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

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 ?

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

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

Commentaires (144)


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 !




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 <img data-src=" /> aux services de l’Etat. <img data-src=" />


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


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.


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



bon courage pour le développement <img data-src=" />








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…



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








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 <img data-src=" />

<img data-src=" />









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.



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…








ledufakademy a écrit :



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





<img data-src=" /><img data-src=" /> go B4 <img data-src=" /> <img data-src=" />



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 =)


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


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


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.


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.








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.



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). <img data-src=" />





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


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. <img data-src=" />








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.





<img data-src=" /> <img data-src=" />









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)









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 <img data-src=" />









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). <img data-src=" />





* : 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.









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). <img data-src=" />



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.




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 <img data-src=" />








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.









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.









naemo a écrit :



Quelle réponse de merde <img data-src=" />





Quoi, tu veux qu’ils enfreignent la loi ? <img data-src=" />









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 ?









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é.









naemo a écrit :



Quelle réponse de merde <img data-src=" />







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é.









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 ?









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é)



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.








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.



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








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 <img data-src=" />



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.








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 <img data-src=" />







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 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.





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









linkin623 a écrit :



<img data-src=" /> 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.









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.





<img data-src=" /> maintenant



Blague à part, +1









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).









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 ?









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.









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.<img data-src=" />









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.









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 ?<img data-src=" />









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 ?









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.<img data-src=" />







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… <img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



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…









Ricard a écrit :



Sieve avec Dovecot ?<img data-src=" />







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).









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é !









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.<img data-src=" />









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.<img data-src=" />









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é)





<img data-src=" /> Toutafé. Le type à du passer pour un gros guignol en plus. <img data-src=" />









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.<img data-src=" />







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…









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).





<img data-src=" />

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é).









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.<img data-src=" />







Ok merci pour les précisions ;)









Commentaire_supprime a écrit :



surveillance d’individus clefs bien ciblées,





j’apprécie l’utilisation de cette orthographe, le s étant de trop <img data-src=" />









linkin623 a écrit :



j’apprécie l’utilisation de cette orthographe, le s étant de trop <img data-src=" />







<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



Déjeuner, boulot, toussa…



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



<img data-src=" /><img data-src=" />









Commentaire_supprime a écrit :



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



Déjeuner, boulot, toussa…



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



<img data-src=" /><img data-src=" />





<img data-src=" /> on ne croira jamais un fonctionnaire lorsqu’il parle de “boulot” <img data-src=" />









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.









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 ?



<img data-src=" /><img data-src=" /><img data-src=" />









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.<img data-src=" />









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! <img data-src=" />










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! <img data-src=" />



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









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.





<img data-src=" /><img data-src=" /><img data-src=" />





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 10012 = 8.3, soit 9 mots.









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.<img data-src=" />







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…









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! <img data-src=" />





DSK s’est fait piégé par la NSA <img data-src=" />









Ricard a écrit :



Un raspberry pi, et c’est parti.<img data-src=" />





<img data-src=" /> Ça faisait longtemps.









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…









uzak a écrit :



DSK s’est fait piégé par la NSA <img data-src=" />







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”









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









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.<img data-src=" />





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. <img data-src=" />









linkin623 a écrit :



<img data-src=" />

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







pas toujours, mais dans une majorité des cas :



http://arstechnica.com/security/2013/03/how-i-became-a-password-cracker/










yl a écrit :



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





Dans l’os quoi !









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?









uzak a écrit :



Dans l’os quoi !







Ou expertiser tout le code assemblé <img data-src=" />



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!









yl a écrit :



Ou expertiser tout le code assemblé <img data-src=" />



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.



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








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.









Ricard a écrit :



Effectivement, la DGSE bluff aussi.<img data-src=" />







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.









Ricard a écrit :



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







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 !









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 10012 = 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.<img data-src=" />









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 !





<img data-src=" />

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









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 ?









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.

<img data-src=" />









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.<img data-src=" />





je confirme.

je peux pas te citer mes sources, mais je te confirme. <img data-src=" />









ledufakademy a écrit :



ben tu fais comme tout les geek : free.

ip fixe , bridge etc.

<img data-src=" />







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…



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.








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! <img data-src=" />







Tu penses à qui en particulier ?

DSK , Dominique SkywalKer ?

<img data-src=" />



La réponse de Google arrive …








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 10012 = 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.









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.



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”








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.









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.<img data-src=" />

Je confirme qu’il confonds bien les deux.<img data-src=" />



Sans déconner.<img data-src=" />








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.









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.









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.<img data-src=" />

Je confirme qu’il confonds bien les deux.<img data-src=" />







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 ! <img data-src=" />









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.









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.



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.








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 ?



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








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.<img data-src=" />







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. <img data-src=" />









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.









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.









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. <img data-src=" />





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…









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)









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 :)









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.



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!”








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 ?









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)









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 <img data-src=" />









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.









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 !



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








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 <img data-src=" />

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?









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…









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).



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)


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








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 <img data-src=" />









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é <img data-src=" />

Merci à vous tous pour toutes ces précisions <img data-src=" />









uzak a écrit :



Ah ouais !

Je doute que ce soit possible <img data-src=" />





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.









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. <img data-src=" />





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.









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 ! <img data-src=" />





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.<img data-src=" />





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 <img data-src=" />










cyrano2 a écrit :



pas toujours, mais dans une majorité des cas :



http://arstechnica.com/security/2013/03/how-i-became-a-password-cracker/







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









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. <img data-src=" />







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.



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








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é).









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é.









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.<img data-src=" />





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.









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.









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.









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.









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.<img data-src=" />







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! :oui2:)



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é).



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