Libgcrypt 1.7.8 bouche une faille permettant de récupérer une clé RSA sur 1024 bits

L'été sera chaud !

Le 04 juillet 2017 à 07h30

2 min

Internet

Libgcrypt est victime d'une faille de sécurité qui permet de récupérer une clé de chiffrement RSA sur 1024 bits, et laisse entrevoir une attaque similaire sur 2048 bits. Une mise à jour est disponible, reste maintenant à ce qu'elle soit implémentée par les systèmes utilisant cette bibliothèque.

Une mise à jour importante a été publiée pour la bibliothèque de cryptographie Libgcrypt. Portant le numéro de version 1.7.8, elle permet de combler la faille identifiée CVE-2017-7526.

Une faille pour RSA-1024, qui pourrait toucher RSA-2048

Elle est importante puisque l'équipe de Debian explique que les chercheurs ont « découvert que Libgcrypt est prédisposé à une attaque par canal auxiliaire locale permettant une récupération complète de clé pour le chiffrement RSA-1024 ». Les chercheurs précisent également que cette attaque pourrait fonctionner sur des clés RSA sur 2048 bits avec une puissance de calcul « modérément plus importante ».

Précisons tout de même que son exploitation nécessite d'avoir accès à la machine et pouvoir y exécuter des logiciels de manière arbitraire. Détail important cependant, dans le cas d'un ordinateur exécutant plusieurs machines virtuelles, « cette attaque peut être utilisée par une VM pour récupérer des clés privées d'une autre VM », ce qui peut être un problème dans le cadre de serveurs par exemple. Tous les détails techniques sont disponibles dans ce document.

Des mises à jour disponibles pour Debian et Ubuntu

Une faille de sécurité dont la portée est augmentée par la très large utilisation de Libgcrypt dans de nombreuses distributions, y compris dans des systèmes propriétaires comme des NAS. Comme toujours, il est recommandé de se mettre à jour dès que possible.

Certaines distributions Linux ont d'ores et déjà déployé des correctifs, c'est notamment le cas de Debian et d'Ubuntu. De son côté Red Hat explique qu'il mène des investigations afin de vérifier ce qu'il en est pour Red Hat Entreprise Linux 5 à 7. D'autres arriveront certainement dans les jours qui viennent.

Commentaires (32)

skankhunt42

Le 04/07/2017 à 09h08

David_L a écrit :

Next INpactJe te conseille de rechercher le passage qui dit « l’utilisation des moyens de cryptologie est libre »

J’ai quand même du mal avec le passage du pourquoi chiffrer… Parce que bon :

. Car vous mettez des enveloppes autour de votre courrier : Le facteur peut très bien ouvrir ma lettre ou même un voisin car crocheter une boite c’est vraiment fastoche.

. vous n’affichez pas votre numéro et votre code de carte bancaire sur un t-shirt : Je ne vois pas le rapport

. vous fermez vos portes à clef : 380.000 cambriolage en france chaque année !

. vous envoyez des messages sur Facebook Messenger et pas uniquement via votre mur public : Et alors ? Mon collègue peut très bien aller sur ma tab pendant que je vais boire un café !

Pourquoi vous ne dites pas simplement la vérité les gars !

Si une communication n’est pas chiffrée ont peut ce prendre un man in the middle car 99.99% d’internet n’est pas sécurisé et facilement piratable ( demandez au ukrainiens ), que des fournisseur de mails peuvent très facilement lire vos emails ( en ce logguant sur votre compte de manière invisible ou en sniffant le protocole ), et qu’un gamin de 12 ans peut hacker votre navigateur et pomper toutes vos données en quelques secondes !

C’est des exemple concret qui sont déja arrivés et bien mieux que des argument extrêmes complètement débile et c’est la première chose que mes parent me répondront. Pour résumer ce n’est pas tant les chose à cacher qui pose problème mais la facilité à les découvrir via internet part moyen légal ou non.

Ricard

Le 04/07/2017 à 09h24

the_Grim_Reaper a écrit :

Bah, beaucoup de monde en l’occurrence, surtout du 2048.

