Cryptage - dois-je utiliser RSA ou AES?
Mon modèle est celui où j'ai plusieurs clients qui souhaitent parler avec certains (mais pas tous) des autres clients.
Tous les messages seront envoyés via un serveur.
Seuls les deux clients qui communiquent devraient pouvoir connaître le message. Le serveur ET les autres clients ne devraient donc pas être en mesure de déterminer le message envoyé.
La communication entre deux clients peut commencer et se terminer plusieurs fois par jour.
Les messages seront en clair avec une longueur potentiellement illimitée, mais probablement beaucoup moins, pensez aux messages de style SMS.
Dans ces circonstances, comment chiffrer les messages? Cela ne me dérange pas d'écrire du code supplémentaire si cela conduit à une meilleure vitesse ou efficacité.
Je connais les bases rudimentaires du fonctionnement de RSA et AES, mais je n'arrive pas à déterminer ce qui est le mieux.
Lorsque vous générez une paire de clés publique/privée pour RSA, y a-t-il une situation où vous auriez besoin de générer une nouvelle paire? Ou un client peut-il avoir une clé publique et donner la même clé à quiconque veut lui parler et lui seul peut (jamais) lire les messages, mais ils stockent la clé publique pour tous les futurs messages?
Ou devrais-je avoir une clé AES symétrique distincte pour une paire de clients et la partager simplement lors du premier contact et l'utiliser à tout jamais. Encore une fois, y a-t-il des circonstances où cela devrait être généré à nouveau?
Comment puis-je stocker la ou les clés afin qu'elles persistent si le client plante/s'arrête/redémarre?
Ni l'un ni l'autre, à moins que ce ne soit les deux. Vous posez la mauvaise question . Vous ne devriez pas penser à un algorithme cryptographique à ce stade, mais à un protocole cryptographique.
Les protocoles cryptographiques sont difficiles à concevoir et constituent une source fréquente de bogues de sécurité. Vous ne comprenez pas complètement la cryptographie à clé publique, vous n'êtes donc pas prêt à l'utiliser dans votre propre protocole cryptographique.
À un niveau élevé, votre modèle se prête à la cryptographie à clé publique (par exemple RSA). Laissez chaque client avoir sa propre clé privée et publiez sa clé publique sur l'autre client. La clé privée d'un client ne change pas au fil du temps, sauf si le client a été compromis. La cryptographie symétrique (par exemple AES) ne serait pas bien mise à l'échelle ici car chaque paire de clients aurait besoin d'avoir sa propre clé secrète.
Utilisez autant que possible les logiciels existants. La mise en œuvre de protocoles cryptographiques est presque aussi délicate que leur conception. Pour un modèle où les clients s'envoient occasionnellement des messages, de type e-mail, un outil qui fonctionnerait bien est GnuPG . (Pour les communications bidirectionnelles, utilisez SSL/TLS .)
Donc: pour les opérations quotidiennes, pour envoyer un message, appelez gpg, chiffrez avec la clé publique du destinataire, et pendant que vous y êtes, signez avec la clé privée de l'expéditeur. Lorsque vous recevez un message, vérifiez la signature par rapport à la prétendue clé publique de l'expéditeur et déchiffrez avec la clé privée du destinataire. En d'autres termes, envoyez avec gpg --sign --encrypt -r NAME_OF_RECIPIENT et recevez avec gpg --verify suivi par gpg --decrypt.
Le problème restant est celui de la distribution des clés. Une fois qu'un client a généré sa paire de clés, il doit en informer les autres clients et la distribuer sans permettre à la clé publique d'être interceptée et remplacée en transit par un attaquant. Comment faire cela dépend beaucoup de votre scénario précis. Ne négligez pas la sécurité de cette pièce.
Si, et seulement si, l'invocation de GnuPG s'avère trop lente, envisagez d'utiliser une implémentation plus légère, peut-être faite maison, d'un protocole similaire (en passant de la surcharge de la plage de messagerie à SMS Sous le capot, GnuPG génère une clé symétrique pour chaque message, car la cryptographie à clé publique coûte cher pour les messages volumineux; l'algorithme de clé publique n'est utilisé que pour crypter la clé symétrique et pour signer un résumé du fichier. devrait utiliser ce modèle. En utilisant AES pour le chiffrement symétrique, SHA-256 comme algorithme de résumé et RSA comme algorithme de clé publique est un bon choix.
Comme déjà dit par In silico, RSA et AES ont deux objectifs différents. AES est un algorithme rapide, adapté pour crypter une conversation entière. Mais il y a un problème: comment décider quelle clé utiliser entre deux parties sans que les autres le sachent?
RSA peut être la solution à cela. Si chaque participant a la clé RSA publique de chaque autre participant, n'importe qui peut démarrer une communication cryptée avec n'importe qui (en utilisant la clé publique de l'autre participant) et décider d'une clé AES secrète à utiliser. Une fois la clé AES décidée, le reste de la conversation peut être crypté à l'aide d'AES. Pour prouver au participant B que c'est vraiment A qui veut lui parler, une signature numérique peut être utilisée.
Ce que j'ai décrit est, grosso modo, ce que fait la prise de contact SSL lorsqu'un navigateur se connecte à un serveur Web compatible SSL.
Ne prenez pas cela mal mais ...
Je connais les bases rudimentaires du fonctionnement de RSA et AES, mais je n'arrive pas à déterminer ce qui est le mieux.
Si vous ne connaissez que les bases, vous n'êtes peut-être pas encore la bonne personne pour résoudre ce problème. La sécurité est l'un de ces domaines où vous devez être très particulier et prudent, sinon vous invalidez l'ensemble de votre configuration de sécurité.
De plus, je ne pense pas que nous ayons suffisamment d'informations pour vous donner une bonne réponse. Les contrats commerciaux concernant les attentes en matière de sécurité devront être connus dès le départ.
Dans la plupart des cas, les clés ne quittent jamais la machine sur laquelle elles sont générées pour des raisons de sécurité, donc si vous avez l'intention de "partager" des informations, une solution de clé publique est généralement la bonne option d'un point de vue purement sécuritaire. L'exception à cette règle est si vous pouvez partager une clé symétrique de manière sécurisée, comme l'envoi de la clé à la personne sur un support physique.
Fondamentalement, l'utilisation du chiffrement à clé publique (comme RSA) est beaucoup plus coûteuse que l'utilisation du chiffrement à clé symétrique (comme AES), et quand il y a beaucoup de messages qui passent de l'un à l'autre, il est préférable d'utiliser un symétrique clé.
Désormais, la création et l'échange de la clé symétrique peuvent se faire à l'aide du chiffrement à clé publique.
Par exemple:
Chaque client possède une paire de clés privée-publique et la clé publique est stockée sur le serveur. Lorsque deux clients démarrent une session de communication, chacun prend la clé publique de l'autre sur le serveur et envoie un numéro chiffré à l'autre. Ensuite, chaque côté hache ces deux nombres et utilise le résultat comme clé pour crypter/décrypter les données à partir de maintenant.
Si vous utilisez le style PUBLIC/PRIVATE (RSA avec suffisamment de bits :)), vous pouvez configurer le type de communication sécurisée que vous décrivez de cette façon:
- Alice écris un message
- Alice le chiffre à l'aide de la clé Alice PRIVÉE
- Alice le chiffre à nouveau à l'aide de la clé Bob PUBLIQUE
- Alice envoie les résultats à Bob.
Alors:
- Bob reçoit (soi-disant) un message d'Alice
- Bob le déchiffre en utilisant la clé Bob PRIVÉE
- Bob le déchiffre à nouveau en utilisant la touche Alice PUBLIQUE
- Si tout se passe bien, Bob lit le message.
Remarque:
- Bob est le seul à pouvoir lire ce message.
- Bob sait sans aucun doute que cela vient d'Alice.
Obtenir ces deux attributs avec AES est un peu plus délicat.