Lequel des approches de chiffrement dois-je utiliser?

Question

J'ai besoin d'un système pour échanger des données très secrètes (code source qui est un secret commercial). Je vais utiliser Crypto ++ donc pratiquement je peux utiliser tous les algorithmes de cryptage, bien que je préfère vraiment utiliser un standard de l'industrie.

Actuellement, je pense à ces méthodes:

1. que le serveur génèrent 2048/4096 bits clés RSA, envoyer la clé publique au client, que le client crypter les données puis l'envoyer sur au serveur.
2. Utilisez une méthode d'échange de clés comme Diffie-Hellman (Diffie-Hellman-Merkle pour être correct) pour échanger une clé AES-256.
3. Lancez une connexion TLS et indiquez directement au serveur la clé AES.

Quelle approche pensez-vous que je devrais utiliser? Je ne suis pas préoccupé par la performance tant que c'est raisonnable; la sécurité est ce qui compte. Si aucun d'entre eux, s'il vous plaît suggérer une autre méthode.

P.S .: Je pourrais utiliser le chaînage sur l'algorithme symétrique, comme AES-Twofish-Serpent.

EDIT: Tout logiciel recommandé doit être dans une licence qui ne limitera pas l'utilisation exclusive. LGPL est aussi restrictive qu'elle doit l'être. Cela exclut la GPL.

Answer 1

Je vous recommande d'utiliser une implémentation S/MIME (ou CMS) existante avec un module cryptographique solide pour crypter votre contenu. Les données enveloppées S/MIME constituent un bon format pour le stockage des données cryptées "au repos": l'enveloppe enregistre des informations sur les algorithmes et les clés utilisés pour que l'information soit disponible plus tard aux destinataires autorisés, lorsque cela est nécessaire. De plus, même s'il ne supporte pas les «meilleurs» algorithmes (comme l'accord de clé ECDH), une bonne bibliothèque est beaucoup moins susceptible d'avoir des vulnérabilités que quelque chose écrit par un programmeur général. Comme il est loin, loin plus probable que la sécurité sera violée par une erreur de mise en œuvre que cryptanalysis, il est logique de minimiser ces erreurs.

---

Dans les protocoles légitimes, les clés publiques sont signés par l'un d'un petit nombre d'émetteurs de confiance, dont les clés publiques sont distribués par des moyens sûrs « out-of-band ». Si vous avez déjà un moyen sécurisé d'obtenir une clé publique pour l'expéditeur du message, pourquoi envoyer un autre message? Et si vous ne le faites pas, vous êtes foutu.

TLS et S/MIME dépendent de l'existence d'un ensemble de certificats CA bien connus sur chaque client. Ils sont utilisés pour signer la clé publique du serveur afin qu'un client puisse détecter les tentatives de substitution de clés. Le protocole ne peut pas s'amorcer lui-même; il doit y avoir un moyen sûr de distribuer des «ancres de confiance» hors bande.

Notez également que RSA est incroyablement lent par rapport aux chiffrements symétriques. Les protocoles réels génèrent une «clé de chiffrement de contenu» pour un algorithme symétrique comme AES, puis utilisent une clé publique RSA comme «clé de chiffrement de clé» pour chiffrer la clé de chiffrement de contenu pour le (s) destinataire (s) du message. Par conséquent, le principal problème consiste à obtenir votre clé publique auprès du client en toute sécurité. Si vous pouvez le faire, soit l'option # 1 ou # 2 est bon — en supposant que vous utilisez simplement cette clé publique, plutôt que d'essayer d'en envoyer un autre "in-band". En fait, dans CMS, l'option 1 est appelée «transport de clé» et l'option 2 est appelée «accord de clé». En pratique, le «serveur» peut utiliser un certificat émis par une autorité de certification déjà connue, ou le client peut comparer un hachage du certificat avec un certificat que vous lui avez donné par téléphone, ou vous faire une image au visage d'une falaise, ou peu importe. La chose critique est, tous de votre sécurité dépend de l'intégrité du certificat. Vous devez le protéger contre la falsification.

Alors que Crypto ++ est un "standard de l'industrie", sa sécurité dépend de comment vous l'utilisez.Just like Jerry told Kramer, "la porte doit être & hellip; fermé!" L'utilisation des primitives cryptographiques dans Crypto ++ avec un protocole mal conçu ne vous mènera nulle part.C'est pourquoi je souligne l'utilisation de CMS (un protocole de plus haut niveau) avec un bon module cryptographique (primitives cryptographiques).

Answer 2

Ne pas développer votre propre échange de clés et/ou clé protocole de provisionnement (s). C'est ce qui brise historiquement la plupart des produits et, sauf si vous êtes un cryoptographe (pas un programmeur avec une expérience cryptographique), vous vous tromperez probablement.

Utiliser des protocoles impromptu comme SSL/TLS. Par exemple. TLS initialisés avec RSA paires de clés pour les clés d'authentification mutuelle et de session AES sons correspond le pour ce que vous décrivez

Mise à jour

Bruce Schneier:

« Un collègue m'a dit une fois que le monde était plein de mauvais sécurité systèmes conçus par des personnes qui ont lu Applied Cryptography »

erickson dans son article vous a déjà donné de nombreuses raisons pour lesquelles la conception de votre propre protocole de gestion des clés et de gestion est défectueuse. Je veux juste dire à la maison pourquoi Mallory est vivant et s'en sort plutôt bien, grâce à des développeurs trop confiants:

Vous concevez le schéma que vous proposez où le client crypte avec une clé publique et vous renvoie le document. Les choses fonctionnent bien, mais 1 an plus tard, le certificat approche l'expiration. Vous envoyez un e-mail à vos clients avec le nouveau certificat contenant la clé publique que vous voulez que vos utilisateurs signent et crypte les documents pour vous. Inconnu à vous est que au cours des 4 derniers mois, votre administrateur ISP a reçu un pot de vin pour acheminer tout votre trafic IP à travers une machine distante. Votre email est intercepté avant la distribution et votre certificat joint est remplacé par un autre. Tous vos clients envoient maintenant leurs documents ultra secrets incrustés pour la clé privée de quelqu'un d'autre. Une application déchiffre chacun d'eux, les stocke, puis les crypte avec votre clé publique et vous transmet le trafic. Vous ne savez même pas ce qui se passe, jusqu'à ce que, par hasard, lors d'une visite sur le site d'un client, vous remarquiez que le certificat qu'il utilise n'est pas celui que vous avez distribué.

Vous mentionnez dans votre message une option pour enchaîner les algorithmes. Personne ne va te forcer. Votre faiblesse sera la gestion des clés, et l'attaque prendra une forme d'ingénierie sociale pour tromper quelqu'un qui utilise la mauvaise clé, ou se délecter de la clé privée (encore une fois, les pots de vin vont un long chemin). Les protocoles agréés par l'industrie prévoient des mesures pour empêcher les attaques intermédiaires, ils peuvent compter sur une infrastructure PKI qui reconnaît l'utilisation des clés et les autorités de confiance, ajouter des étapes de vérification de la liste de révocation des certificats à la validation, etc. clé, vous décrypter avec privé 'ne fait pas de secret en toute sécurité.

Answer 3

Qu'en est-il de ssh? (rsync sur ssh par exemple)?