LE 3072 et 4096 sur beaucoup de liens c’est trop lourd à mettre en place/exploiter.

Après, pour avoir fait des préco de sécu, j’avais regardé sur le RGS ancienne version, et du coup, j’étais parti sur du 4096 pour avoir une dureé de vie des clés assez grande vu la durée de vie des documents chiffrés.

2048 minimum en effet. C’est pour ça que j’ai dit 3072 pour une bonne sécurité.

Le 1024 est tombé il y a 7 ans maintenant avec peu de moyens à l’époque (80 pentiums pendant 3 mois). Perso, vu les moyens actuels de certaines agences/botnets/whatever, le 2048 me fait plus trop confiance.

Ricard

Le 04/07/2017 à 09h33

Wikus a écrit :

Certes " />

On remercie donc Apple d’exiger la déclaration lors de la publication d’un tel soft sur l’AppStore (est-ce toujours le cas ?). ChatSecure, Wire, ProtonMail, cryptomator… ont visiblement été ravis de se frotter à l’administration française !

Thankfully, there is an English website for this.

But the fun stops there. From now on, everything is in French. Yup. That’s right. Everything. Even the responses you receive are in French. And you have to submit your request via mail (yes, not email).

cryptomator

Ben… heureusement que l’appstore d’Apple ne représente que 0.5% des solutions de chiffrement alors.

OlivierJ Abonné

Le 04/07/2017 à 09h45

the_Grim_Reaper a écrit :

Bah, beaucoup de monde en l’occurrence, surtout du 2048.

LE 3072 et 4096 sur beaucoup de liens c’est trop lourd à mettre en place/exploiter.

Après, pour avoir fait des préco de sécu, j’avais regardé sur le RGS ancienne version, et du coup, j’étais parti sur du 4096 pour avoir une dureé de vie des clés assez grande vu la durée de vie des documents chiffrés.

Il ne faut pas trop délirer sur les tailles de clés, là on parle d’attaque par des États, et encore même la NSA n’a pas des moyens illimités, surtout pour aller craquer un de vos documents relativement anodins.

Ricard a écrit :

2048 minimum en effet. C’est pour ça que j’ai dit 3072 pour une bonne sécurité.

Le 1024 est tombé il y a 7 ans maintenant avec peu de moyens à l’époque (80 pentiums pendant 3 mois). Perso, vu les moyens actuels de certaines agences/botnets/whatever, le 2048 me fait plus trop confiance.

Le 1024 n’est pas encore tombé (cf mon lien précédent), tu dois confondre avec une taille bien inférieure.

Pas la peine de se branler la nouille, la différence entre 1024 et 2048 est tout simplement énorme (rien à voir avec 2 fois plus de temps), et le 2048 est hors de portée pour un bout de temps, et on parle encore une fois d’organisations qui auraient des moyens considérables.

De toutes façons, tout dépend de ce qu’on veut protéger : si c’est un document qui n’aura guère d’importance dans 5 ou 10 ans, pas la peine de d’utiliser un marteau-pilon. Perso, je chiffre pour éviter qu’on puisse lire facilement le contenu, et pour ça même du 1024 bits suffirait amplement (qui va aller faire tourner des réseaux entiers de machines + l’électricité associée pour aller déchiffrer une archive “tgz” ?).

127.0.0.1

Le 04/07/2017 à 09h48

Du moins, tous les derniers guides/tutos que j’ai lu sur les outils de crypto utilisent RSA 4096, AES 256 et SHA 256 (voir SHA 512).

Ricard

Le 04/07/2017 à 09h54

127.0.0.1 a écrit :

Du moins, tous les derniers guides/tutos que j’ai lu sur les outils de crypto utilisent RSA 4096, AES 256 et SHA 256 (voir SHA 512).

" />

David_L Abonné

Le 04/07/2017 à 09h57

127.0.0.1 a écrit :

Du moins, tous les derniers guides/tutos que j’ai lu sur les outils de crypto utilisent RSA 4096, AES 256 et SHA 256 (voir SHA 512).

Vrai pour les tutos emails & co, quand tu dois implémenter ça dans des solutions avec peu de puissance & co, c’est un autre délire. 

