Certbot: La longueur en bits de la clé RSA par défaut doit être 3072

Je suggérerais même 4096 (je le fais sur presque tous mes systèmes).

Merci,
Martin

Je suggérerais également 4096.

Mais il y a quelques mois, ils n'étaient pas d'accord avec 4096 par défaut : https://github.com/letsencrypt/letsencrypt/issues/489

Je préfère un compromis (= RSA avec un module de 3072 bits) par rapport à aucune sécurité par défaut.

Suggérez également 4096.
La sécurité doit être bonne par conception et par défaut : aucun utilisateur standard ne modifie la configuration par défaut.

Et il n'y a pas d'argument acceptable pour 2048/3072 vs 4096 bits (seulement une très petite surcharge de vitesse).
3072 bits peuvent entraîner des problèmes de compatibilité si l'agent utilisateur code en dur certaines tailles de clé (2048 et 4096 bits seront mieux pris en charge que 3072).

Pire, l'argument de la régénération de clé à 90 jours pour justifier l'utilisation d'une clé 2048 bits n'est pas bon :

• La régénération de clé casse beaucoup d'autres protections de pile TLS, comme DANE/TLSA ou HPKP, une configuration renforcée doit la désactiver pour éviter de gros problèmes.
• La régénération des clés ne dit pas "destruction du passé". Si le serveur Web n'est pas configuré correctement avec uniquement la suite de chiffrements PFS, les agences de type NSA peuvent intercepter et stocker les communications réseau protégées avec une clé de 2048 bits, et peuvent les décrypter dans 20 ou 30 ans, même si les clés correspondantes ont été détruites. Les clés 4096 bits protègent plus longtemps les communications non PFS.
• Même avec les chiffrements PFS uniquement, les serveurs Web basent généralement le paramètre DH négocié sur la taille de la clé privée. Si vous utilisez uniquement une clé privée de 2048 bits, votre paramètre DH est de 2048 bits uniquement, et donc peut-être faible pour LogJam.

Un autre +1 pour 4096, c'est ce que j'utilise toujours ces jours-ci.

Voir #489 pour de nombreuses discussions sur ce problème.

Avec les paramètres par défaut de LE, RSA 2048 bits, 90 jours, essayez de le casser ? Je propose de fermer ce sujet.

La question n'est pas « preuve que vous pouvez le cracker » (ou rester à 1024 bits, personne ne le crack depuis maintenant) mais « toutes les recommandations / état de l'art demandent au moins 3072 bits » (NSA, NIST, ANSSI, FIPS, Qualys et Suite).
Il n'y a AUCUN inconvénient valable à passer à 4096 bits par défaut.

(Et je le répète, même avec un renouvellement de clé de 90 jours, si aucun PFS n'est utilisé, vous avez une validité de clé pratique de plusieurs décennies même si la validité technique n'est que de 90 jours, et le renouvellement de clé de 90 jours casse beaucoup d'autres piles TLS (TLSA, HPKP, épinglage de certificat), donc l'administrateur système sain d'esprit DOIT le désactiver et réutiliser une clé pendant au moins 120 jours et 1 an dans la pratique)

Cependant, dans le top 1 000 000 de sites Web d'Alexa, plus de 89 % des sites Web compatibles SSL/TLS utilisent RSA 2048 bits, y compris de nombreux sites Web bancaires en ligne.

Oui, la banque a aussi SSLv3 et MD5 si vous voulez https://imirhil.fr/tls/#Banques %20en%20ligne
Et Google/Youtube aussi https://imirhil.fr/tls/alexa.html
Et site porno pas de TLS du tout https://imirhil.fr/tls/porn.html
Même CA a SSLv3, MD5, RC4 ou SSLv2 (oui, vous avez bien lu…) et des suites EXPORT 40 bits https://imirhil.fr/tls/ca.html

La configuration TLS est TRÈS mauvaise dans la nature, ce n'est pas un moyen de continuer à faire du craps.

@devnsec-com Ils ne sont donc pas sécurisés. Même si IPv6 et DNSSEC sont de bonnes technologies, elles ne sont pas encore massivement déployées. Il en est de même pour RSA 4096 bits. Nous devons avancer au lieu de faire du surplace.

La seule raison d'utiliser RSA 3072 ou 4096 (ou même plus) est la pérennité, mais avec un certificat de 90 jours uniquement, tous les utilisateurs ont-ils vraiment besoin de RSA plus long que 2048 par défaut ? Si vous êtes vraiment paranoïaque, optez pour des touches plus longues, il y a un paramètre et vous pouvez le changer.

Tous les utilisateurs ont besoin de la clé 3072+ par défaut .

Les personnes sachant vraiment ce qu'elles font peuvent éventuellement réduire la taille, mais par défaut , Let's encrypt doit fournir une configuration conforme à l'état de l'art.
L'utilisateur standard (99% en fait) ne regarde même pas la configuration ou ne se soucie pas de la taille de la clé générée ou ne sait même pas ce qu'est vraiment TLS…

Rappelez-vous, nous parlons d'un certificat SSL/TLS, vous pouvez avoir un support PFS sur votre serveur, et il peut être révoqué si nécessaire. Nous ne parlons pas d'une clé OpenGPG ou d'une clé SSH que vous pourriez utiliser pendant 20 ans ou même plus.

Et de nombreuses années plus tard, lorsqu'il s'avère que RSA 2048 n'est plus sécurisé, nous pouvons changer les valeurs par défaut de LE en RSA 4096, presque tous les utilisateurs seront changés en RSA 4096 dans les 90 jours.

Depuis que j'ai mentionné OpenGPG, je dirais que même OpenGPG est par défaut sur RSA 2048.
Lisez ceci : https://gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096

Vous pouvez . Vous pouvez aussi ne pas avoir de PFS. Et si la clé est de 2048 bits, vous n'êtes pas en sécurité. Même avec 90 jours de renouvellement. Et si pas de PFS, la destruction de clé ne sert à rien, vos données sont déjà dans la nature et devraient être décryptées dans quelques décennies.

Et seul le certificat peut être révoqué, pas la clé.
Les clés sont exactement comme les clés GPG/SSH : après génération, vous devez les gérer jusqu'à la destruction physique de la surface de la terre si PFS et éternellement si pas de PFS.

Depuis que j'ai mentionné OpenGPG, je dirais que même OpenGPG est par défaut sur RSA 2048.

GPG a un réel inconvénient à utiliser 4096 clés (seules quelques cartes à puce supportent plus de 2048, appareil mobile…). Sur TLS, il n'y en a pas.

Et sur GPG, tout le monde génère actuellement des clés 4096 bits, tous les tutoriels et recommandations le demandent.

Vous venez de faire un point, au lieu de discuter par défaut de RSA 2048 ou plus, nous devrions parler de défaut pour activer PFS. Parce que quelle que soit la longueur de la clé, elle sera déchiffrée tôt ou tard, RSA 2048 le sera, RSA 4096 le sera aussi.

Oui, mais vous n'avez aucun moyen d'assurer le PFS avec Let's Encrypt (et pire seulement les chiffrements PFS, vous pouvez négocier une suite de chiffrement PFS mais le serveur peut prendre en charge no-PFS ou EXPORT…).

Et actuellement, il y a un inconvénient majeur à n'utiliser que les suites de chiffrement PFS (compatibilité navigateur, voir https://tls.imirhil.fr/suite/EECDH+AES:EDH+AES+aRSA).

Dans tous les cas, ce n'est pas le travail d'un CA.

On ne parle pas ici de CA, mais d'un logiciel client, non ?

Non. TLS est très compliqué, avec beaucoup de pile.
Aucun logiciel ne peut le gérer complètement.

Vous n'avez aucun moyen de deviner si votre utilisateur a DNSSec ou TLSA, doit s'assurer de la compatibilité IE ou non de l'agent utilisateur standard, quelle version d'OpenSSL est utilisée, etc.
La seule chose que LE peut faire est d'augmenter la taille de la clé…

Non, quand LE utilise RSA 3072 ou 4096 par défaut, quelqu'un dira qu'il veut RSA 8192 par défaut pour tous les utilisateurs, c'est une course aux armements sans fin.

@devnsec-com Non. NSA, NIST, ANSSI, FIPS, Qualys ne recommandent pas RSA 8192 mais au moins RSA 3072.

Non, si quelqu'un demande 8192, vous pouvez dire que 4096 est actuellement sûr et recommandé partout.
Actuellement, ce n'est pas le cas de 2048.

Je peux également dire que Yubico , Cisco et de nombreuses entreprises recommandent RSA 2048 au moment où nous parlons.

Plus la longueur de la clé est longue, plus elles sont sûres, mais les entreprises commerciales sont plus pragmatiques sur ce sujet. Encore une fois, RSA 2048 est suffisant au stade actuel par défaut, tant que nous prenons en charge une clé plus longue en cas de besoin.

Bonne ressource pour cette conversation - keylength.com

@devnsec-com Les positions Yubico et Cisco sont valides, car ils ont un problème matériel (HSM, PKI et carte à puce ne prennent pas très bien en charge 4096 bits).

De Yubico : « Ce n'est pas une contrainte de Yubico, mais plutôt une limitation matérielle de la puce NXP A700x utilisée dans les YubiKeys »
De Cisco : 4096 bits uniquement disponibles à partir de Cisco IOS XE version 2.4 (et le matériel est difficile à mettre à niveau), et la page donnée est très ancienne (ne semble pas mise à jour depuis la version 2.4 (2009), même valeur par défaut depuis au moins la version 2.X …).

Et ce n'est pas parce que tous les autres moutons courent vers la falaise qu'il faut les suivre...

@devnsec-com J'ajoute aussi que la documentation de Cisco concerne la gestion de PKI et CA, et dans ce domaine (certificat CA, pas de certificat d'utilisateur final), CA/B-forum recommande au moins 2048 bits .

Et il y a aussi un débat interne sur les 4096 inclusions depuis 2014.

Est-ce que nous inclurions une recommandation sur la taille de la clé ? Certaines personnes veulent intentionnellement utiliser une clé de 4096 bits. Prendraient-ils conseil ? Le document pourrait expliquer le compromis entre la sécurité, la compatibilité et d'autres facteurs

Mais il semble que les routeurs matériels ne prennent pas en charge les racines supérieures à 2048 (Cisco)

Iñigo a déclaré que les derniers produits de Cisco ne prennent pas en charge les racines SHA-1 et 4096 bits. Kelvin a dit qu'il pourrait essayer de travailler avec Cisco pour changer cela.

@devnsec-com Un autre commentaire interne sur CA/B-forum.

Fixer des dates cibles pour la prochaine série de modifications pour améliorer la sécurité/les performances (RSA-4096/ECC/SHA-512/etc)

Bonjour les gars, Ce serait formidable de continuer ce fil et d'avoir des nouvelles du personnel de LE.
Autant que je sache, les arguments de @aeris semblent être valables et non contredits. Sauf si nous avons raté quelque chose, je m'attends également à ce que LE passe bientôt la clé RSA par défaut à 4096 bits.

