Les clés asymétriques comportent une partie publique et une partie privée; la partie publique est utilisée pour effectuer l'opération qui complète celle effectuée avec la partie privée (par exemple, vous signez avec la clé privée et vous vérifiez la signature avec la clé publique) ou cryptez les données avec la clé publique et décryptez avec la clé privée). Le point des clés asymétriques est que les parties privée et publique peuvent être connues par des entités distinctes; à savoir, que la partie publique est, bien, publique (tout le monde le sait) alors que la partie privée reste privée. Par conséquent, générer une clé asymétrique "en temps réel" n'a guère de sens dans la plupart des situations: ce qui donne de la valeur à une clé privée, c'est que la clé publique est déjà connue pour une autre partie.
On peut encore imaginer des situations dans lesquelles la génération "en temps réel" de clés asymétriques peut être utile. Par exemple, les connexions SSL utilisant l'une des suites de chiffrement "éphémères Diffie-Hellman": les clés DH, dites "asymétriques", sont générées pour chaque connexion, la partie publique étant alors signée par le serveur (avec une autre clé asymétrique, qui n'est pas générée à la volée: la clé publique est celle du certificat du serveur), puis envoyée au client de connexion. Dans une telle situation, pré-générer des paires de clés DH et les stocker pourrait être considéré comme une sorte d'optimisation, mais une mauvaise puisque la génération de paires de clés DH est très rapide, et le stockage de clés privées est une question complexe et délicate. Si votre problème concerne la génération de clé lors de l'enregistrement de l'utilisateur par rapport à la génération et le stockage des clés: en supposant que la génération de clés côté serveur soit ce que vous voulez, la génération et le stockage de clés ne vaut que l'optimisation, si la génération à la volée s'avère trop coûteuse pour gérer les pics (occasionnellement, de nombreux utilisateurs tentent de s'enregistrer en même temps). Je suggère que vous essayiez et que vous vérifiiez que le problème existe réellement, avant d'implémenter une "solution", car le stockage sécurisé par clé privée est quelque peu compliqué. La génération de clés RSA est assez rapide (sur un PC de base, vous pouvez facilement générer une douzaine de clés RSA par seconde), et avec les cryptosystèmes à logique discrète (DSA, Diffie-Hellman, El-Gamal) ou à courbe elliptique, considérablement plus rapide (par exemple dix milliers nouvelles paires de clés EC par seconde, avec un PC).
L '* utilisateur * génère la paire de clés, pas vous. L'utilisateur vous donnera alors la clé publique dans le cadre du processus d'inscription. –
Je suis d'accord que c'est le processus habituel, mais dans ce cas, j'ai besoin de le générer pour l'utilisateur sur le serveur. À qui on dirait passer la clé privée sur le réseau est stupide, mais supposons ce cas hypothétique où la clé privée lui est passée :) –
Il n'est toujours pas clair quel problème vous essayez de résoudre. Êtes-vous en train d'essayer de sécuriser les communications avec l'utilisateur? Si oui, de quelle menace les sécurisez-vous? Je ne peux pas penser à celui qui est adressé par le mécanisme que vous énumérez. – Slartibartfast