OlivierJ Abonné

Le 04/07/2017 à 09h58

127.0.0.1 a écrit :

Du moins, tous les derniers guides/tutos que j’ai lu sur les outils de crypto utilisent RSA 4096, AES 256 et SHA 256 (voir SHA 512).

C’est vraiment pour se la jouer, parce que c’est assez inutile pour le commun des mortels (et ça a un coût).

127.0.0.1

Le 04/07/2017 à 10h05

David_L a écrit :

Vrai pour les tutos emails & co, quand tu dois implémenter ça dans des solutions avec peu de puissance & co, c’est un autre délire.

Certes. Reste à espérer que ces solutions low-power ne soient pas visées par l’exploitation de cette faille.

Mais si c’est du low-power, c’est sans doute un système dédié (NAS ?, middleware réseau ?). Et on peut espérer qu’il n’y ait pas un “accès à la machine et pouvoir y exécuter des logiciels de manière arbitraire”. " />

the_Grim_Reaper Abonné

Le 04/07/2017 à 12h13

OlivierJ a écrit :

Il ne faut pas trop délirer sur les tailles de clés, là on parle d’attaque par des États, et encore même la NSA n’a pas des moyens illimités, surtout pour aller craquer un de vos documents relativement anodins.

Le 1024 n’est pas encore tombé (cf mon lien précédent), tu dois confondre avec une taille bien inférieure.

Pas la peine de se branler la nouille, la différence entre 1024 et 2048 est tout simplement énorme (rien à voir avec 2 fois plus de temps), et le 2048 est hors de portée pour un bout de temps, et on parle encore une fois d’organisations qui auraient des moyens considérables.

De toutes façons, tout dépend de ce qu’on veut protéger : si c’est un document qui n’aura guère d’importance dans 5 ou 10 ans, pas la peine de d’utiliser un marteau-pilon. Perso, je chiffre pour éviter qu’on puisse lire facilement le contenu, et pour ça même du 1024 bits suffirait amplement (qui va aller faire tourner des réseaux entiers de machines + l’électricité associée pour aller déchiffrer une archive “tgz” ?).

La puissance de calcul n’est plus si énorme avec le cloud et le GPGPU ;) mets toi à la page des algo et des puissances louable sur Azure et EC3…

La clé de 1024 est tombée y’a des années, c’est assez vite après celle de 768 bits justement.

C’est en grande partie pour ca que RSA a fini par annulé son concourt de cassage de clés :p

Le 2048 n’est pas hors de portée avec les machines actuelles, sans compter la recherche quantique.

De plus, je n’ai fait que suivre les recommandation de l’ANSSI (une bande de branleurs d’après toi) qui recommande d’aller au dela de 2048 pour des documents échangés au delà de 2019 (ce qui était mon cas) dans le cas d’un chiffrement asymétrique.

Après, pour juger des doc que j’avais à protéger, je pense que je suis plus à même que toi de savoir.

En l’occurrence, c’est pour plus de 10 ans, avec des données confidentielles (industrielle et personnelles clients) .

C’est beau de faire des remarques déplacées, encore faut-il un minimum maîtriser son sujet, ce qui ne semble pas vraiment être le cas ici, et prendre en compte les contraintes d’utilisation des autres.

Avec des gens comme toi, je ne m’étonnerai pas de voir des données perso se balader dans al nature " />

Ricard a écrit :

2048 minimum en effet. C’est pour ça que j’ai dit 3072 pour une bonne sécurité.

Le 1024 est tombé il y a 7 ans maintenant avec peu de moyens à l’époque (80 pentiums pendant 3 mois). Perso, vu les moyens actuels de certaines agences/botnets/whatever, le 2048 me fait plus trop confiance.

Ete 2010 de mémoire en plus ;)

Visiblement, quelqu’un n’est pas d’accord avec nous…

Et de surcroît, se permet de faire des remarques sans connaitre le contexte autour.

Tout le monde ne bosse pas pour une PME du BTP qui est spécialisée dans le goudronnage de route.

the_Grim_Reaper Abonné

Le 04/07/2017 à 12h23

