Je regarde actuellement des outils de sécurité utilisant des certificats
(chiffrement, authentification, ...).
Je constate qu'aujourd'hui il y a encore des outils qui sont limités et
n'acceptent pas des autorités de certification qui ont des certificats
supérieurs à 2048 bits ou bien des chaines de certification limité à un
CA.
Cela m'étonne et je me demande s'il y a des raisons qui m'échapent
(lois, exportation, difficultés technique, affaiblissement de la
protection, ...) ou bien s'il s'agit tout simplement de retard dans le
développement de ces outils.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Marc Desperrier
wrote:
Je constate qu'aujourd'hui il y a encore des outils qui sont limités et n'acceptent pas des autorités de certification qui ont des certificats supérieurs à 2048 bits ou bien des chaines de certification limité à un CA.
Tu peux donner des noms ? Je connais quelques tests de ce genre qui se gardent bien d'expliciter de qui il s'agit. Généralement les vendeurs ont prété le matos pour les tests, ont participés à leur mise en place, leur taper publiquement sur la tête en retour devient difficile.
Cela m'étonne et je me demande s'il y a des raisons qui m'échapent (lois, exportation, difficultés technique, affaiblissement de la protection, ...) ou bien s'il s'agit tout simplement de retard dans le développement de ces outils.
Non, c'est un gros problème en PKI, la qualité des implémentations qui ne respectent pas des trucs élémentaires. En particulier, les gens qui n'implémente que le cas de base qui les intéressent, par exemple les produits de VPN qui ne savent gérer que les certif émis directement sous une CA.
C'était génant en 98, en 2003, on se demande vraiment pourquoi cela progresse aussi peu, et je pense personnellement que c'est un facteur majeur dans les difficultés d'implémentation de PKI. Et pendant ce temps là, les comités se battent sur et propose des trucs ésotériques (voir la complexité des algo de restriction de noms ou de restriction de politique) pendant que les implémenteurs n'arrivent même pas à implémenter les trucs simples. Ou comités qui semblent n'avoir pas un mot à dire sur les conséquences du fait que le respect des RFC 3280/2459 impose à partir la fin de cette année d'utiliser UTF-8 dans tous les certifs, alors que les implémentations ne sont pratiquement jamais à la hauteur, ce qui me semble au moins aussi important que d'autres sujets qui s'étalent sur des centaines de mails.
Cela dit pour la taille des clés, une taille supérieure à 2048 ne sert pas à grand chose. Voir le message de Pornin du 26/09, 11h07 qui détaille les critères de choix de taille de clé en fonction de difficulté de cassage. Pour avoir besoin d'une taille de clé supérieure à 2048, il faudrait à la fois que les progrès rendent facile de casser 2048 sans rendre facile de casser 4096. Ce qui veut dire que ce serait à la fois un progrès qui ne rendrait pas le cassage algorithmiquement simple (où augmenter la taille ne servira de toute façon plus à rien, la démonstration de Pornin est éloquente à ce sujet), et qui ferait faire un énorme bond en avant sur les tailles de clés cassables. Ca semble peu probable.
En plus tout dépend du matériel, mais 4096 sur carte à puce c'est plutôt limite. En génération, la différence se sent vraiment. Cf note de Microsoft sur la génération de clés 8192 : "Prévoyez quelques heures".
lucien_marcel@hotmail.com wrote:
Je constate qu'aujourd'hui il y a encore des outils qui sont limités et
n'acceptent pas des autorités de certification qui ont des certificats
supérieurs à 2048 bits ou bien des chaines de certification limité à un
CA.
Tu peux donner des noms ? Je connais quelques tests de ce genre qui se
gardent bien d'expliciter de qui il s'agit.
Généralement les vendeurs ont prété le matos pour les tests, ont
participés à leur mise en place, leur taper publiquement sur la tête en
retour devient difficile.
Cela m'étonne et je me demande s'il y a des raisons qui m'échapent
(lois, exportation, difficultés technique, affaiblissement de la
protection, ...) ou bien s'il s'agit tout simplement de retard dans le
développement de ces outils.
Non, c'est un gros problème en PKI, la qualité des implémentations qui
ne respectent pas des trucs élémentaires. En particulier, les gens qui
n'implémente que le cas de base qui les intéressent, par exemple les
produits de VPN qui ne savent gérer que les certif émis directement sous
une CA.
C'était génant en 98, en 2003, on se demande vraiment pourquoi cela
progresse aussi peu, et je pense personnellement que c'est un facteur
majeur dans les difficultés d'implémentation de PKI.
Et pendant ce temps là, les comités se battent sur et propose des trucs
ésotériques (voir la complexité des algo de restriction de noms ou de
restriction de politique) pendant que les implémenteurs n'arrivent même
pas à implémenter les trucs simples.
Ou comités qui semblent n'avoir pas un mot à dire sur les conséquences
du fait que le respect des RFC 3280/2459 impose à partir la fin de cette
année d'utiliser UTF-8 dans tous les certifs, alors que les
implémentations ne sont pratiquement jamais à la hauteur, ce qui me
semble au moins aussi important que d'autres sujets qui s'étalent sur
des centaines de mails.
Cela dit pour la taille des clés, une taille supérieure à 2048 ne sert
pas à grand chose.
Voir le message de Pornin du 26/09, 11h07 qui détaille les critères de
choix de taille de clé en fonction de difficulté de cassage.
Pour avoir besoin d'une taille de clé supérieure à 2048, il faudrait à
la fois que les progrès rendent facile de casser 2048 sans rendre facile
de casser 4096. Ce qui veut dire que ce serait à la fois un progrès qui
ne rendrait pas le cassage algorithmiquement simple (où augmenter la
taille ne servira de toute façon plus à rien, la démonstration de Pornin
est éloquente à ce sujet), et qui ferait faire un énorme bond en avant
sur les tailles de clés cassables.
Ca semble peu probable.
En plus tout dépend du matériel, mais 4096 sur carte à puce c'est plutôt
limite. En génération, la différence se sent vraiment. Cf note de
Microsoft sur la génération de clés 8192 : "Prévoyez quelques heures".
Je constate qu'aujourd'hui il y a encore des outils qui sont limités et n'acceptent pas des autorités de certification qui ont des certificats supérieurs à 2048 bits ou bien des chaines de certification limité à un CA.
Tu peux donner des noms ? Je connais quelques tests de ce genre qui se gardent bien d'expliciter de qui il s'agit. Généralement les vendeurs ont prété le matos pour les tests, ont participés à leur mise en place, leur taper publiquement sur la tête en retour devient difficile.
Cela m'étonne et je me demande s'il y a des raisons qui m'échapent (lois, exportation, difficultés technique, affaiblissement de la protection, ...) ou bien s'il s'agit tout simplement de retard dans le développement de ces outils.
Non, c'est un gros problème en PKI, la qualité des implémentations qui ne respectent pas des trucs élémentaires. En particulier, les gens qui n'implémente que le cas de base qui les intéressent, par exemple les produits de VPN qui ne savent gérer que les certif émis directement sous une CA.
C'était génant en 98, en 2003, on se demande vraiment pourquoi cela progresse aussi peu, et je pense personnellement que c'est un facteur majeur dans les difficultés d'implémentation de PKI. Et pendant ce temps là, les comités se battent sur et propose des trucs ésotériques (voir la complexité des algo de restriction de noms ou de restriction de politique) pendant que les implémenteurs n'arrivent même pas à implémenter les trucs simples. Ou comités qui semblent n'avoir pas un mot à dire sur les conséquences du fait que le respect des RFC 3280/2459 impose à partir la fin de cette année d'utiliser UTF-8 dans tous les certifs, alors que les implémentations ne sont pratiquement jamais à la hauteur, ce qui me semble au moins aussi important que d'autres sujets qui s'étalent sur des centaines de mails.
Cela dit pour la taille des clés, une taille supérieure à 2048 ne sert pas à grand chose. Voir le message de Pornin du 26/09, 11h07 qui détaille les critères de choix de taille de clé en fonction de difficulté de cassage. Pour avoir besoin d'une taille de clé supérieure à 2048, il faudrait à la fois que les progrès rendent facile de casser 2048 sans rendre facile de casser 4096. Ce qui veut dire que ce serait à la fois un progrès qui ne rendrait pas le cassage algorithmiquement simple (où augmenter la taille ne servira de toute façon plus à rien, la démonstration de Pornin est éloquente à ce sujet), et qui ferait faire un énorme bond en avant sur les tailles de clés cassables. Ca semble peu probable.
En plus tout dépend du matériel, mais 4096 sur carte à puce c'est plutôt limite. En génération, la différence se sent vraiment. Cf note de Microsoft sur la génération de clés 8192 : "Prévoyez quelques heures".
Erwann ABALEA
On Thu, 2 Oct 2003, Jean-Marc Desperrier wrote:
[...]
En plus tout dépend du matériel, mais 4096 sur carte à puce c'est plutôt limite. En génération, la différence se sent vraiment. Cf note de Microsoft sur la génération de clés 8192 : "Prévoyez quelques heures".
<mode troll-facile> Oui, mais ils ne sont pas forcément doués... ;) </mode troll-facile>
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- il faut bien commencer par publier pour publier ensuite plus sérieusement - c'est-à-dire, entrer en conflit, avec l'injustice et le "on" de la mondanité consensuelle appellée ici netiquette. -+- RC in: Guide du Neuneu d'Usenet - Le neuneu ridicule pédante -+-
On Thu, 2 Oct 2003, Jean-Marc Desperrier wrote:
[...]
En plus tout dépend du matériel, mais 4096 sur carte à puce c'est plutôt
limite. En génération, la différence se sent vraiment. Cf note de
Microsoft sur la génération de clés 8192 : "Prévoyez quelques heures".
<mode troll-facile>
Oui, mais ils ne sont pas forcément doués... ;)
</mode troll-facile>
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
il faut bien commencer par publier pour publier ensuite plus
sérieusement - c'est-à-dire, entrer en conflit, avec l'injustice et le
"on" de la mondanité consensuelle appellée ici netiquette.
-+- RC in: Guide du Neuneu d'Usenet - Le neuneu ridicule pédante -+-
En plus tout dépend du matériel, mais 4096 sur carte à puce c'est plutôt limite. En génération, la différence se sent vraiment. Cf note de Microsoft sur la génération de clés 8192 : "Prévoyez quelques heures".
<mode troll-facile> Oui, mais ils ne sont pas forcément doués... ;) </mode troll-facile>
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- il faut bien commencer par publier pour publier ensuite plus sérieusement - c'est-à-dire, entrer en conflit, avec l'injustice et le "on" de la mondanité consensuelle appellée ici netiquette. -+- RC in: Guide du Neuneu d'Usenet - Le neuneu ridicule pédante -+-
