Il va falloir plus qu’un post de blog pour me convaincre qu’il y a quelque part (sur Terre, hein, pas dans une galaxie lointaine, très lointaine) un attaquant capable de casser une clef RSA de 2048 bits en moins de trois mois...
C’est justement là que tu te trompes. Une clef n’a pas d’existence propre, ce n’est pas parce que tu as détruit son fichier que ses effets ne peuvent pas continuer à se faire ressentir.
Dans le cas de HTTPS, si la suite de chiffrement négociée n’est pas une suite PFS (Perfect Forward Secrecy), alors la NSA ou toute autre entité du genre peut se contenter de collecter de manière passive l’ensemble de tes communications actuelles, puis espérer a posteriori (d’ici 2030 donc) déchiffrer l’intégralité de l’échange réalisé.
La durée de vie de la clef privée (le fichier au sens informatique du terme) n’a que peu d’importance par rapport à la durée de rétention possible des données échangées chiffrées avec elles (qui elles ne peuvent ni expirées ni être révoquées, cause collecte passive possible).
C’est encore plus visible avec le cas de GPG, où même une fois que ta clef a expiré ou qu’elle est révoquée, tu dois quand même la conserver à vie et protéger l’ensemble des mails envoyés avec cette clef (aussi à vie et ton correspondant de même).
Si demain l’avancée techno permet de casser du 2048 bits, alors c’est l’ensemble des mails que j’ai pu échanger avec ma vieille clef GPG de 2048 bits pourtant déjà actuellement et expirée et révoquée qui se retrouve dorénavant en clair dans la nature.
Même dans le cas de PFS, sauf dans les versions très récentes des serveurs web, les paramètres DH négociés sont calqués sur la taille de la clef privée. Donc une clef de 2048 bits donnera des paramètres DH de 2048 bits, donc fragiles par rapport à LogJam et soumis aux mêmes problèmes de cassage a posteriori (avec certes une puissance de calcul nécessaire plus importante puisqu’il faut casser chaque message indépendamment, ce qui n’est pas le cas des suites non PFS vu que le cassage de la clef permet le déchiffrement instantané de toutes les communications pour un coût nul)
Une clef de 2048 bits impose donc que tout le contenu échangé à cet instant même, avec ou sans PFS, ne possède plus aucune signification utile d’ici à 2030, ce qui est relativement encore trop « demain ». Ceci que ta clef soit regénérée toutes les 10min ou tous les 15 ans. Avec un renew à 90j, ça ne complexifiera la tache d’une écoute passif que d’un facteur 60 (60 générations de clefs de 90j = 15 ans).
Une clef de 4096 bits laisse quelques décennies supplémentaires de sécurité.
Pour info, l’ANSSI (qui selon l’auteur « déconseille officiellement » les clefs de 2048 bits) admet en réalité que cette taille de clef est toujours satisfaisante jusqu’en 2030 (p. 17, RègleFact-1).
Et d’ajouter juste en dessous en recommandation qu’il faut déjà dès maintenant envisager l’usage de 3072 bits, même pour des communications n’allant pas jusqu’à 2030.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 4.
C’est justement là que tu te trompes. Une clef n’a pas d’existence propre, ce n’est pas parce que tu as détruit son fichier que ses effets ne peuvent pas continuer à se faire ressentir.
Dans le cas de HTTPS, si la suite de chiffrement négociée n’est pas une suite PFS (Perfect Forward Secrecy), alors la NSA ou toute autre entité du genre peut se contenter de collecter de manière passive l’ensemble de tes communications actuelles, puis espérer a posteriori (d’ici 2030 donc) déchiffrer l’intégralité de l’échange réalisé.
La durée de vie de la clef privée (le fichier au sens informatique du terme) n’a que peu d’importance par rapport à la durée de rétention possible des données échangées chiffrées avec elles (qui elles ne peuvent ni expirées ni être révoquées, cause collecte passive possible).
C’est encore plus visible avec le cas de GPG, où même une fois que ta clef a expiré ou qu’elle est révoquée, tu dois quand même la conserver à vie et protéger l’ensemble des mails envoyés avec cette clef (aussi à vie et ton correspondant de même).
Si demain l’avancée techno permet de casser du 2048 bits, alors c’est l’ensemble des mails que j’ai pu échanger avec ma vieille clef GPG de 2048 bits pourtant déjà actuellement et expirée et révoquée qui se retrouve dorénavant en clair dans la nature.
Même dans le cas de PFS, sauf dans les versions très récentes des serveurs web, les paramètres DH négociés sont calqués sur la taille de la clef privée. Donc une clef de 2048 bits donnera des paramètres DH de 2048 bits, donc fragiles par rapport à LogJam et soumis aux mêmes problèmes de cassage a posteriori (avec certes une puissance de calcul nécessaire plus importante puisqu’il faut casser chaque message indépendamment, ce qui n’est pas le cas des suites non PFS vu que le cassage de la clef permet le déchiffrement instantané de toutes les communications pour un coût nul)
Une clef de 2048 bits impose donc que tout le contenu échangé à cet instant même, avec ou sans PFS, ne possède plus aucune signification utile d’ici à 2030, ce qui est relativement encore trop « demain ». Ceci que ta clef soit regénérée toutes les 10min ou tous les 15 ans. Avec un renew à 90j, ça ne complexifiera la tache d’une écoute passif que d’un facteur 60 (60 générations de clefs de 90j = 15 ans).
Une clef de 4096 bits laisse quelques décennies supplémentaires de sécurité.
Et d’ajouter juste en dessous en recommandation qu’il faut déjà dès maintenant envisager l’usage de 3072 bits, même pour des communications n’allant pas jusqu’à 2030.