David_L a écrit :

Vrai pour les tutos emails & co, quand tu dois implémenter ça dans des solutions avec peu de puissance & co, c’est un autre délire.

BAh, si le compte sert à chiffrer des docs en plus des mails, c’est pas forcément déconnant.

Si c’est juste pour du chiffrement mails, effectivement…

127.0.0.1 a écrit :

Certes. Reste à espérer que ces solutions low-power ne soient pas visées par l’exploitation de cette faille.

Mais si c’est du low-power, c’est sans doute un système dédié (NAS ?, middleware réseau ?). Et on peut espérer qu’il n’y ait pas un “accès à la machine et pouvoir y exécuter des logiciels de manière arbitraire”. " />

Le soucis des mots de passes faible, tu l’as aussi dans le monde de l’industrie et services :/

Ricard

Le 04/07/2017 à 12h36

the_Grim_Reaper a écrit :

BAh, si le compte sert à chiffrer des docs en plus des mails, c’est pas forcément déconnant.

Si c’est juste pour du chiffrement mails, effectivement…

Le soucis des mots de passes faible, tu l’as aussi dans le monde de l’industrie et services :/

RSA sert aussi dans TLS… Rien que ça." />

Quand on sait que sur Nxi c’est du RSA 256. " />

Ricard

Le 04/07/2017 à 12h39

the_Grim_Reaper a écrit :

Ete 2010 de mémoire en plus ;)

Visiblement, quelqu’un n’est pas d’accord avec nous…

Et de surcroît, se permet de faire des remarques sans connaitre le contexte autour.

Tout le monde ne bosse pas pour une PME du BTP qui est spécialisée dans le goudronnage de route.

En mars 2010 exactement. Par les chercheurs de l’Univesité du Michigan.

http://ns.umich.edu/new/releases/7551

et le PDF qui va bien:http://www.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf

OlivierJ Abonné

Le 04/07/2017 à 12h47

the_Grim_Reaper a écrit :

La puissance de calcul n’est plus si énorme avec le cloud et le GPGPU ;) mets toi à la page des algo et des puissances louable sur Azure et EC3…

Avant de pouvoir louer de quoi casser du RSA facilement, je te conseille de gagner au loto d’abord.

Et puis qui va louer un réseau entier de machines puissantes pour aller casser tes documents, simple individu ?

the_Grim_Reaper a écrit :

La clé de 1024 est tombée y’a des années, c’est assez vite après celle de 768 bits justement.

C’est en grande partie pour ca que RSA a fini par annulé son concourt de cassage de clés :p

Le cassage de la clé de 1024 s’appuyait sur un méthode indirecte (effet sur la consommation du processeur), qui peut être corrigée (et l’a été dans les circuits spécialisés, d’ailleurs dans les cartes à puces - ou circuit utilisant du RSA - en principe c’est le cas) :http://macbidouille.com/news/2010/03/08/des-chercheurs-ont-reussi-a-casser-une-c…

Pour info j’ai aussi bossé chez Schlumberger (partie qui est devenu Gemalto) dans la partie cartes à puces, je ne pars pas de zéro.

the_Grim_Reaper a écrit :

Le 2048 n’est pas hors de portée avec les machines actuelles, sans compter la recherche quantique.

La recherche quantique, si ça aboutit, c’est même pas 4096 bits qui vont te protéger, il me semble.

Quand aux 2048 bits, le saut est gigantesque. Un ordre de grandeur expliqué ici par exemple :http://www.bibmath.net/forums/viewtopic.php?id=6389 .

the_Grim_Reaper a écrit :

De plus, je n’ai fait que suivre les recommandation de l’ANSSI (une bande de branleurs d’après toi) qui recommande d’aller au dela de 2048 pour des documents échangés au delà de 2019 (ce qui était mon cas) dans le cas d’un chiffrement asymétrique.

“une bande de branleurs d’après toi” : ?? Où j’aurais écrit ça " />

Quand j’ai mentionn” l’ANSSI dans un commentaire précédent, j’ai indiqué ce lienhttps://www.keylength.com/fr/5/ dans lequel il est indiqué :