+1 pour RSA 3072bit par défaut.

Comme cela a été mentionné, RSA 2048 bits n'équivaut qu'à 112 bits de protection de clé symétrique. Cela tombe en dessous du minimum largement répandu de 128 bits utilisé aujourd'hui. RSA 3072bit est seulement équivalent à 128 bits, donc suffisant pour le moment (et le strict minimum recommandé par la NSA en janvier 2016).

Notez que toutes les estimations précédentes de la longévité des tailles de clé doivent être prises avec un scepticisme sain, car elles supposent généralement une amélioration linéaire de la rupture de clé, mais de nouvelles attaques peuvent réduire la sécurité beaucoup plus rapidement.

Les clés RSA avec > 2048 bits sont actuellement incompatibles avec Amazon Web Services. À partir du Guide du développeur Amazon CloudFront :

La taille maximale de la clé publique dans un certificat SSL/TLS est de 2048 bits

Je pensais juste ajouter ce point supplémentaire dans la conversation.

Quiconque souhaite avoir plus de 2048 bits RSA peut simplement entrer --rsa-key-size 3072 ou --rsa-key-size 4096 pour demander ces tailles de clé.
Veuillez noter que les clés RSA plus grandes prennent beaucoup plus de temps à générer, et tout ce qui est supérieur à 4096 peut faire planter les anciens navigateurs Apple.

Lorsque #2632 a été implémenté, l'inconvénient des performances n'aura presque aucun impact pour la majorité.
Nous pouvons donc combiner EC 256 avec 3072 RSA (ou ce que nous préférons par défaut) pour fournir une résistance égale pour les deux.

Soit dit en passant, comme suggestion pour prendre en charge les clés EC, ayez une commande comme --ec-key-type pour générer une clé EC et demander le certificat.
Je génère et fais signer actuellement mes clés RSA à l'aide de certbot et mes clés EC à l'aide d'un script shell.

@WilliamFeely c'est #2625

Merci.
En ce qui concerne la taille de la clé RSA, je suppose que RSA 2048 est toujours la norme de l'industrie et toujours autorisée pour la conformité PCI-DSS, et donc pourquoi est-elle toujours par défaut ?

Voici ce que dit la dernière documentation PCI-DSS ( v3.2, avril 2016 ) :

Reportez-vous aux normes de l'industrie et aux meilleures pratiques pour plus d'informations sur la cryptographie robuste et les protocoles sécurisés (par exemple, NIST SP 800-52 et SP 800-57, OWASP, etc.)

Heureusement, le glossaire définit la cryptographie forte comme suit :

Cryptographie basée sur des algorithmes testés et acceptés par l'industrie, ainsi que des longueurs de clé qui fournissent un minimum de 112 bits de force de clé effective et des pratiques de gestion de clé appropriées. La cryptographie est une méthode de protection des données et comprend à la fois le cryptage (qui est réversible) et le hachage (qui est "à sens unique", c'est-à-dire non réversible). Voir Hachage.

