La force de RSA Crypter une Clé AES

Je suis en train de développer un système pour transmettre des données entre le client et le serveur, et je me demandais ce que la force du chiffrement j'ai prévu d'utiliser.

Ma pensée a été privé/public paire de clés RSA et de la main de la clé publique de chaque client, tout en laissant la clé privée uniquement sur le serveur). Chaque client de générer leur propre clé AES et RSA le chiffrer. Ils seraient alors AES crypter leurs données et envoyer les données chiffrées et crypté AES clé pour le serveur. Le serveur peut ensuite déchiffrer la clé AES à l'aide de la clé privée, puis déchiffrer les données à l'aide de la clé AES.

Existe-il des failles de sécurité, je suis absent et/ou est-il une meilleure façon de le faire?

...c'est fondamentalement la façon dont PGP fonctionne, donc si elles sont appliquées correctement, il est tout à fait sûr, oui.

OriginalL'auteur user201117 | 2009-11-02

  1. 19

    C'est presque exactement comment SSL/TLS œuvres (consultez la section poignée de main). La seule chose pour le rendre plus fort est de générer la clé AES pour chaque connexion, plutôt que d'utiliser la même clé à chaque fois. Vous pouvez également signer numériquement les messages qui vont d'avant en arrière pour éviter de man-in-the-middle et d'autres attaques par usurpation.

    Généralement parlant, la création d'un bon système cryptographique est très difficile. Si possible, vous devriez toujours en faveur d'un existant (de confiance), la demande de l'aider. Dans ce cas, vous pouvez envisager l'envoi de vos messages en utilisant le protocole HTTPS, plutôt que de créer votre propre système.

    +1 toujours choisir d'utiliser les suites de sécurité conçu par des experts sur la conception de votre propre.
    +1 exactement la conception que j'avais de l'utiliser.
    Seule chose à ajouter, c'est d'utiliser RSA de 1024 bits à court terme secrets, jamais à plus courte longueur de la clé, et 2048 bits pour des choses avec significative de la valeur durable.
    +1 pour le staqndard "l'utilisation d'un système existant" conseils. 🙂

    OriginalL'auteur jheddings

  2. 2

    Vous devriez nous donner plus d'informations à propos de la langue et de la plate-forme, de sorte que nous pouvons vous donner des recommandations spécifiques sur les bibliothèques qui existent déjà et qui va gérer les détails pour vous. À l'aide de primitives cryptographiques directement n'est pas trivial et difficile à obtenir exactement droit, et avec la cryptographie, il faut être "pas exactement" une seule fois, pour votre sécurité, pour être brisées.

    Pour répondre à votre question, il est généralement une meilleure idée de créer une session secrète (la clé AES) par l'intermédiaire d'un L'Échange De Clés Diffie-Hellman de change, et de chaque côté de l'utilisation de son mot de clé RSA de signer sa clé d'échange de données.

    Sinon, si la session secret n'est pas créé à travers un échange DIFFIE-hellman, un adversaire que les gains d'accès à la clé RSA (qui doit être stockée quelque part) peut déchiffrer tout le trafic qui n'a jamais été échangées entre le client et le serveur.

    Si le secret est établi par le biais d'un échange DIFFIE-hellman, alors seule la partie authentification du protocole seraient exposés. Bien qu'un adversaire en possession de la clé RSA privée serait alors de ne pas être en mesure de lire toute la communication précédente, il ne pourrait entrer authentifié dialogue avec le client/serveur ou de lancer un man-in-the-middle attack (qui peut ou peut ne pas être facile à faire, selon le réseau).

    OriginalL'auteur Inshallah

  3. 0

    Une vulnérabilité serait si un attaquant substitué leur clé publique pour le "réel" de la clé publique. Puis ils seraient en mesure d'intercepter le trafic comme un "man-in-the-middle."

    Protocoles tels que le protocole S/MIME, PGP, et TLS utiliser le cryptage RSA, pour le transport des touches comme vous le proposer. Cependant, le public des clés qu'ils utilisent sont dans les certificats signés par des autorités de confiance.

    L'intégrité de ces autorités de confiance doivent être soigneusement protégés. Par exemple, ils peuvent être brûlés dans un inviolable jeton matériel, ou un MAC peut être calculée sur eux à l'aide d'un mot de passe.

    OriginalL'auteur erickson

  4. -3

    Je ne suis pas sûr que votre approche permettra de protéger quoi que ce soit! Vous allez garder la clé privée du serveur et la clé publique sera distribué. Si je reçois une prise de votre clé publique, je vais être en mesure d'interagir avec votre serveur. Je pense que vous devez inverser la clé de la propriété; chaque client tiendra il est-propre clé privée et le serveur dispose d'une liste de clés publiques (ala SSH). Le serveur devra ajouter "autorisés" clés publiques et uniquement aux détenteurs des clés privées seront en mesure de se connecter.

    Espère que cette aide.

    OriginalL'auteur cjh