2014-2020 : symétrique : 100 bit | asymétrique factorisation : 2048 bits

2021-2030 : symétrique : 128 bit | asymétrique factorisation : 2048 bits

Et ça s’adresse plus à des banques et des institutions étatiques qu’à de simples individus, qui détiennent rarement des informations du même intérêt.

the_Grim_Reaper a écrit :

Après, pour juger des doc que j’avais à protéger, je pense que je suis plus à même que toi de savoir.

En l’occurrence, c’est pour plus de 10 ans, avec des données confidentielles (industrielle et personnelles clients).

Ben si tu veux te faire plaisir avec 4096 bits ou 8192 bits, éclate-toi hein. On va pas te gâcher le plaisir.

the_Grim_Reaper a écrit :

C’est beau de faire des remarques déplacées, encore faut-il un minimum maîtriser son sujet

Mouais. Relis.

the_Grim_Reaper a écrit :

Tout le monde ne bosse pas pour une PME du BTP qui est spécialisée dans le goudronnage de route.

Des grosses boîtes surtout, avec des besoins de protection aussi.

the_Grim_Reaper Abonné

Le 04/07/2017 à 13h44

Ricard a écrit :

RSA sert aussi dans TLS… Rien que ça." />

Quand on sait que sur Nxi c’est du RSA 256. " />

Bah en TLS y’a pas vraiment beaucoup mieux si tu ne veut pas planter les perfs, sauf à investir dans un accélérateur à côté de mémoire. Ca fait un moment que j’ai aps fait de pur technique sécu réseau.

Mais le coût n’est pas le même.

Ricard a écrit :

En mars 2010 exactement. Par les chercheurs de l’Univesité du Michigan.

http://ns.umich.edu/new/releases/7551

et le PDF qui va bien:http://www.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf

My (Wo)man, merci :)

OlivierJ a écrit :

Avant de pouvoir louer de quoi casser du RSA facilement, je te conseille de gagner au loto d’abord.

Et puis qui va louer un réseau entier de machines puissantes pour aller casser tes documents, simple individu ?

Le cassage de la clé de 1024 s’appuyant sur un méthode indirecte (effet sur la consommation du processeur), qui peut être corrigée (et l’a été dans les circuits spécialisés, d’ailleurs dans les cartes à puces - ou circuit utilisant du RSA - en principe c’est le cas) :http://macbidouille.com/news/2010/03/08/des-chercheurs-ont-reussi-a-casser-une-c…

Pour info j’ai aussi bossé chez Schlumberger (partie qui est devenu Gemalto) dans la partie cartes à puces, je ne pars pas de zéro.

La recherche quantique, si ça aboutit, c’est même pas 4096 bits qui vont te protéger, il me semble.

Quand aux 2048 bits, le saut est gigantesque. Un ordre de grandeur expliqué ici par exemple :http://www.bibmath.net/forums/viewtopic.php?id=6389 .

“une bande de branleurs d’après toi” : ?? Où j’aurais écrit ça " />

Quand j’ai mentionn” l’ANSSI dans un commentaire précédent, j’ai indiqué ce lienhttps://www.keylength.com/fr/5/ dans lequel il est indiqué :

2014-2020 : symétrique : 100 bit | asymétrique factorisation : 2048 bits

2021-2030 : symétrique : 128 bit | asymétrique factorisation : 2048 bits

Et ça s’adresse plus à des banques et des institutions étatiques qu’à de simples individus, qui détiennent rarement des informations du même intérêt.

Ben si tu veux te faire plaisir avec 4096 bits ou 8192 bits, éclate-toi hein. On va pas te gâcher le plaisir.

Mouais. Relis.

Des grosses boîtes surtout, avec des besoins de protection aussi.

Bah.. Azure ou EC3, tout le monde peu en louer, donc oui… :p

Et le prix de la puissance de calcul est ridicule. Encore une fois, renseignes-toi avant de sortir des choses.

Vive le site de référence… " />

Si tu passe en quantique, tous les algo actuels vont tomber. Pour le coup, le nombre de clients est assez limité actuellement. Etats et grosses société (couple Google-Nasa).

