je me demandais si le but est seulement d'améliorer la vitesse d'utilisation des logiciels qui utilisent /dev/random et /dev/urandom ou si cela en améliorait aussi la "qualité" d'aléatoire. De l'aléa de meilleur qualité que ce qu'il y a en général dans ces interfaces.
Je ne pense pas que ça en améliore la qualité.
Dans le meilleur des cas (si le générateur de nombres aléatoires de la carte est correct), logiquement la qualité est la même. Un bit d’entropie en provenance de la carte revient au même qu’un bit d’entropie en provenance des autres sources utilisées normalement par le noyau, c’est juste que la carte est capable d’en délivrer plus rapidement.
Dans le pire des cas (si le générateur de la carte est mauvais — ce que je suis incapable de déterminer, mais qui peut arriver), la qualité serait a priori réduite, mais l’effet devrait être mitigé par les traitements réalisés aussi bien en entrée qu’en sortie du pool.
À noter que dans le noyau Linux, c’est à celui qui ajoute de l’aléa dans le pool qu’il revient d’estimer quelle est l’entropie réellement ajoutée. Pour cette première version de scdrand, je suis parti du principe que le générateur de la carte est correct et produit bien des octets complètement aléatoires. En conséquence, scdrand estime qu’un octet en provenance de la carte = 8 bits d’entropie. Une évolution possible de scdrand serait de permettre à l’utilisateur de modifier ce comportement et d’estimer lui-même la « valeur » des octets générés par la carte.
Aussi quand tu crées une clé, pour reprendre ton exemple, la clé peut-elle être plus "sûre" avec du bon aléa? Y a-t-il une notion de qualité d'une clé, deux clés de la même taille peuvent-elles avoir intrinsèquement une sécurité différente?
Oui.
Une clef se doit d’être unique. L’unicité est normalement assurée par le fait de tirer la clef au hasard dans un très grand espace, la probabilité que deux personnes tirent la même clef étant virtuellement nulle. Mais si les clefs sont générés avec une entropie insuffisante, cette probabilité augmente, et avec elle le risque d’avoir des clefs dupliquées dans la nature. Ce risque n’est pas que théorique.
Les clefs RSA sont particulièrement vulnérables, car leur génération nécessite non pas un mais deux grands nombres premiers. Ces deux nombres sont supposés être uniques à chaque clef. Si, en raison d’un mauvais RNG, plusieurs clefs RSA partagent un même facteur, elles sont toutes trivialement cassables.
Sinon oui, comme le commentaire au dessus, je suis curieux de connaître l'utilité générale d'une telle carte, car je n'ai jamais eu affaire à quiconque qui en avait une. Comment ça s'utilise, etc.
Il y a l’air d’avoir du monde intéressé (je vois que le commentaire du dessus est à 10...), je vais voir si je peux écrire quelque chose là-dessus.
En tous cas, ton outil a quand même l'air extra et améliore grandement l'utilité existante de ces cartes en les rendant utile génériquement (transparent pour toute application qui utilise /dev/(u?)random et qui utilisera donc la carte indirectement sans le savoir). C'est génial.
Pour bien rendre à César ce qui lui appartient, l’idée géniale d’alimenter le pool d’entropie du noyau vient de l’auteur de TokenTools. Je n’ai écrit scdrand que parce qu’une utilisation simultanée de GnuPG (donc de scdaemon) et de TokenTools semble impossible.
[^] # Re: Vitesse d'utilisation seulement ou aussi sécurité?
Posté par gouttegd . En réponse à la dépêche scdrand: alimenter le pool d’entropie du noyau à partir d’une carte à puce. Évalué à 10.
Je ne pense pas que ça en améliore la qualité.
Dans le meilleur des cas (si le générateur de nombres aléatoires de la carte est correct), logiquement la qualité est la même. Un bit d’entropie en provenance de la carte revient au même qu’un bit d’entropie en provenance des autres sources utilisées normalement par le noyau, c’est juste que la carte est capable d’en délivrer plus rapidement.
Dans le pire des cas (si le générateur de la carte est mauvais — ce que je suis incapable de déterminer, mais qui peut arriver), la qualité serait a priori réduite, mais l’effet devrait être mitigé par les traitements réalisés aussi bien en entrée qu’en sortie du pool.
À noter que dans le noyau Linux, c’est à celui qui ajoute de l’aléa dans le pool qu’il revient d’estimer quelle est l’entropie réellement ajoutée. Pour cette première version de scdrand, je suis parti du principe que le générateur de la carte est correct et produit bien des octets complètement aléatoires. En conséquence, scdrand estime qu’un octet en provenance de la carte = 8 bits d’entropie. Une évolution possible de scdrand serait de permettre à l’utilisateur de modifier ce comportement et d’estimer lui-même la « valeur » des octets générés par la carte.
Oui.
Une clef se doit d’être unique. L’unicité est normalement assurée par le fait de tirer la clef au hasard dans un très grand espace, la probabilité que deux personnes tirent la même clef étant virtuellement nulle. Mais si les clefs sont générés avec une entropie insuffisante, cette probabilité augmente, et avec elle le risque d’avoir des clefs dupliquées dans la nature. Ce risque n’est pas que théorique.
Les clefs RSA sont particulièrement vulnérables, car leur génération nécessite non pas un mais deux grands nombres premiers. Ces deux nombres sont supposés être uniques à chaque clef. Si, en raison d’un mauvais RNG, plusieurs clefs RSA partagent un même facteur, elles sont toutes trivialement cassables.
Il y a l’air d’avoir du monde intéressé (je vois que le commentaire du dessus est à 10...), je vais voir si je peux écrire quelque chose là-dessus.
Pour bien rendre à César ce qui lui appartient, l’idée géniale d’alimenter le pool d’entropie du noyau vient de l’auteur de TokenTools. Je n’ai écrit scdrand que parce qu’une utilisation simultanée de GnuPG (donc de scdaemon) et de TokenTools semble impossible.