En quoi ces raisons ne s'appliquent-elles pas pour RSA ?
En fait, avoir la crypto dans le noyau permet d'utiliser les "coffres forts numériques", tels que EVM. Ça vas pour RSA comme pour tout autre algo de chiffrement.
Avec de tels coffres forts, il n'est pas possible d'avoir la valeur de la clé, qui est stockée dans une mémoire inaccessible. Le seul moyen de chiffrer et déchiffrer, c'est d'envoyer un blob dans le module de chiffrement, de lui demander de chiffrer ou déchiffrer, et de récupérer le résultat.
Bien entendu, il n'est pas possible de faire ça depuis l'espace utilisateur, car dialoguer avec le module de chiffrement se fait souvent par des accès restreints (eg. instructions disponibles seulement en ring 0 sur x86, ou mémoire non mappable dans l'adresse d'un processus mais disponible pour le noyau, etc…)
De plus, pour éviter que différents utilisateurs du module ne se "marche dessus", il faut sérialiser les accès. Ça se fait très bien dans un driver, pas en espace utilisateur (non, les sémaphores n'aident pas, par exemple s'il y deux implémentations dans deux programmes ou librairies différents).
Bon, c'est une vue un peu simplifiée, mais c'est grosso-modo la raison de le faire en mode noyau. Le principe vaut aussi pour les algos de hachage, comme sha1 & Co. qui peuvent être accélérés de cette manière (sauf si ce sont des instruction et pas un module matériel, auquel cas la restriction ne s'applique pas, ces instructions n'étant pas protégées).
[^] # Re: RSA dans le noyau
Posté par ymorin . En réponse à la dépêche Sortie du noyau Linux 3.3. Évalué à 10.
En fait, avoir la crypto dans le noyau permet d'utiliser les "coffres forts numériques", tels que EVM. Ça vas pour RSA comme pour tout autre algo de chiffrement.
Avec de tels coffres forts, il n'est pas possible d'avoir la valeur de la clé, qui est stockée dans une mémoire inaccessible. Le seul moyen de chiffrer et déchiffrer, c'est d'envoyer un blob dans le module de chiffrement, de lui demander de chiffrer ou déchiffrer, et de récupérer le résultat.
Bien entendu, il n'est pas possible de faire ça depuis l'espace utilisateur, car dialoguer avec le module de chiffrement se fait souvent par des accès restreints (eg. instructions disponibles seulement en ring 0 sur x86, ou mémoire non mappable dans l'adresse d'un processus mais disponible pour le noyau, etc…)
De plus, pour éviter que différents utilisateurs du module ne se "marche dessus", il faut sérialiser les accès. Ça se fait très bien dans un driver, pas en espace utilisateur (non, les sémaphores n'aident pas, par exemple s'il y deux implémentations dans deux programmes ou librairies différents).
Bon, c'est une vue un peu simplifiée, mais c'est grosso-modo la raison de le faire en mode noyau. Le principe vaut aussi pour les algos de hachage, comme sha1 & Co. qui peuvent être accélérés de cette manière (sauf si ce sont des instruction et pas un module matériel, auquel cas la restriction ne s'applique pas, ces instructions n'étant pas protégées).
Hop,
Moi.