Du coup, y’a déjà de la recherche pour pondre un algo quantique.

Bah, vu que dans mon post initial je précise que je me suis basé sur les recommandations du RJS V1 (comme précisé, les V2 n’étaient alors pas dispo), je me dis que… soit t’as pas vu … soit tu ‘en cognes.

Je viens de vérifier, pour la V2, c’est du 2048. My bad, vive la regression de la V2 :/

Ne sachant pas où je bossais (et à quel poste) et où je bosse maintenant… posé la question aurait été totalement pertinente ;)

Et vu qu’a tour de rôle j’ai fait les deux, c’est balo ;)

C’est surtout parce que j’ai anticipé les lourdeurs organisationnelles autour ;)

En soit, le temps passé à généré la clé est un poil plus long, mais c’est pas mortel non plus. A l’usage ça ne changeait rien :)

Bah justement.

Miracle… enfin un post avec des choses constructives et posée :)

Y’a donc, les grosses boites (tous secteurs confondus), les administrations, les banques, et les prestataires associés (beaucoup d’externalisation dans tout ça).

Ricard

Le 04/07/2017 à 13h51

the_Grim_Reaper a écrit :

Bah en TLS y’a pas vraiment beaucoup mieux si tu ne veut pas planter les perfs, sauf à investir dans un accélérateur à côté de mémoire. Ca fait un moment que j’ai aps fait de pur technique sécu réseau.

Mais le coût n’est pas le même.

Certes. Mais il y a TLS et TLS. TLS 1.0, c’est de la merde.

Seul TLS 1.2 tient la route.

Bon après je disais Nxi, comme ça mais il y a pire. Le site du Crédit Agricole est encore plus pourri, et pire que tout, le site des impôts (interface de connexion) ou tu rentres tes logins mdp utilise du DES3. Je te laisse deviner ce qu’il se passe si Mme Michu doit faire sa déclaration avec son XP IE6. Sécurité = 0

levhieu

Le 04/07/2017 à 13h58

Ça veut dire que quelqu’un pourrait payer à ma place ? " />

" />

Z-os Abonné

Le 04/07/2017 à 17h51

Ou déclarer tes tableaux de maître et résidences secondaires à ta place. :)

the_Grim_Reaper Abonné

Le 04/07/2017 à 18h00

Ricard a écrit :

Certes. Mais il y a TLS et TLS. TLS 1.0, c’est de la merde.

Seul TLS 1.2 tient la route.

Bon après je disais Nxi, comme ça mais il y a pire. Le site du Crédit Agricole est encore plus pourri, et pire que tout, le site des impôts (interface de connexion) ou tu rentres tes logins mdp utilise du DES3. Je te laisse deviner ce qu’il se passe si Mme Michu doit faire sa déclaration avec son XP IE6. Sécurité = 0

:lol:

Ricard

Le 04/07/2017 à 18h36

Z-os a écrit :

Ou déclarer tes tableaux de maître et résidences secondaires à ta place. :)

:laurent_fabius:

koshieDotFr

Le 05/07/2017 à 07h55

Ce n’est pas plus lourd à ma connaissance (du moins, ça ne se ressent pas réellement), Google et d’autres entreprises recommandent déjà de passer tout le web en HTTPS même si “y’en a pas besoin”:

-https://https.cio.gov/everything/

-https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Ciphersuite

-https://www.sslshopper.com/why-ssl-the-purpose-of-using-ssl-certificates.html

Ça fait un moment que j’ai pas lu ces liens mais Google semblait dire qu’en passant toute leur infra en HTTPS ils s’attendaient à une montée de la charge. Elle l’a été de moins d’1% et donc leur préparation n’a été qu’une précaution en fin de compte.

 

Je sais que je dépose ces liens à l’arrache mais ils m’ont convaincu qu’ils fallait tout passer en HTTPS, et de toute façon mes clés sont toutes en 4096 donc cette faille ne semble pas me concerner o.

 

Ricard

Le 05/07/2017 à 08h42

koshieDotFr a écrit :