Au moment de la publication, des exemples de normes et d'algorithmes testés et acceptés par l'industrie incluent AES (128 bits et plus), TDES/TDEA (clés à triple longueur), RSA (2048 bits et plus), ECC (224 bits et plus) , et DSA/DH (2048/224 bits et plus). Consultez la version actuelle de la publication spéciale NIST 800-57 Partie 1 (http://csrc.nist.gov/publications/) pour plus d'informations sur les forces et les algorithmes des clés cryptographiques.

_ Remarque : Les exemples ci-dessus sont appropriés pour le stockage persistant des données de titulaire de carte. Les exigences minimales de cryptographie pour les opérations basées sur les transactions, telles que définies dans PCI PIN et PTS, sont plus flexibles car des contrôles supplémentaires sont en place pour réduire le niveau d'exposition.
Il est recommandé que toutes les nouvelles implémentations utilisent un minimum de 128 bits de force de clé effective._

Il n'est pas nécessaire d'utiliser par défaut 3072 pour une clé RSA utilisée avec un serveur Web.

Tout d'abord, vous ne devez utiliser que des chiffrements qui fournissent FS. De cette façon, les sessions passées enregistrées sont toujours sécurisées même si votre clé privée est découverte ultérieurement.

Avec quelque chose comme GnuPG, vous voudrez peut-être utiliser plus grand (j'utilise 4096) car FS n'est pas une option, le client et le serveur ne négocient pas leur propre clé lorsque la connexion est établie. Même avec GnuPG, vous n'avez vraiment pas besoin de > 2048 et si vous le faites, EC en donne plus pour votre argent, mais comme il n'est pas encore bien pris en charge par les clients et qu'un message chiffré GnuPG peut être sensible pendant des décennies, 4096 est au moins justifiable,

Ce n'est pas justifiable avec HTTPS si FS est utilisé. Lorsque FS est utilisé, vous devez utiliser les chiffrements ECDHE lorsque cela est possible afin que la clé utilisée entre le client et le serveur soit plus forte. Si votre serveur prend toujours en charge les clés DHE, c'est dans le groupe DH que vous devez vous soucier du nombre de bits, et là, la plupart des gens utilisent le groupe 2048 DH prédéfini qui est publié dans la RFC. Générer votre propre groupe DHE 2048 bits est raisonnable.

Pour la clé privée du serveur, 2048 bits ne peuvent pas être facilement piratés et sont donc suffisants. Suggérer une valeur par défaut de 3072 ou 4096 revient à suggérer un presse-papier de 20 livres au lieu de 15 livres. Oui, le 20 livres est plus lourd, mais non, il n'y a pas de réel avantage et votre clé RSA 2048 bits sera remplacée depuis longtemps avant qu'elle ne soit plus sûre.

Utilisez toujours le secret de transmission et utilisez les chiffrements ECDHE dans la mesure du possible. La clé privée, RSA 2048 est assez bonne et si vous voulez vraiment mieux, utilisez ECDSA et non RSA pour la clé.

Je suppose que ce que j'essaie de dire, et corrigez-moi si je me trompe, c'est que lorsque votre TLS nécessite des chiffrements qui utilisent Forward Secrecy, le seul véritable objectif de la clé privée à long terme du serveur est l'identité.

Le chiffrement réel entre le client et le serveur qui a lieu utilise une clé temporaire négociée entre le client et le serveur qui n'est pas liée à la clé utilisée avec le certificat x.509.

C'est ce dont vous devez vous soucier, n'utilisez jamais de paramètres DH <2048 et utilisez de préférence ECDHE. La clé privée du serveur n'a alors de pertinence que pour établir l'identité du serveur, et le RSA 2048 bits est certainement suffisant pour cela, surtout si vous suivez les meilleures pratiques pour générer une nouvelle clé au moins une fois par an.

Ainsi, ce problème devrait être clos et l'accent mis sur la sécurité devrait être mis sur la sélection appropriée de la suite de chiffrement.

Intéressant, mais quand Applebaum et Snowden me recommandent d'utiliser la taille de clé RSA 4096 bits, eh bien, hmm, je ne sais pas, je pense que je pourrais suivre ce conseil. L'identité n'est-elle pas précisément ce que nous essayons de cacher/protéger ici ?

@jult Tenez -vous en à 4096 bits, surtout si vous utilisez GnuPG. Ce n'est que lorsque tout le monde passera à la version 2.1 que nous aurons accès aux clés OpenPGP ed25519. et ils ne sont pas beaucoup plus forts. (J'adore mes clés ed25519 SSH + GPG, alors encouragez tout le monde à s'éloigner de RSA !)

Les clés RSA 2048 bits devraient être cassables par un attaquant disposant d'une grande quantité de ressources de calcul au cours des prochaines années. 768-1024 bits déjà rompus régulièrement.

Je ne pense pas que 3072 soit une valeur par défaut raisonnable, c'est un peu hors de l'ordinaire.

2048-bit ne sera pas recommandé après 2030, je vous le garantis, et le coucher du soleil sera progressif comme il l'était pour SHA-1. J'ai lu beaucoup de ces documents de normes gouvernementales et autres...

Pendant un certain temps, les gens avaient l'habitude de créer des clés de 8192 bits et plus ... Ce n'est qu'un changement amusant de deux ou trois lignes à la source, je ne suis pas sûr de leur efficacité avec les autres.

. @WikiLeaks publie une clé de cryptage RSA PGP 8192 bits exceptionnellement puissante pour les soumissions https://t.co/xGnu72HTUN pic.twitter.com/8TZyql1NN6

– KM Gallagher (@ageis) 27 mai 2015

@ageis De plus, il y a une limite assez stricte sur 16384. Il faudrait * beaucoup * plus de piratage pour aller plus loin; J'ai essayé.

– isis agora lovecruft (@isislovecruft) 8 septembre 2014

@jult Je ne parlerai pas de l'affaire Appelbaum et Snowden. Je les connais aussi vaguement, mais je vois cela comme une sorte d'appel de rock star à l'autorité que vous lancez. Regardez toutes les sources, je peux en recommander quelques-unes en particulier :

• http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
• https://pages.nist.gov/800-63-3/sp800-63b.html
• http://www.secg.org/sec2-v2.pdf
• http://www.ecc-brainpool.org/download/Domain-parameters.pdf
• http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf
• https://safecurves.cr.yp.to/

Personnellement, je suis plus désireux de mettre tout le monde à jour vers GnuPG 2.1, avec le format kbx plus rapide, et de générer de nouvelles clés ed25519 (pensées @dkg ou @floodyberry ?), et j'espère que la prochaine série Yubico les prendra en charge. En fait, je peux tendre la main pour vérifier; car j'ai fait des tests bêta pour la YubiKey 4. Je n'aime pas la façon dont les clés doivent être protégées/mot de passe pour être exportées, car cela rend l'importation sur la carte à puce un défi.

Pendant que je suis autour de ce problème, je vais déposer un excellent tableau de la publication spéciale 800-57 du NIST. Beaucoup plus d'où cela vient. C'est parfait pour commencer un samedi soir, hein ?

Encore une fois, la charge supplémentaire sur la taille lors de la prise de contact client ne vaut pas le risque supplémentaire avec une taille de clé plus petite. Ceux qui déconseillent l'utilisation de RSA 4096 bits ne parviennent pas à trouver des arguments valables pour ne pas le faire. Sans parler du fait que nous comptons sur la bonne génération des clés , et si jamais cela finit par être défectueux, nous sommes bien mieux avec des clés de 4096 bits.
Vérifiez ça; https://github.com/certbot/certbot/issues/489#issuecomment-114083162
Vous voulez vous assurer que vous générez également des clés Diffie Helman de> = 4096 bits, des trucs comme ça
openssl dhparam -dsaparam -out /etc/ssl/dh4096.pem 4096
si vous voulez que cela ait un sens lorsque vous avez activé DH(E) dans vos suites de chiffrement.

J'ai exécuté un benchmark synthétique pour les signatures RSA tout à l'heure et j'ai vu ceci :

(1024, 0.0008035948276519776)
(2048, 0.0025235090255737304)
(3072, 0.006322009086608887)
(4096, 0.013043954849243164)

Le premier nombre est la taille du module et le second est le nombre moyen de secondes nécessaires par opération de signature.

J'ai trouvé les commentaires de @AliceWonderMiscreations sur le secret de transmission quelque peu convaincants ; est-ce que quelqu'un a des statistiques actuelles sur les fractions de connexions TLS qui sont négociées avec diverses suites de chiffrement aujourd'hui ? Si très peu utilisent maintenant des chiffrements non-PFS, le paramètre de longueur de clé RSA aura des conséquences minimales sur la sécurité à long terme.

FS et non-FS est un problème distinct. Oui, nous devrions encourager les suites de chiffrement FS, et les clients et les serveurs devraient désactiver les suites de chiffrement non FS lorsqu'ils savent qu'il est possible de le faire. (TLS 1.3 n'a plus de suites de chiffrement non-FS, yay !) Cela ne signifie pas que nous devrions ignorer l'importance d'une clé d'identité cryptographique forte, ou que nous devrions jouer les unes contre les autres. Rappelez-vous qu'une clé d'identité falsifiée permet de MiTM même une connexion FS.

RSA 3072 semble être le point idéal où les recommandations (comme ENISA et NIST) se fondent sur une forte marge de sécurité pour les clés destinées à être utilisées au cours de la prochaine décennie.

Salut @dkg ,

FS et non-FS est un problème distinct. Oui, nous devrions encourager les suites de chiffrement FS, et les clients et les serveurs devraient désactiver les suites de chiffrement non FS lorsqu'ils savent qu'il est possible de le faire. (TLS 1.3 n'a plus de suites de chiffrement non-FS, yay !) Cela ne signifie pas que nous devrions ignorer l'importance d'une clé d'identité cryptographique forte, ou que nous devrions jouer les unes contre les autres. Rappelez-vous qu'une clé d'identité falsifiée permet de MiTM même une connexion FS.

Dans le cas par défaut, nous n'utilisons actuellement qu'une clé de sujet RSA individuelle pendant 60 jours (le risque MITM actif se poursuivant pendant la durée de vie de 90 jours du certificat), puis nous passons à une autre. Il semble qu'il y ait une différence considérable entre "un attaquant qui peut casser la clé de 2048 bits en 90 jours peut effectuer une attaque active" et "un attaquant qui peut casser la clé de 2048 bits à tout moment peut récupérer le texte en clair des anciennes sessions qui il a été impliqué dans ». Le premier est vrai et le second n'est pas vrai dans le cas des suites de chiffrement FS.

Les recommandations sur la longueur de clé semblent généralement supposer un modèle de menace dans lequel l'attaquant casse une clé quelque temps après l'utilisation de cette clé. Par exemple, les recommandations que vous mentionnez ci-dessous semblent être basées sur un modèle de menace dans lequel un attaquant met des années à casser. une clé individuelle. Avec les suites de chiffrement FS, ce modèle de menace ne devrait pas être pertinent pour décider de la longueur de la clé d'identité, car une clé d'identité donnée a depuis longtemps cessé d'être utilisée.

RSA 3072 semble être le point idéal où les recommandations (comme ENISA et NIST) se fondent sur une forte marge de sécurité pour les clés destinées à être utilisées au cours de la prochaine décennie.

Le point que j'apprécie dans l'argument de @AliceWonderMiscreations est que les clés de 2048 bits que nous générons ne sont pas individuellement destinées à être utilisées sur une période d'une décennie, mais plutôt à être utilisées sur une période de plusieurs mois, lorsqu'elles sont utilisé pour authentifier les négociations Diffie-Hellman. Ainsi, ces recommandations peuvent tenir compte d'un contexte de sécurité différent dans la plupart des cas. En théorie, nous devrions nous inquiéter davantage du module DH dans la plupart des modèles de menace car c'est le paramètre limitant qui affecte directement le niveau de sécurité à long terme.

Je vais essayer d'obtenir des données pratiques sur la fréquence d'utilisation des suites de chiffrement FS et l'impact des clés 2048 par rapport aux clés 3072 bits sur les performances du serveur.

En tant que mise à jour, j'ai entendu des estimations approximatives de quelques sources différentes selon lesquelles "environ 10 %", "moins de 10 %" et "environ 1 %" des connexions HTTPS utilisent désormais des suites de chiffrement non FS. Il s'agit d'une cible très difficile à définir car cela dépend si c'est du point de vue du navigateur, du point de vue du serveur, dans un pays particulier, sur un site Web particulier, pour un type particulier de site Web, etc., et ces types de les différences semblent expliquer l'écart de 1 % à 10 %.

Personnellement, je suis plus préoccupé à cet égard par le fait que nous conservons les anciennes clés privées sur le disque (sur lequel j'ai déposé un problème séparé, https://github.com/certbot/certbot/issues/4635). Je pense que cela devrait être une priorité plus élevée car je pense que les attaquants compromettant un serveur afin de lire l'ancien trafic sont généralement beaucoup plus susceptibles que les attaquants de casser RSA 2048 bits pour le faire.

Je suggère ce qui suit :

• Je sais que @dkg a beaucoup travaillé sur la sécurité des échanges de clés DH dans TLS en général. Pouvez-vous créer ou trouver des outils qui aident à analyser les sites pour estimer la force de l'échange DH susceptible de se produire lorsqu'un client se connecte à chaque site¹ ? (Je sais que dans certains des domaines qui vous préoccupent, nous ne pouvons pas vraiment dire du côté client à quel point l'échange est sécurisé, mais je pense juste à essayer de cartographier la force de l'échange DH dans la mesure que nous pouvons le voir et le déterminer.) Nous connaissons aussi beaucoup de chercheurs universitaires qui se sont intéressés à ce genre de sujet...

• Je vais toujours essayer de corriger https://github.com/certbot/certbot/issues/4635 afin que les anciennes clés privées qui ne sont plus utilisées ne soient pas présentes sur les serveurs Web.

• Peut-être pouvons-nous penser à des mesures en cours pour encourager les utilisateurs à mettre à jour leurs navigateurs Web, afin d'augmenter la quantité de DH utilisée dans TLS.

Dans cet esprit, je répéterai que les clés de 2048 bits que nous générons par défaut ne sont généralement pas utilisées pour protéger directement la confidentialité des clés de session, mais plutôt pour authentifier les échanges de clés DH, où une attaque devrait être un en ligne , interactive, attaque active pendant la validité de 90 jours du certificat. Sinon, l'attaquant devra choisir une autre avenue d'attaque à la place. Il m'est difficile de voir que des sources de conseil sur la longueur de clé soutiennent que les clés de 2048 bits ne conviennent pas à l'authentification pendant une fenêtre de 90 jours. Ils sont plus directement liés à la confidentialité à long terme de 1 à 10 % des connexions, mais nous pouvons peut-être faire plus d'efforts pour réduire ce pourcentage.

¹ par exemple, en ce qui concerne l'algorithme et en ce qui concerne la taille et la réutilisation des paramètres publics

Je fais des recherches supplémentaires sur une suggestion connexe concernant les clés RSA, mais je prévois de fermer ce problème bientôt à moins que quelqu'un ait des réponses à mes trois suggestions dans ma réponse la plus récente.

Que diriez-vous de fermer ceci après que # 3349 ait été fait ?

Que diriez-vous de fermer ceci après que # 3349 ait été fait ?

Je dirais que #6492 est plus pertinent et que nous devrions fermer ceci après que #6492 ait été fait (et #4635).

Les gens, la crypto 4096 bits n'est pas gratuite. Il est extrêmement lent dans les processeurs à faible puissance. Même les téléphones modernes souffrent lors de son utilisation. Êtes-vous sûr que passer d'une crypto inviolable à une crypto encore plus inviolable vaut la peine de ruiner les performances et la durée de vie de la batterie de chacun ?

La longueur de clé de 4096 bits est un énorme problème dans l'IoT car ces appareils ont souvent une puissance CPU très limitée.

La vitesse des réservoirs RSA privés de 3,6 à 0,6 pour passer de 2048 à 4096 sur l'un de nos anciens appareils embarqués.

Comme mentionné précédemment, l'IoT et d'autres appareils sans accélération matérielle peuvent utiliser ECDSA (#6492).

Comme mentionné précédemment, l'IoT et d'autres appareils sans accélération matérielle peuvent utiliser ECDSA (#6492).

Existe-t-il une accélération matérielle de RSA dans de nombreux appareils ou est-ce encore généralement géré via un logiciel ?

L'accélération matérielle est disponible sur certains MCU, mais pas sur la majorité d'entre eux (c'est plus cher). De plus il est souvent limité à 3072, comme c'est la recommandation (https://www.keylength.com/)
Notez que la vérification RSA est assez rapide. Seules la génération et la signature sont très lentes.

OPENSSL_TLS_SECURITY_LEVEL=3 nécessite au moins 3072 bits.

Pourquoi ce problème est-il toujours ouvert ? Il est assez clair que les utilisateurs qui le demandent semblent mal comprendre la pertinence de TLS, surtout en 2020.

TL; DR

• Les certificats RSA n'ont d'importance que pour prouver que l'identité du serveur est fiable et sont remplacés tous les 90 jours . Il ne sera pas compromis en raison de la longueur de la clé de 2048 bits pendant cette période, juste pour se faire passer pour vous.
• Cela suppose que puisque vous vous souciez tellement de la sécurité, vous n'autorisez que les suites de chiffrement qui offrent FS (DHE/ECHDE), et DHE n'est pas vraiment une préoccupation pour vous non plus puisque pour les sites Web, aucun navigateur Web moderne ne prend en charge DHE pour plus d'échange de clés (Safari et Chrome ont abandonné la prise en charge vers 2016).
• Le RSA 1024 bits par rapport au RSA 2048 bits est environ 4 milliards de fois plus difficile à attaquer . Le RSA 768 bits a été rompu en 2010 (il a fallu 2 ans avec un calcul parallèle équivalent à 2000 ans d'une seule machine), En 2020, nous n'avons réussi qu'à atteindre 829 bits, 512 bits contre 1024 bits soit ~ 1 milliard fois en difficulté, tandis que 2048 bits vs 3072 bits ne sont que ~ 65 000 fois plus difficiles ...
• L'identité de votre certificat est vérifiée dans une chaîne de confiance par rapport aux certificats CA , qui ont une durée de validité plus longue mais sont toujours RSA 2048 bits, vous n'avez aucun contrôle sur cela . Un attaquant ciblera cela s'il veut se faire passer pour vous, augmenter la longueur de votre clé au-delà de cela n'offre aucun avantage supplémentaire lorsque le certificat n'est pas utilisé pour autre chose.

Pour la majorité des déploiements, vous devez vous assurer uniquement des suites de chiffrement PFS, votre certificat RSA n'a aucun avantage ici au-delà de 2048 bits, vous réduisez simplement le nombre de poignées de main que le serveur peut prendre en charge simultanément en raison de la surcharge supplémentaire. Le contexte des conseils doit être pris en considération, et pas seulement répété aveuglément.

Utilisez DHE / ECDHE uniquement pour l'échange de clés. Avec les serveurs Web, vous constaterez que depuis 2015, les navigateurs suppriment progressivement la prise en charge de DHE également. Safari l'a fait en réponse à Logjam en 2015, Chrome a abandonné le support DHE en 2016 ( Chrome 53 (août 2016) ) en raison du nombre de serveurs encore négociés avec des groupes DH 1024 bits, et Firefox a finalement rejoint cette année ( Firefox 78 ( juin 2020) ). Donc, fondamentalement, pour le Web, vous ne traitez qu'avec ECDHE, à moins que vous ne connaissiez réellement des clients qui ne peuvent pas le prendre en charge pour une raison quelconque, les navigateurs Web prennent en charge ECC depuis longtemps .

De quelle inquiétude éventuelle vous reste-t-il à vous soucier maintenant ? Vos certificats sont renouvelés/remplacés dans les 3 mois, le seul problème de sécurité avec les certificats RSA est l'identité, qu'un attaquant peut se faire passer pour vous, mais pour que cela se produise, l'attaquant doit réussir dans cette fenêtre de <90 jours.

En 2020, le record jusqu'à présent bat le RSA 829 bits (10 ans depuis que nous savions que le 768 bits était cassable), le précédent record de RSA 795 bits cite avoir de meilleurs algorithmes et du matériel disponible pour obtenir leurs résultats dans environ la moitié le temps de calcul. Il suffit de regarder les années de calcul 900-2000 auxquelles ces réalisations étaient équivalentes dans leur puissance de calcul parallèle (qui pour 768 bits a été réduite à 2 ans).

Le RSA 512 bits correspond à environ 50 bits de force de clé symétrique en matière de sécurité. RSA 1024 bits est connu sous le nom de 80 bits et RSA 2048 bits, 112 bits, tandis que 3072 bits, comme indiqué dans ce numéro, est de 128 bits. Bon, fantastique donc RSA 768 bits (qui se situe entre 50 et 80 bits de sécurité symétrique) en 2010 pourrait être cassé sur une période de 2 ans et une tonne d'argent, une décennie plus tard, nous avons réussi à faire quelques symétriques bits équivalents plus. Pour tous ceux où cela sonne comme du charabia, chaque bit supplémentaire dans la force de la clé symétrique double la quantité de travail à calculer si vous devez forcer brutalement toutes les possibilités (en moyenne, vous auriez du succès à mi-chemin de tout ce traitement cependant) .

Maintenant, comparez RSA 512 bits à 1024 bits, il y a une différence d'environ 30 bits dans la sécurité symétrique, 2 ^ 30 est d'environ 1 milliard, soit 50 bits (1 125 899 906 842 624 clés potentielles) multiplié par 1 milliard (1 125 899 906 842 624 000 000 000), ou tout simplement , 1 milliard de fois plus d'effort/temps pour se casser. Avec RSA 1024 bits vs 2048 bits, vous avez une différence de 32 bits, 2 ^ 32 est un peu plus de 4 milliards. Nous avons donc (4 503 599 627 370 496 000 000 000 000 000 000). Maintenant, monter à 3072 bits est un 16 bits de sécurité supplémentaire plus modeste, 2 ^ 16 == 65 536 ... oui, cela le rendra plus "sécurisé", pas tout à fait le même saut que notre multiplicateur de 4 milliards, mais nous avons déjà une augmentation significative de la difficulté avec RSA 2048 bits.

Maintenant, laissez cela s'imprégner et réfléchissez. Le RSA 768 bits en 2010 nécessitait 2 ans de traitement parallèle équivalent à 2000 ans à partir d'une seule machine, et une décennie plus tard, nous pouvons faire un peu mieux avec toutes ces avancées depuis. Encore loin du RSA 1024 bits à moins que quelqu'un avec une tonne d'argent et de temps à perdre veuille casser votre certificat RSA, ce n'est pas comme les groupes DH partagés, la valeur est considérablement plus petite d'un retour, sauf si vous êtes en possession de certaines données qui sont ridiculement précieuses et ne peuvent pas être obtenues par des moyens moins chers tels que la torture physique / le chantage.

Même si quelqu'un avait de telles ressources à gaspiller pour casser votre certificat RSA, ce n'est pas 1024 bits, la difficulté de 2048 bits est 4 milliards de fois cela, cela ne se produira pas sans une percée majeure, probablement une faiblesse où la longueur de la clé est ce n'est pas un problème (il suffit de regarder toutes les autres vulnérabilités de TLS qui ont contourné cela). Si vous êtes allé au-delà de RSA 3072 bits et que cela a été utilisé pour votre cryptage qui utilisait des clés 128 bits, alors votre certificat RSA n'a pas d'importance, et la clé de cryptage 128 bits pour AES peut simplement être attaquée à la place.

Tout cela mis à part, comme indiqué, nous parlons simplement de RSA n'ayant de pertinence pour l'identité que si vous utilisez uniquement des suites de chiffrement PFS, quelles que soient vos ressources, il existe de meilleures façons de compromettre votre serveur ou vos utilisateurs que le coût de briser 2048 -bit RSA cert en moins de 90 jours...

OPENSSL_TLS_SECURITY_LEVEL=3 nécessite au moins 3072 bits.

Et cela a une pertinence pourquoi? Il y a un niveau 5 qui impose une longueur de clé RSA minimale de 15360 bits, pourquoi s'arrêter à 3072 bits avec cette logique ?

Comme l'indique le document lié, la valeur par défaut est 1 , sauf configuration contraire. Connaissez-vous un logiciel grand public qui compile OpenSSL avec le niveau 3 ? La plupart du temps, lorsque OpenSSL est utilisé, il est lié à la copie du système, car vous souhaitez recevoir des mises à jour de sécurité sans dépendre de la mise à jour par chaque application de ses propres copies groupées (en supposant que le logiciel est régulièrement entretenu/mis à jour pour cela en premier lieu, ce qui ne se produit pas toujours dans ce scénario).

analysez les sites pour estimer la force de l'échange DH susceptible de se produire lorsqu'un client se connecte à chaque site

@schoen Chrome en 2016 a abandonné le support DHE , ils notent que 95% des connexions DHE étaient avec des paramètres DH 1024 bits. Cela ne devrait pas avoir beaucoup d'importance maintenant, car les navigateurs modernes ne prennent plus en charge les suites de chiffrement DHE.

Pour d'autres serveurs comme le courrier, cela pourrait encore être utile (bien que le support ECDHE ait été assez bon pendant un certain temps, certaines distributions Linux comme RHEL n'ayant pas de support jusqu'à 6.5 vers 2014). DHE doit utiliser les groupes FFDHE officiels de la RFC 7919, qui ont un minimum de 2048 bits. Aucun des anciens clients avec la limite de 1024 bits ne devrait avoir d'importance, pour les situations de niche où c'est le cas, l'administrateur système serait dans une position rémunérée pour y remédier, mais il y a une foule de problèmes de sécurité qui peuvent être rencontrés à ce stade, y compris la chaîne potentielle des problèmes de confiance dus à l'expiration des certificats racine sur un système.

Peut-être pouvons-nous penser à des mesures en cours pour encourager les utilisateurs à mettre à jour leurs navigateurs Web, afin d'augmenter la quantité de DH utilisée dans TLS.

Lorsque vous avez fait cette suggestion, Safari et Chrome n'offraient plus de DHE. Cela aurait le résultat inverse, réduisant le DHE, en supposant que les utilisateurs sont même en mesure de mettre à niveau les navigateurs/clients sur les appareils qui exécutent des logiciels obsolètes. Certains anciens systèmes d'exploitation ou logiciels sont verrouillés sur d'anciennes implémentations TLS (comme macOS / iOS Secure Transport), ce qui affecte la prise en charge de la version TLS, les suites de chiffrement prises en charge (macOS manquait d'AES-GCM jusqu'à la fin 2015 de la version IIRC).

En ce qui concerne quiconque pense que le RSA 2048 bits est insuffisant pour la protection de l'identité pendant 90 jours, en ignorant d'autres mesures de protection telles que les journaux OCSP et CT, connaissez-vous la chaîne de confiance ? Votre certificat est vérifié par rapport à la racine LetsEncrypt et aux certificats intermédiaires, si quelqu'un veut attaquer un certificat, il est plus utile de compromettre ceux que celui délivré à un site spécifique.

Si le certificat est utilisé uniquement pour l'authenticité et n'est pas compromis pour décrypter le trafic enregistré, vous pouvez augmenter la longueur de la clé de votre site Web autant que vous le souhaitez, mais que gagnez-vous en protection contre cette attaque théorique où vous êtes plus en sécurité qu'un précédent cert dans la chaîne de confiance est-il compromis ? (qui utilisent RSA 2048-bit, ~incluant la racine LE~ ( EDIT: My bad, LE RSA root is 4096-bit ), qui ont des périodes de validité beaucoup plus longues, 5 ans pour l'intermédiaire, et jusqu'en 2035 pour la racine LE)

Pourquoi ce problème est-il toujours ouvert ? Il est assez clair que les utilisateurs qui le demandent semblent mal comprendre la pertinence de TLS, surtout en 2020.

TL; DR

* RSA certs only matter for **proving the identity of the server can be trusted**, and are being **replaced every 90 days**. It won't be compromised due to key length of 2048-bit within that time just to impersonate you.

On dirait que vous ne comprenez pas mieux X.509 (et pas TLS :rofl:)… :rofl:
Cert n'est pas le problème mais la clé l'est. Et dans le monde X.509, il n'est pas possible de révoquer la clé… Ainsi, le roulement de 90 jours n'est pas toujours pertinent ici, et c'est un problème pour le serveur n'utilisant pas ECDHE/DHE mais simplement l'ancienne authentification RSA. Et c’est plutôt le cas aussi en 2020…

Vous comptez également mal pour la force RSA-2048. Vous devez calculer non seulement le moment où la meilleure façon actuelle de casser une clé donnée, mais aussi la future au moment où votre clé n'a plus de sens. En cas de non ECDHE/DHE (ce qui n'est, je le répète, pas si rare), ce n'est pas 90d mais 10-30y. Et ce n'est pas seulement le temps à prendre en compte, mais aussi le coût, l'évolution technologique et la découverte de failles/astuces cryptographiques. Et c'est particulièrement visible dans votre étui d'explication.
Le RSA-256 a été fissuré en ~60s sur un ordinateur portable standard à ~1000$ en 09/2019. Mais RSA-512 a été cracké en ~4h et ~75$ en 2015.
https://www.doyler.net/security-not-included/cracking-256-bit-rsa-keys
https://eprint.iacr.org/2015/1000.pdf
Il n'y a définitivement pas [insérer ici un grand nombre] de différence entre les deux, mais plus ou moins 1,8 à coût constant.
C'est également assez visible dans le benchmark cado-nfs pour la factorisation de la clé RSA. RSA-120 est 1.9h, RSA-130 est 7.5h (et non 81d comme prévu), RSA-140 est 23h (et non 227y) et RSA-155 est 5.3d (et non 7452 millenium).

C'est pourquoi des entités comme l'ANSSI ou le NIST basent leurs recommandations non seulement sur l'état actuel des capacités informatiques ou des connaissances en cryptographie, mais également sur les améliorations futures attendues dans le délai d'utilisation/signification de la clé.

c'est un problème pour le serveur qui n'utilise pas ECDHE/DHE mais simplement l'ancienne authentification RSA. Et c'est assez souvent le cas aussi en 2020

Donc, votre conseil pour améliorer la sécurité ici est d'encourager l'utilisation d'une taille de clé plus grande au lieu d'encourager les suites de chiffrement PFS uniquement ? Pourquoi?

Vous comptez aussi mal pour la force RSA-2048
Vous devez calculer non seulement le moment où la meilleure façon actuelle de casser une clé donnée, mais aussi la future au moment où votre clé n'a plus de sens

Veuillez élaborer davantage. Dans quel cas savez-vous qu'au cours de la dernière décennie cela a été faux. Il n'y a aucun cas connu de RSA 1024 bits factorisé/cassé, sans parler de 2048 bits qui a 2 ^ 32 bits de plus d'entropie en regardant sa force de clé symétrique.

1. Le RSA 2048 bits est environ 4 milliards de fois plus puissant que le RSA 1024 bits.
2. 3072 bits n'est que ~ 65 000 fois plus puissant (lorsque l'on compare 112 bits à 128 bits de sécurité symétrique telle que définie officiellement par le NIST).
3. Si nous supposons que 1024 bits (force de clé symétrique de 80 bits) peuvent être compromis dans l'espace d'un an de puissance de calcul. C'est 4 milliards d'années pour 2048 bits.
4. Vous prétendez qu'une avancée technologique inconnue pourrait réduire considérablement ce temps de calcul, mais ne menacerait pas le RSA 3072 bits ?

Nous pourrions comparer 1024 bits comme cassables en 1 seconde, alors 2048 bits équivaut à 136 ans encore ( (1/31536000) * 2^32 ). Une telle réalisation est loin de se produire, si vous voulez insister sur le fait que c'est en quelque sorte une préoccupation valable, savez-vous que même 512 bits sont pris en compte en 1 seconde ? Le RSA 512 bits a été factorisé pour la première fois sur 6 mois en 1999 , depuis 2015, il existe un projet Github (FaaS) qui vous permet de tirer facilement parti d'AWS pour moins de 100 $ et quelques heures pour factoriser le RSA 512 bits.

Dans cet esprit, RSA 1024 bits étant d'environ 2 ^ 28 (~ 250k) à 2 ^ 30 (1 milliard) fois plus difficile (je n'ai pas de chiffres exacts désolé, mais semble être autour de cela), et les universitaires actuels étant encore loin de cela, je ne sais pas comment vous pensez que le RSA 1024 bits est sur le point d'être calculé aussi rapidement, ce qui devrait être avant que le RSA 2048 bits soit même quelque chose à craindre d'être cassé de cette manière .

L'approche habituelle ici est GNFS (General Number Field Sieve), qui devient plus irréalisable avec les ressources requises, plus la taille de la clé est grande . Il y a aussi ce joli tableau de l'histoire de l'affacturage RSA , et une réponse connexe qui a épinglé le RSA 2048 bits à être factorisé d'ici 2048 sur cette base, et 1024 bits d'ici 2015-2020, ce qui n'a pas encore été atteint sur le plan académique.

Compte tenu de ce qui précède, j'aimerais que vous souteniez comment RSA 3072 bits offre beaucoup plus d'avantages de sécurité supplémentaires. Si le RSA 2048 bits est attaqué d'une autre manière ou progresse à un tel rythme technologiquement, alors je ne vois pas comment le RSA 3072 bits offrirait une protection supplémentaire ?

En cas de non ECDHE/DHE (ce qui n'est, je le répète, pas si rare)

J'aime la façon dont vous prétendez que ce n'est "pas si rare", dans quelle mesure est-il courant que votre poignée de main utilise un échange de clés RSA au lieu de DHE ou ECDHE ces jours-ci ? Avez-vous même un exemple?

ce n'est pas 90d mais 10-30y

Je pense avoir été assez clair en indiquant une période de renouvellement de 90 jours pour le certificat alors que son objectif était uniquement de servir l'authentification, pas l'échange de clés.

Et ce n'est pas seulement le temps à prendre en compte, mais aussi le coût, l'évolution technologique et la découverte de failles/astuces cryptographiques. Et c'est particulièrement visible dans votre étui d'explication.

Oui, coût. Je vous ai lié pour citer RSA 1024 bits nécessitant des téraoctets de RAM pour exécuter GNFS, l'étape de réduction linéaire étant la partie la plus coûteuse/difficile à gérer. C'est la chose avec une difficulté exponentielle, quelque chose qui est bon marché/facile peut monter en difficulté très rapidement.

Le RSA-256 a été fissuré en ~60s sur un ordinateur portable standard à ~1000$ en 09/2019. Mais RSA-512 a été cracké en ~4h et ~75$ en 2015.

J'ai déjà lié au projet Github qui peut effectuer l'affacturage 512 bits sur AWS. Je ne connais pas la quantité exacte de bits d'entropie symétrique de RSA 256 bits, peut-être environ 30 bits? (donc environ 1 048 576 fois la différence entre RSA 512 bits). L'article 512 bits auquel vous liez mentionne 432 processeurs (12 instances avec 36 vCPU + 60 Go de RAM chacune) et un total de 2770 heures de processeur avec 1,5 à 2 Go de mémoire ou de stockage pour la matrice (je ne connais pas trop ce calcul, si vous êtes n'hésitez pas à intervenir).

Mes calculs sont probablement mauvais ici, mais essayons de comparer la puissance de calcul des deux systèmes en fonction de ces informations, 2770 heures en minutes seraient 2770 * 60 = 166200 que nous pouvons comparer à 1 minute du RSA 256 bits comme log2(166200) = 17.34 , ~2^17, pas trop loin de l'estimation 2^20, et comme je ne connais pas les bits symétriques exacts pour l'un ou l'autre, cela peut être assez précis, avec une marge de manœuvre pour des améliorations de la technologie et des algorithmes , mais rien de choquant ?

En 1991, le RSA 330 bits a été pris en compte en quelques jours , un seul processeur Intel Core2Duo plus tard pouvait le gérer en un peu plus d'une heure. Le RSA 256 bits aurait été inférieur à cela alors, donnons-lui 60 minutes optimistes et disons qu'en ~ 30 ans, il est descendu à ~ 1 minute, une grande réduction de 60 fois. Cela équivaut à dire 2^6 (64)... 6 bits. Comme indiqué précédemment, compte tenu du temps, et non des ressources comme l'augmentation des besoins en RAM, c'est encore loin d'être une menace valable. Supprimez 6 bits supplémentaires au cours des 30 prochaines années et vous avez réussi à factoriser 1 seconde de RSA 256 bits, félicitations, un long chemin à parcourir pour atteindre RSA 2048 bits dans un délai raisonnable.

Même les 15 ans pour le RSA 512 bits passant de 6 mois à 4 heures sont 24hr * (6month * 30day) = 4320hr / 4hr = log2(1080hr) = 10 ~2^10. C'est certainement mieux qu'une réduction, ~ 1 000 fois mieux, mais ce n'est toujours pas un taux alarmant en comparaison. Je pense que cela est encore confirmé par le ralentissement des progrès, les universitaires étant capables de prendre en compte des tailles de clé RSA plus importantes.

C'est également assez visible dans le benchmark cado-nfs pour la factorisation de la clé RSA. RSA-120 est 1.9h, RSA-130 est 7.5h (et non 81d comme prévu), RSA-140 est 23h (et non 227y) et RSA-155 est 5.3d (et non 7452 millenium).

D'où proviennent ces temps de calcul attendus ? RSA-155 (alias RSA 512 bits) a été pris en compte il y a 6 mois en 1999 , RSA-120 (RSA 397 bits) et RSA-130 (RSA 430 bits) ne sont probablement qu'environ 1-2 bits symétriques différents ? Donc une augmentation d'environ 4 fois est à prévoir...?

C'est pourquoi des entités comme l'ANSSI ou le NIST basent leurs recommandations non seulement sur l'état actuel des capacités informatiques ou des connaissances en cryptographie, mais également sur les améliorations futures attendues dans le délai d'utilisation/signification de la clé.

Vous n'avez rien fourni de substantiel qui indique que le RSA 2048 bits est proche de la faiblesse, même avec un contexte historique où des améliorations notables ont été apportées, cela ne semble pas si pertinent avec l'augmentation exponentielle. Vous semblez adopter une vision un peu linéaire? J'espère que vous savez pourquoi l'AES 128 bits est considéré comme sécurisé (apparemment peut être faible pour un ordinateur quantique un jour en utilisant l'algorithme de Grover) et que l'AES 256 bits nécessiterait toute l'énergie de notre système solaire pour être épuisé de craquer par la force brute.

De plus, tenez compte des données sensibles que vous essayez de protéger sans tenir compte des meilleures pratiques comme l'utilisation uniquement de suites de chiffrement compatibles PFS, où ces données sont également considérées comme problématiques pour être potentiellement déchiffrées dans plusieurs décennies (un peu de les données sensibles ne seront plus aussi importantes dans des décennies qu'elles ne le sont aujourd'hui).

TL; DR

Cela revient à peu près à cela. Briser 2048 bits, même dans des décennies, coûtera toujours ridiculement cher, mais soyons optimistes et disons 1 million de dollars et 10 ans (ou 1 si vous préférez).

• Cet attaquant s'intéresse-t-il spécifiquement à vous en ce moment qu'il va être équipé pour enregistrer le trafic de vos serveurs pour N utilisateurs (où N n'a pas d'importance au-delà des exigences de stockage, puisque vous utilisez de toute façon de manière non sécurisée la même clé pour tout chiffrement) .
• Ce trafic va être enregistré pendant X années, où tous les 90 jours votre certificat change nécessitant une attaque distincte pour chacun (temps et $$$$) ? Ou l'attaquant sait-il à l'avance quand enregistrer les données spécifiques qui l'intéressent, même s'il lui faudra plusieurs décennies avant de croire qu'il peut casser le cryptage ?
• C'est en quelque sorte une meilleure stratégie et moins chère que de pirater directement votre serveur ou votre client utilisateur et de compromettre ce système (je veux dire qu'ils se sont déjà lancés dans une attaque MitM pour capturer le trafic et sont déterminés à accéder à vos secrets avec un financement adéquat de toute façon, n'est-ce pas ? ), n'auraient-ils pas les ressources disponibles pour choisir l'attaque la plus pratique ?
• Ne serait-il pas moins cher et plus facile de menacer ou de faire chanter quelqu'un directement pour avoir accès à la clé privée RSA ? Ensuite, la longueur de la clé n'a pas d'importance, si vous étiez intelligent et n'utilisiez que des suites de chiffrement PFS, cette stratégie ne serait pas pertinente.

Sooo fondamentalement ...

Encourager les suites de chiffrement PFS (DHE / ECDHE) et non des améliorations mineures pour panser les mauvaises pratiques de sécurité

Donc, votre conseil pour améliorer la sécurité ici est d'encourager l'utilisation d'une taille de clé plus grande au lieu d'encourager les suites de chiffrement PFS uniquement ? Pourquoi?

Parce que LE a la main sur la taille de clé par défaut, pas sur la configuration httpd. Et LE a déjà pris des mesures dans le passé (désactivation de https sur HTTP-01, suppression de TLS-SNI-01…) au lieu d'appliquer la configuration httpd.

Veuillez élaborer davantage.

Sûr. Et simple voir le benchmark de cado-nfs. Le temps de fissuration n'est pas le temps théorique attendu.
L'écart de difficulté théorique n'est pas observé en pratique à cause de deux biais. On ne peut que comparer le temps de crack pour un état de l'art donné et au même temps courant et s'attendre à l'écart théorique (et en pratique, ce n'est pas le cas, voir cado-nfs), mais rien n'assure que X+1 bits vaut 2 fois plus difficile que X si l'on compare les connaissances et la puissance de calcul actuelles et ce que nous aurons 1 mois plus tard.
Et voir aussi les 2 exemples que je donne. Il n'y a qu'un écart de 2 fois entre le crack de 256 et 512 bits entre 2015 et 2019 étant donné la même puissance et les mêmes coûts, alors qu'en théorie il y a un écart de 10⁷⁷ fois.
Et nous ne sommes pas en mesure de garantir qu'il n'y aura pas demain une astuce de rupture RSA 3072 où 4096 bits resteront plus sûrs.

J'ai déjà lié au projet Github qui peut effectuer l'affacturage 512 bits sur AWS. Je ne connais pas la quantité exacte de bits d'entropie symétrique de RSA 256 bits, peut-être environ 30 bits? (donc environ 1 048 576 fois la différence entre RSA 512 bits). L'article 512 bits auquel vous liez mentionne 432 processeurs (12 instances avec 36 vCPU + 60 Go de RAM chacune) et un total de 2770 heures de processeur avec 1,5 à 2 Go de mémoire ou de stockage pour la matrice (je ne connais pas trop ce calcul, si vous êtes n'hésitez pas à intervenir).

Ouais, ça a l'air d'être un nombre énorme et peu pratique… A l'époque de la première rupture du 512 bits (1999), c'était considéré comme peu pratique car nécessitant un super-ordinateur dont personne ne dispose. Mais en fait, la facture AWS correspondante pour une telle infrastructure en 2015 est de… 100 $ pour 4h et EST pratique quelques années plus tard, largement plus rapide que l'écart de milliards de milliards de milliards prévu en 1999.
https://arstechnica.com/information-technology/2015/10/breaking-512-bit-rsa-with-amazon-ec2-is-a-cinch-so-why-all-the-weak-keys/

Il n'y a qu'un écart de 2 fois entre le crack de 256 et 512 bits entre 2015 et 2019 étant donné la même puissance et les mêmes coûts, alors qu'en théorie il y a un écart de 10⁷⁷ fois.

Quoi non. Je vous ai été très clair à ce sujet dans mes messages que la différence entre 256 bits et 512 bits n'est pas 2 ^ 256 (votre base 10, 10 ^ 77), mais plutôt 2 ^ 20 ou moins (dans le comparaison que j'ai faite de vos deux exemples de factorisation cités, c'était environ 2 ^ 17).

Je ne sais pas non plus comment vous revendiquez un "écart de 2 fois" ? Même puissance et mêmes coûts ? Le RSA 256 bits a été factorisé en environ 1 minute, le RSA 512 bits équivalant à 166 200 minutes (les calculs ont été cités dans mon article précédent, n'hésitez pas à me corriger si j'ai fait une erreur).

Et nous ne sommes pas en mesure de garantir qu'il n'y aura pas demain une astuce de rupture RSA 3072 où 4096 bits resteront plus sûrs.

Vous allez littéralement être bien avec RSA 2048 bits, RSA 3072 bits a une amélioration "marginale" de la sécurité, je l'ai déjà expliqué, vous semblez l'avoir sauté ou mal compris ? La seule façon dont le RSA 2048 bits devient non sécurisé dans un laps de temps beaucoup plus court est lorsque votre RSA 3072 bits va être menacé par le taux d'avancement.

Si vous voulez être plus sûr, n'utilisez pas RSA pour l'échange de clés. Je vous ai demandé de citer un site Web où l'échange de clés RSA est requis ((EC)DHE non pris en charge/négocié pour une raison quelconque), pourquoi n'avez-vous pas été en mesure de répondre à cela, vous avez affirmé que c'est un phénomène si courant qu'il justifie l'augmentation du longueur de clé RSA par défaut ? Veuillez confirmer cette déclaration. Vous pouvez trouver des serveurs qui offrent RSA comme échange de clés, ils auront probablement activé la sélection de suite de chiffrement de serveur et cela ne sera négocié par aucun client qui peut prendre en charge les suites de chiffrement PFS.

Mais en fait, la facture AWS correspondante pour une telle infrastructure en 2015 est de… 100 $ pour 4h et EST pratique quelques années plus tard, largement plus rapide que le milliard de milliards de milliards d'écart prévu en 1999.

Le coût du matériel est considérablement plus élevé que 100 $, ce qui n'est pas ridicule, mais oui, la possibilité de louer/d'accéder facilement à des ressources informatiques comme celle-ci l'a rendu plus accessible. Notez le matériel utilisé, ce n'était pas des instances EC2 bon marché/petites, c'étaient des machines assez grosses en ce qui concerne la location de ressources de calcul, nous avons pris en compte RSA 768 bits depuis plus d'une décennie maintenant, mais vous ne voyez pas FaaS être capable de gérer cela à moindre coût? Le RSA 2048 bits est un long chemin à parcourir.

Avez-vous une source de quelqu'un prétendant que 512 bits nécessitaient plus d'un milliard de calculs ? Je suis presque sûr que les ressources matérielles en 1999 qui ne représentaient que 6 mois étaient loin de coûter même des milliards. D'où vient ce prix ? De déclarations plus récentes sur des éléments de sécurité plus élevés ? Cela est dû à l'augmentation exponentielle de la difficulté, qui nécessite non seulement plus de temps de calcul, mais aussi d'autres ressources comme la RAM. Ces instances AWS de factorisation RSA 512 bits disposaient chacune de 60 Go de RAM (720 Go au total)...

Aperçu rapide de quelques informations sur le traitement :

RSA-250 (RSA 829 bits) qui a été factorisé en 2020 a été atteint en 3 mois avec des dizaines de milliers d'ordinateurs et en utilisant CADO-NFS que vous aimez évoquer, il semble qu'ils aient atteint la factorisation ~ à peu près le même temps de calcul ~ ( EDIT : mon erreur, des années, pas des heures) que la factorisation AWS de RSA 512 bits en 2015 (environ 2 700 heures de processeur, normalisé AFAIK sur un Intel Xeon Gold 6130 2,1 GHz référencé). RSA-240 (RSA 795 bits) factorisé en décembre 2019 est intéressant en ce qu'il a été réalisé par la même équipe et sur le même matériel qui a factorisé RSA 768 bits en 2010/2016 (utilisant également CADO-NFS). Ils ont noté des améliorations d'algorithme dans le logiciel CADO-NFS puisque c'est ce qui a permis un gain de performances d'environ 3 fois.

Voici l'article sur la factorisation 2010 de RSA 768 bits , regardez les besoins en RAM :

La première étape a été divisée en huit tâches indépendantes exécutées en parallèle sur ces clusters, chacune des huit séquences faisant un point de contrôle une fois toutes les 214 étapes. L'exécution d'une séquence de premier (ou troisième) étage nécessitait 180 Go de RAM , un seul ¯b de 64 bits de large prenait 1,5 gigaoctets et une seule matrice mi 8 kilooctets, dont 565 000 étaient conservés, en moyenne, par séquence de premier étage. Chaque somme partielle lors de la troisième étape d'évaluation a nécessité 12 gigaoctets .

La plupart du temps, les 896 Go de RAM disponibles suffisaient, mais pendant une partie centrale du calcul, plus de mémoire était nécessaire (jusqu'à environ 1 To)

Et comparons cela à la factorisation RSA 512 bits (2009, pas celle d'AWS en 2015) :

En 2009, Benjamin Moody pouvait factoriser une clé RSA-512 bits en 73 jours en utilisant uniquement un logiciel public (GGNFS) et son ordinateur de bureau (un Athlon64 double cœur avec un processeur de 1 900 MHz). Un peu moins de cinq gigaoctets de stockage sur disque étaient nécessaires et environ 2,5 gigaoctets de RAM pour le processus de tamisage.

Cela devrait donner une échelle approximative des besoins en RAM à mesure que la longueur de la clé augmente. Je suis sûr qu'il y a probablement d'autres goulots d'étranglement dont il faut être conscient avec le traitement, en particulier lorsqu'on le fait de manière distribuée. N'hésitez pas à approfondir cela et à identifier la quantité de RAM nécessaire pour attaquer RSA 2048 bits.

Contre qui essayez-vous réellement de vous protéger et qui est équipé pour vous cibler ou cibler spécifiquement le trafic de vos utilisateurs afin de l'enregistrer et d'effectuer une attaque dans des décennies ?

Pas un script kiddy attendant une solution AWS à 100 $, ils seraient passés à de meilleures choses d'ici là et compromettre votre réseau pour enregistrer le trafic leur coûterait beaucoup plus cher, sinon c'est un malware où personne en particulier n'a été ciblé, félicitations vos données enregistrées segmentées dans des périodes de trafic de 90 jours par clé RSA est maintenant dans une mer de beaucoup d'autres, des milliers, des millions peut-être, 100 $ AWS même si possible ne serait pas très bon marché pour attaquer tout cela, surtout lorsque les données ont une valeur inconnue, il y aurait un beaucoup de bric-à-brac pour gaspiller de l'argent.

Non, si quelqu'un veut vos secrets, il existe des moyens plus abordables.

Pour une raison quelconque, vous pensez qu'une sécurité 4 milliards de fois plus forte de 1024 bits à 2048 bits RSA est inadéquate, mais 65 000 fois plus de sécurité de 2048 bits à 3072 bits RSA est adéquate. Votre argument est que la théorie de la sécurité selon laquelle 2048 bits sont sûrs en termes de calcul n'est pas valide, mais certains comment cette même logique pour RSA 3072 bits ne s'applique pas et c'est beaucoup plus sûr? Une porte en verre est-elle plus sûre parce que j'ajoute des serrures plus grandes et plus sûres ?

TL; DR

S'il vous plaît, passez en revue le TL précédent; DR, mais je vais réitérer ..

• Quelqu'un veut enregistrer votre trafic crypté à l'aide d'une clé RSA faible de 2048 bits.
• Ils sont capables d'effectuer cette attaque MitM, ils ont donc des compétences ou de l'argent et c'est probablement une attaque ciblée.
• Vos données doivent conserver à l'avenir leur valeur qu'il est souhaitable d'acquérir maintenant, même si elles ne peuvent être décryptées que dans plus de 20 ans selon vos estimations.
• L'attaque doit être justifiable pour le coût à réaliser pour obtenir la valeur du secret, il faut savoir quelle fenêtre de 90 jours capturer, sinon l'attaque doit être calculée plusieurs fois dans l'espoir d'acquérir ledit secret.
• Cette attaque est en quelque sorte plus efficace que toute autre méthode pour acquérir lesdites données de manière plus rapide/moins chère ?

Qui sensé va faire ça ? Cela ne sera pratique que sur une cible de grande valeur où aucun autre moyen d'obtenir cette information n'est viable. Ladite cible est en quelque sorte en possession de secrets aussi précieux mais ne prend pas la peine de payer un professionnel ou de considérer les meilleures pratiques pour les sécuriser (ils ne peuvent apparemment pas configurer un serveur avec un copier/coller des conseils de la suite de chiffrement de Mozilla).

Ce n'est pas très convaincant. Ce n'est pas LetsEncrypt, vous supposez qu'un utilisateur avec des secrets précieux utilise Certbot avec RSA uniquement les suites de chiffrement d'échange de clés prises en charge par leur serveur (aucune configuration par défaut ne le fait), et que RSA 2048 bits est tellement plus faible qu'il ne l'est ? Quel que soit cet utilisateur, leurs pratiques de sécurité ailleurs sont probablement suffisamment faibles pour les compromettre directement, pourquoi attendre 20 à 30 années supposées pour décrypter les données alors que vous pouvez effectuer une attaque active et obtenir toutes les données juteuses du présent ?

La bonne solution consiste à configurer correctement les suites de chiffrement, et ce projet Certbot fait exactement cela si vous êtes inexpérimenté dans le domaine et que vous souhaitez compter sur lui pour s'en occuper pour vous. Mais pour une raison quelconque, cela ne s'applique pas à cette discussion ?

Je vous ai demandé de citer un site Web où l'échange de clés RSA est requis ((EC)DHE non pris en charge/négocié pour une raison quelconque)

https://cryptcheck.fr/https/bankofamerica.com (oui, vous avez bien lu)
https://cryptcheck.fr/https/caf.fr (administration d'état pour la France, équivalent du US Supplement Security Income)
https://cryptcheck.fr/https/xn--trkiye-3ya.gov.tr
https://cryptcheck.fr/https/pfisng.dsna-dti.aviation-civile.gouv.fr
https://cryptcheck.fr/https/reader.xsnews.nl
https://cryptcheck.fr/https/protecpo.inrs.fr
https://cryptcheck.fr/https/tiscali.it

Je compte 68 domaines non PFS sur mon CryptCheck v2 sur 7221 analyses de poignées de main (~0,9%) et 2091 sur 349961 analyses de poignées de main (~0,6%) sur ma v1.

https://www.bankofamerica.com/

Protocole : TLS 1.2
Échange de clé : ECDHE_RSA
Groupe d'échange de clés : P-256
Chiffre : AES_128_GCM
AC : confier

https://cryptcheck.fr/https/bankofamerica.com est censé identifier des IP de serveur supplémentaires pour le même domaine qui ne fournissent pas l'échange de clés ECDHE ?

https://www.caf.fr/

Protocole : TLS 1.2
Échange de clés : RSA
Chiffre : AES_128_CBC avec HMAC-SHA1
CA : Certification

Je n'ai aucune idée de ce qu'est ce site Web ou des secrets sensibles qu'il doit exploiter ?

https://www.turkiye.gov.tr/

Protocole : TLS 1.2
Échange de clés : RSA
Chiffre : AES_128_CBC avec HMAC-SHA1
Autorité de certification : GlobalSign

J'ai été redirigé vers cela à partir de votre nom de domaine étrange que je ne peux pas imaginer que quelqu'un visiterait directement et le considérerait légitime / digne de confiance d'un nom.

Ceci, comme beaucoup d'autres suivants, est clairement un site Web du gouvernement. Ils sont souvent à la traîne et doivent être accessibles à un large public, RSA ne devrait cependant pas être l'échange de clés par défaut, mais encore une fois, de quelles communications se produisent ici dont vous voulez vous protéger ? Le gouvernement lui-même ne semble pas trop inquiet évidemment.

https://pfisng.dsna-dti.aviation-civile.gouv.fr/jts/auth/authrequired

Protocole : TLS 1.2
Échange de clés : RSA
Chiffre : AES_128_GCM
CA : Certification

Encore une fois, aucune idée de ce que c'est autre qu'un service gouvernemental avec connexion. Existe-t-il des informations sensibles au-delà des informations de connexion ? Quelles sont les préoccupations ici concernant l'accès aux informations sensibles dans 20 à 30 ans ? Que j'utilise le même nom d'utilisateur et mot de passe ailleurs et que je continue à le faire dans 20 à 30 ans ?

Une escroquerie par hameçonnage ne serait-elle pas aussi efficace si les informations de connexion étaient souhaitées (et la valeur des données sur les comptes). Cela pourrait-il être réalisé dans un délai plus court ou avec un budget inférieur à celui d'attaquer le certificat RSA ?

https://reader.xsnews.nl/

Plus d'une minute passée à essayer de charger/résoudre l'URL, je n'ai pas pu accéder à ce site Web.

https://protecpo.inrs.fr/ProtecPo/jsp/Accueil.jsp

Protocole : TLS 1.2
Échange de clés : RSA
Chiffre : AES_128_GCM
CA : GÉANT

Cela semble être un site Web pour certains logiciels que vous pouvez utiliser pour vous aider à prendre une décision d'achat. Quelles informations sensibles sont en danger ici ?

https://www.tiscali.it/

Protocole : TLS 1.2
Échange de clés : RSA
Chiffre : AES_256_CBC avec HMAC-SHA1
CA : Thawte

Un site d'actualités ? Encore une fois, quelles informations sensibles sont concernées par l'interaction avec ce site ?

Résumé

Aucun de ces résultats n'indique la nécessité de protéger les communications sensibles au-delà des 20 à 30 ans estimés de RSA 2048 bits compromis. Ces sites Web nécessiteraient toujours une attaque MitM efficace pour capturer ce trafic entre le client et le serveur, ce qui n'est probablement pas une préoccupation valable pour aucun d'entre eux ?

Aucun d'entre eux n'utilise les certificats émis par LetsEncrypt. Faire un changement pour Certbot n'est bénéfique que si vous savez avec certitude que ces sites Web utilisent Certbot spécifiquement en tant que client ACME pour ces autorités de certification (en supposant qu'ils disposent d'un support ACME tiers).

Merci d'avoir signalé certains sites Web où RSA est l'échange de clés négocié (à l'exception de Bank of America qui semble être incorrect et n'a été validé que comme suite de chiffrement sur un site Web public, et non sur de véritables échanges sensibles).

Je compte 68 domaines non PFS sur mon CryptCheck v2 sur 7221 analyses de poignées de main (~0,9%) et 2091 sur 349961 analyses de poignées de main (~0,6%) sur ma v1.

Ok, donc votre "pas rare" est inférieur à 1% des 7 221 et 349 961 sites Web que vous avez scannés avec CryptCheck ? Considérez maintenant l'audience et la valeur mesurable réelle offerte par l'utilisation de RSA 3072 bits à la place pour sécuriser ces communications, est-ce que cela sécurise réellement quelque chose de valable et serait-il plus sûr contre des alternatives moins chères pour compromettre la sécurité ? (comme dans, était 2048 bits plus faible/moins cher que toute autre attaque ciblée alternative, où 3072 bits augmente la limite inférieure de l'attaque)

Parmi les 1 million de sites Alexa les plus importants, combien négocient l'échange de clés RSA ? Combien de ceux trouvés utilisent LetsEncrypt comme autorité de certification ?

J'ai calculé des bits symétriques pour RSA 512 bits et 256 bits (basé sur l'équation du NIST), et nous obtenons 40 bits (RSA 256 bits) et 57 bits (RSA 512 bits).

Fait intéressant, cela correspond à la différence de 17 bits citée précédemment lors de la comparaison des deux calculs avec les avancées récentes (il semble que le document NIST auquel j'ai fait référence a été mis à jour pour la dernière fois en 2020).

Il révèle également que la distance au RSA 1024 bits n'est que de 23 bits de force de clé symétrique équivalente, 8 388 608. Et nous pouvons voir que les progrès actuels pour RSA 768 bits et 795 bits ou le record actuel de RSA 829 bits sont :

768 == 69.74588053597235
795 == 70.91595938496408
829 == 72.35600867501326

• Enregistrement RSA 768 bits depuis 2010 avec RSA 829 bits comme record en 2020, moins de 3 bits d'amélioration sur une période d'une décennie. 2000 vs 2700 années CPU (monocœur). Le RSA 795 bits était tombé à 900 années CPU en novembre 2019.
• 57 bits (512 bits RSA) à 72 bits (829 bits RSA) avec ~2 700 heures de calcul~ ( EDIT : heures vs années, oups) entre 2015 et 2020. ~15 bits (32 768) d'amélioration~ ? (Le RSA 829 bits a pris 3 mois et des dizaines de milliers de machines en comparaison). Les factorisations RSA 768 bits (décembre 2009) et 795 bits (novembre 2019) ont mis en évidence qu'elles étaient environ 3 fois plus rapides en raison des seules améliorations logicielles/algorithmes.
• 2^6 (64) estimation pour l'amélioration RSA 256 bits depuis 1991.
• ~ 2 ^ 10 (1024) pour la différence de 1080 x avec 512 bits sur 16 ans (1999 - 2015) 6 mois contre 4 heures, la précision d'une comparaison n'est pas claire, 8 000 ans MIPS contre 2770 ans du processeur Intel généralement référencé. Le principal diff ici était probablement dû à l'accès à la location de matériel à moindre coût avec le cloud computing pour réduire le temps, tout en tirant parti de 15 ans d'améliorations matérielles et d'améliorations d'algorithmes apportées au logiciel depuis.

Je viens de réaliser que j'ai commis une erreur plus tôt en citant l'affacturage RSA 829 bits et en le comparant au temps d'affacturage RSA AWS 512 bits. Ils citent tous les deux environ 2700 unités de temps de calcul, mais j'ai trébuché avec un RSA 829 bits représentant des années et un RSA 512 bits représentant des heures. Cela semble être une différence d'environ 8 760 ( (8760hrs * 2700yrs) / 2700hrs , où 8 760 sont des heures dans une année) fois (2 ^ 13) ce qui, je pense, est de 4 ans ( (4hrs * 8760hrs) / 24hrs / 365days ) ce qui serait proche de un million de dollars de temps de calcul sur AWS ? (en ignorant le fait que vous avez probablement besoin d'un peu plus de RAM)

Temps de calcul RSA 256 bits 1 minute vs temps de calcul RSA 829 bits 2700 ans = log2(525600mins * 2700yrs) (minutes par an) équivaut à environ 2^30. Encore une fois, similaire à la difficulté de calcul RSA 512 bits, c'est assez proche d'un delta par rapport à la différence de force supposée de 2 ^ 32 bits. Nous pourrions peut-être factoriser les clés RSA plus rapidement, mais la difficulté de calcul semble être à peu près maintenue ?

Pas la meilleure information, mais suffisamment pour que nous ayons une idée approximative du rythme des progrès et des améliorations.

• La difficulté à calculer est-elle à peu près précise et cohérente sur des décennies ?
• Le taux d'amélioration des calculs pour effectuer l'affacturage plus rapidement s'est bien amélioré, mais pas de manière significative ?

Le 1024 bits restera encore hors de portée pendant un certain temps, et le 2048 bits encore plus sur la base des progrès historiques couverts ci-dessus. Il y a peu de preuves que le RSA 3072 bits avec ses 2 ^ 16 (65k) à 2 ^ 22 (4 millions) bits supplémentaires de difficulté supplémentaire représentera un avantage de sécurité beaucoup plus important que le 2 ^ 30 (1 milliard) à 2 ^ 32 (4 milliards) 2048 bits ont plus de 1024 bits RSA. (non pas que cela n'ajoute pas de difficulté supplémentaire notable, mais sur la base de l'hypothèse que le RSA 2048 bits lui-même ne résistera pas suffisamment quand il le devrait)

Basé sur l'effort RSA 829 bits actuel, et qu'il y a une différence d'environ 38 bits par rapport au niveau de sécurité des bits pour RSA 2048 bits. Si nous prenons la puissance de calcul constante qui a pris en compte le RSA 829 bits en 3 mois (4 durées de trois mois dans un an), nous obtenons 68 719 476 736 ans ( 2^38 / 4 ), même si nous avons eu des progrès pour réduire cela à 1 un milliard de fois moins de travail (2^30), ça fait quand même environ 64 ans, et c'est avec des dizaines de milliers de machines .

Si vous pensez toujours que 3072 bits au minimum en vaut la peine malgré mes mathématiques (peut-être mauvaises?), mon analyse coûts-avantages et mon raisonnement de bon sens ... alors je ne pense pas avoir autre chose que je puisse contribuer pour vous convaincre autrement .

N'oubliez pas que vous préconisez un changement avec Certbot, et non LetsEncrypt appliquant un minimum à émettre. Certbot aide déjà les utilisateurs en configurant des suites de chiffrement appropriées qui évitent tout le problème de toute façon, alors qui va vraiment en bénéficier ici - tandis que tous les autres (utilisant Certbot) qui n'utilisent pas RSA comme échange de clés ajoutent plus de charge et de bande passante sur leurs serveurs (même s'ils sont mineurs pour la plupart).

Le problème devrait être clos.

https://www.keylength.com/

https://www.keylength.com/

Vous avez déjà fourni cette information il y a 4 ans dans ce fil . Il ne semble pas que vous compreniez le contexte des conseils de ce site Web et comment ils s'appliquent ici.

Si vous vous sentez plus à l'aise avec RSA 3072 bits ou des longueurs de clé plus grandes pour vos certificats, optez explicitement pour ce que vous pouvez déjà, il n'y a aucune raison justifiée, lorsque vous vous souciez de la sécurité pragmatique, d'adopter 3072 bits comme nouvelle valeur par défaut . RSA 2048 bits est suffisant .

Vous avez déjà fourni cette information il y a 4 ans dans ce fil . Il ne semble pas que vous compreniez le contexte des conseils de ce site Web et comment ils s'appliquent ici.

Vous ne comprenez pas plus. L'avis de l'ANSSI est par exemple

Dans le cadre du développement des téléservices et des échanges électroniques entre l'administration et les usagers, les autorités administratives doivent garantir la sécurité de leurs systèmes d'information en charge de la mise en œuvre de ces services.
Le Référentiel Général de Sécurité s'impose spécifiquement aux systèmes d'information mis en œuvre par les autorités administratives dans leurs relations entre elles et dans leurs relations avec les usagers (il s'agit des téléservices comme le paiement des amendes à l'Administration).
Indirectement, le Référentiel Général de Sécurité s'adresse à tous les prestataires qui assistent les autorités administratives dans la sécurisation des échanges électroniques qu'ils mettent en œuvre, ainsi qu'aux fabricants dont l'activité est de proposer des produits. de sécurité.
De manière générale, pour tout autre organisme souhaitant organiser la gestion de la sécurité de ses systèmes d'information et des échanges électroniques, le Référentiel Général de Sécurité se présente comme un guide de bonnes pratiques conforme à l'état de l'art.

Et donc est applicable en France pour tout usage et tout moyen , et n'est pas du tout limité à un contexte sensible comme un objectif militaire.

Et l'un des conseils est "Il est recommandé d'utiliser des modules d'au moins 3072 bits, même pour une utilisation ne dépassant pas 2030 ". Et 3072 bits n'est plus un conseil mais est obligatoire si utilisation/impact prévu après 2030.

Même la CNIL, entité française sur la vie privée et les bonnes pratiques, utilise le document ANSSI dans sa recommandation standard pour tout site Web : https://www.cnil.fr/fr/securite-securiser-les-sites-web

L'ANSSI a publié sur son site des recommandations spécifiques pour la mise en place de TLS ou pour la sécurisation d'un site internet.

(Et est également en opposition avec Let's Encrypt car indiquant que vous devez you must authorize only incoming IP network flows on this machine on port 443 and block all the other ports. mais ceci )

Les conseils du NIST ne sont pas liés à la sensibilité de la transmission des informations, mais ce sont des conseils généraux applicables dans presque tous les cas où vous devez également gérer une clé ou un certificat.

Ce n'est pas la première fois que LE utilise la configuration par défaut en opposition avec les conseils de pointe d'une agence gouvernementale ou autre…

Oh, et le BSI l'examine le conseille cette année. Il déclare que

Remarque importante : Il est raisonnable d'utiliser une longueur de clé de 3000 bits pour RSA , DH et DSS, afin d'atteindre un niveau de sécurité homogène pour tous les mécanismes asymétriques. À partir de 2023, une longueur de clé d'au moins 3000 bits est requise pour les implémentations cryptographiques qui doivent se conformer à la présente directive technique.

@aeris même si la France imposait le RSA 3072 bits comme obligatoire, ce n'est pas la loi ailleurs. Notez que les conseils et les recommandations ne correspondent pas non plus à une exigence obligatoire.

Je serais surpris s'ils suggéraient également d'utiliser l'échange de clés RSA dans les suites de chiffrement comme meilleure pratique pour la sécurité/la confidentialité. Si vous souhaitez gérer correctement la sécurité et la confidentialité, adoptez uniquement les suites de chiffrement PFS, votre certificat RSA ne sera plus pertinent à partir de ce moment car il ne jouera alors qu'un rôle dans l'authentification.

Quoi qu'il en soit, j'ai l'impression de me répéter ici et les allers-retours interminables ne m'intéressent pas. Si vous devez vous conformer à certaines autorités/avis de sécurité, faites-le en étant explicite à ce sujet. J'ai déjà assez bien détaillé que 2048 bits est sécurisé et le restera dans un avenir prévisible, si ce n'était pas le cas, le RSA 3072 bits n'est plus susceptible d'être sécurisé non plus.

Comme vous êtes plutôt passionné par ce sujet, essayez de comprendre ce que je vous ai transmis, au lieu de réciter NIST / ANSSI / BSI / etc, il est dans leur intérêt de conseiller un peu plus haut que nécessaire, similaire à la façon dont AES- 128 a été présenté comme le niveau de sécurité le plus bas/le plus faible pour AES , mais considérablement sécurisé en soi.

Tout ce que vous gagnez de 3072 bits est un faux sentiment de "plus sécurisé", car 2048 bits sont plus que suffisants pour que si ce n'était pas le cas, il n'y a aucune raison de penser que 3072 bits seront plus sécurisés car c'est 16 bits de sécurité supplémentaires ne suivront pas de telles avancées. Faites ce qu'il faut et ne continuez pas à utiliser RSA comme échange de clés... si vous ne comptez que sur une longueur de clé RSA plus grande pour votre sentiment de sécurité au lieu d'appliquer des pratiques de sécurité ailleurs, vous vous trompez.

Si vous voulez continuer à discuter pour des raisons de conformité plutôt que pour un avantage réel en matière de sécurité, je vous laisse faire. Personnellement, ce n'est pas un changement valable par défaut, et pour la majorité des utilisateurs de Certbot, il est probablement indésirable en raison d'inconvénients et de l'absence de gain pragmatique en matière de sécurité réelle.

Ce n'est pas la première fois que LE utilise la configuration par défaut en opposition avec les conseils de pointe d'une agence gouvernementale ou autre…

Probablement parce qu'ils savent mieux, malgré ce que vous pourriez penser. Même avec toutes les informations qui vous ont été présentées plus tôt, vous ne semblez pas du tout intéressé ou ouvert à cela.

Bien que cela ne vous convaincra probablement pas davantage, voici ce que nécessite une force symétrique de 2^128 bits pour attaquer avec succès :

La consommation d'énergie mondiale totale actuelle est d'environ 500 EJ (5 × 10 ^ 20 J) par an (c'est du moins ce que dit cet article).

Cela conduirait à un grand total de 2 ^ 138 en l'an 2040 - et ceci pour un seul calcul de dix ans qui mobilise toutes les ressources de la planète entière .

Autre aperçu divertissant :

Pour résumer : même si vous utilisez tous les dollars du monde (y compris les dollars qui n'existent pas, comme les dettes accumulées) et faites frire la planète entière dans le processus, vous pouvez à peine faire 1/1000e d'une recherche clé exhaustive sur Clés 128 bits .

Les clés de chiffrement symétriques de 256 bits dépasseraient toute l'énergie disponible dans notre système solaire pour craquer :

Les lois de l'univers physique signifient que même des clés de ces tailles modestes ne seront jamais brutalement forcées . Cela ne veut pas dire qu'ils ne peuvent jamais être brisés. Des failles peuvent être découvertes dans les algorithmes

il n'y a rien de plus fort que "ne peut pas le casser", donc comparer les forces au-delà de 100 bits environ n'a pas de sens de toute façon. - Origine

Maintenant, toutes ces citations se concentrent sur des clés 128 bits comme RSA 3072 bits, mais les 110-112 bits de RSA 2048 bits sont encore assez considérables. Cependant, il est beaucoup moins cher de simplement emprunter l' itinéraire conseillé par XKCD :)

On dirait que les arguments sont passés de la sécurité à la conformité.

On dirait que les arguments sont passés de la sécurité à la conformité.

Ou non. Ce ne sont que des conseils de pointe d'entités bien connues liées à l'écosystème de sécurité sur ce qu'il faut utiliser par défaut pour éviter de vous tirer dans les pieds comme nous le voyons régulièrement dans le monde TLS/X.509 depuis au moins une décennie.