Je sais que je dépose ces liens à l’arrache mais ils m’ont convaincu qu’ils fallait tout passer en HTTPS, et de toute façon mes clés sont toutes en 4096 donc cette faille ne semble pas me concerner o.

Ben t’es juste concerné quand tu navigues sur INternet sur un site qu’a une sécurité moisie avec un navigateur moisi. Ca concerne beaucoup de monde, sans parler qu’un certificat qui serait “compromis” est toujours valable, même dans un navigateur récent, sans que tu le saches.

Mais ça, malheureusement, tu n’y peux rien." />

Ricard

Le 04/07/2017 à 07h45

RSA 1024 ? Qui l’utilise encore ?

La norme c’est 3072 maintenant, voir 4096.

TNZfr

Le 04/07/2017 à 07h53

Avec ou sans obligation de déclaration ? ( > à 2048)

David_L Abonné

Le 04/07/2017 à 07h55

Next INpactJe te conseille de rechercher le passage qui dit « l’utilisation des moyens de cryptologie est libre »

jice68 Abonné

Le 04/07/2017 à 07h57

David_L a écrit :

Next INpactJe te conseille de rechercher le passage qui dit « l’utilisation des moyens de cryptologie est libre »

Pour le moment… :(

Wikus

Le 04/07/2017 à 08h02

jice68 a écrit :

Pour le moment… :(

E. Macron approuve ce message… et veut qu’on lui fournisse “les codes” " />

Plus sérieusement :

Next INpactQuand on voit la liste de documents à fournir, tu m’étonnes que c’est une calamité pour les “petits” développeurs

Ricard

Le 04/07/2017 à 08h09

Wikus a écrit :

E. Macron approuve ce message… et veut qu’on lui fournisse “les codes” " />

Plus sérieusement :

Next INpactQuand on voit la liste de documents à fournir, tu m’étonnes que c’est une calamité pour les “petits” développeurs

Su Git, personne n’ira vérifier que tu es français. " />

jb18v

Le 04/07/2017 à 08h12

Ricard a écrit :

Su Git, personne n’ira vérifier que tu es français. " />

Je propose de franciser ce nom barbare en “Gîte” " /> :pinard: " />

OlivierJ Abonné

Le 04/07/2017 à 08h14

Ricard a écrit :

RSA 1024 ? Qui l’utilise encore ?

La norme c’est 3072 maintenant, voire 4096.

(voire, pas “voir”, ça ne concerne pas la vision)

" />

Sinon, la recommandation pour encore plus de 10 ans, c’est 2048 bits pour RSA. Il faut dire que le record de factorisation est à 768 bits et donc on est très très loin des 2048 (même 1024 semble quasi hors de portée sauf à y mettre des moyens énormes).

https://www.keylength.com/fr/5/

the_Grim_Reaper Abonné

Le 04/07/2017 à 08h21

Ricard a écrit :

RSA 1024 ? Qui l’utilise encore ?

La norme c’est 3072 maintenant, voir 4096.

Bah, beaucoup de monde en l’occurrence, surtout du 2048.

LE 3072 et 4096 sur beaucoup de liens c’est trop lourd à mettre en place/exploiter.

Après, pour avoir fait des préco de sécu, j’avais regardé sur le RGS ancienne version, et du coup, j’étais parti sur du 4096 pour avoir une dureé de vie des clés assez grande vu la durée de vie des documents chiffrés.

jice68 a écrit :

Pour le moment… :(

+1 … Mac n’est pas vraiment aimant pour le chiffrement :/

A quand les échanges secret devenus publiques hors de Wikileaks ? ^^

Wikus

Le 04/07/2017 à 08h23

Ricard a écrit :

Su Git, personne n’ira vérifier que tu es français. " />

Certes " />

On remercie donc Apple d’exiger la déclaration lors de la publication d’un tel soft sur l’AppStore (est-ce toujours le cas ?). ChatSecure, Wire, ProtonMail, cryptomator… ont visiblement été ravis de se frotter à l’administration française !

Thankfully, there is an English website for this.

But the fun stops there. From now on, everything is in French. Yup. That’s right. Everything. Even the responses you receive are in French. And you have to submit your request via mail (yes, not email).

cryptomator