L'AES dans le ASP.NET avec VB.NET
Qu'est ce qu'un bon lien ou un article sur le chiffrement d'un lien URL avec AES de passe nom d'utilisateur à un autre site web dans ASP.NET à l'aide de VB.NET en 2005?
Pour info: La réception de site web auront accès à la CLÉ privée pour déchiffrer.
AES est un algorithme symétrique. Dans un algorithme symétrique a une seule clé, de sorte que privé et public touches ne faites pas de sens.
OriginalL'auteur user80687 | 2009-03-20
Vous devez vous connecter pour publier un commentaire.
Première
Ne pas le faire! La rédaction de votre propre crypto système peut facilement conduire à faire des erreurs. Il est préférable d'utiliser un système existant, ou si non, demandez à quelqu'un qui connaît la cryptographie pour le faire. Si vous devez le faire vous-même, lisez Pratique De La Cryptographie.
Et s'il vous plaît, rappelez-vous: "Nous avons déjà assez rapide, la précarité des systèmes." (Bruce Schneier) -- Faire des choses correctes et de se soucier de la performance à plus tard.
Cela dit, si vous êtes coincé sur à l'aide d'AES pour restaurer votre choix, voici quelques conseils.
Vecteur D'Initialisation
AES est un algorithme de chiffrement par bloc. Donné une clé et un bloc de texte en clair, il la convertit à un texte chiffré. Le problème, c'est que les mêmes blocs de données génère le même texte chiffré avec la même clé, à chaque fois. Supposons donc que vous envoyez des données comme ceci:
utilisateur=Encrypt(nom d'utilisateur)&les rôles=Encrypt(UserRoles)
Ils sont deux blocs distincts, et le UserRoles de chiffrement aura le même texte chiffré à chaque fois, quel que soit le nom. Tout ce que je besoin est le texte chiffré pour un admin, et je puis déposez-la dans avec mon cipher avait nom d'utilisateur. Oups.
Donc, il y a chiffrement des modes de fonctionnement. L'idée principale est que vous allez prendre le texte chiffré en un seul bloc, et XOR dans le texte chiffré du bloc suivant. De cette façon, nous allons faire Chiffrer(UserRoles, nom d'utilisateur), et le nom de l'utilisateur le texte chiffré est affectée par la UserRoles.
Le problème, c'est que le premier bloc est toujours vulnérable - juste en voyant quelqu'un texte chiffré, je pourrais connaître leurs rôles. Entrez le vecteur d'initialisation. Le IV "démarre" l'algorithme de chiffrement et s'assure qu'elle a données aléatoires pour chiffrer le reste du flux. Alors maintenant, la UserRoles texte chiffré a le cryptogramme de l'aléatoire IV XOR souhaitez. Le problème est résolu.
Donc, assurez-vous de la génération aléatoire IV pour chaque message. Le IV n'est pas sensible et peut être envoyé en clair avec le texte chiffré. Utiliser un IV suffisamment grande, la taille du bloc doit être suffisante pour la plupart des cas.
Intégrité
AES ne fournit pas de fonctionnalités d'intégrité. N'importe qui peut modifier votre texte chiffré, et le décrypter fonctionne toujours. Il est peu probable que ça va être valide de données en général, mais il peut être difficile de savoir ce que les données sont valides. Par exemple, si vous êtes à la transmission d'un GUID chiffré, il serait facile de modifier certains bits et de générer un nom complètement différent. Qui pourrait conduire à des erreurs d'application et ainsi de suite.
Le correctif il y a à exécuter un algorithme de hachage (utiliser SHA256 ou SHA512) sur le texte en clair, et de l'inclure dans les données que vous transmettez. Donc, si mon message est (nom d'utilisateur, de Rôles), vous pourrez envoyer (nom d'utilisateur, de Rôles, de Hachage(nom d'utilisateur, Rôles)). Maintenant, si quelqu'un tente d'altérer le texte chiffré en retournant un peu, le hash n'aura plus de calcul et vous pouvez rejeter le message.
De dérivation de clé
Si vous avez besoin de générer une clé à partir d'un mot de passe, utilisez la classe intégrée: Système.De sécurité.La cryptographie.PasswordDeriveBytes. Cette offre de salage et d'itérations, ce qui peut améliorer la force de la dérivée de clés et de réduire la chance de découvrir le mot de passe si la clé est compromise.
Calendrier/replay
Edit: Désolé pour ne pas mentionner plus tôt :P. Vous devez également vous assurer que vous avez un anti-système de rediffusion. Si vous avez simplement chiffrer le message et le transmettre autour de, toute personne qui reçoit le message peut seulement renvoyer. Pour éviter cela, vous devez ajouter un horodatage du message. Si le timestamp est différente en fonction d'un certain seuil, de rejeter le message. Vous pouvez également inclure une seule fois, ID (ce pourrait être le point IV) et de rejeter temps-valide les messages qui viennent d'autres IPs en utilisant le même IDENTIFIANT.
Il est important de vous assurer de faire la vérification du hachage lorsque vous incluez les informations de synchronisation. Sinon, quelqu'un pourrait trafiquer un peu le texte chiffré et potentiellement générer un timestamp valide si vous n'avez pas de détecter de telles tentatives de brute force.
Exemple de code
Depuis, apparemment, à l'aide d'un IV correctement est controversé pour certaines personnes, voici un code qui va générer au hasard des IVs et les ajouter à votre sortie pour vous. Il va également effectuer l'étape d'authentification, assurez vous que les données chiffrées n'était pas modifié.
De sortie:
Après la suppression de l'aléatoire IV et le hachage, voici le type de sortie:
Remarquez comment le premier bloc, correspondant à "Alice; Bob; Eve;" est le même. "Des cas de coin" en effet.
Exemple sans hachage
Voici un simple exemple de passage d'un entier de 64 bits. Juste chiffrer et vous êtes ouvert à l'attaque. En fait, l'attaque se fait facilement, même avec CBC rembourrage.
De sortie:
Donc, si c'est le genre de ID que vous envoyez, il pourrait très facilement être changé pour une autre valeur. Vous devez vous authentifier à l'extérieur de votre message. Parfois, la structure du message est peu probable de tomber en place et peut sorta agir comme un garde-fou, mais pourquoi compter sur quelque chose qui pourrait peut-être changer? Vous avez besoin de pouvoir compter sur votre crypto travail correctement quelle que soit l'application.
Michael - vous semblez avoir tous les défauts bien documenté, mais ils sont soit peu probable ou très spécifiques en cas de coin qui pourrait bien ne pas s'appliquer. Votre exemple artificiel (nom d'utilisateur/UserRoles) ne permet pas d'établir la nécessité de générer des Vi Uniques pour chaque chiffrement et rend l'ensemble de l'AES lourd.
Pour couvrir votre cas, je voudrais simplement fournir Vi uniques pour le nom d'utilisateur et pour les rôles d'utilisateur de sorte que le récepteur peut déchiffrer chaque sans la possibilité de décrypter les autres. En substance, votre critique de mon code est "si quelqu'un brise le chiffrement, puis ils peuvent casser à nouveau." Et avec ce peu de
pépite de sagesse, vous downvote à moi comme "inutile" malgré le fait que j'ai réellement tous le code source nécessaire pour résoudre ce problème dans le cas général? J'apprécie vraiment vos commentaires ci-dessus, mais vous venons de voir le cas de coin ou, mieux encore, offert votre propre exemple de code.
J'ai peine à le considérer IVs à être un "cas de coin" d'un crypto-système.
OriginalL'auteur MichaelGG
J'ai écrit un billet de blog qui a un exemple de projet que vous pouvez télécharger ici (C#):
http://www.codestrider.com/blog/read/AESFileEncryptorWithRSAEncryptedKeys.aspx
Le code utilise essentiellement des AES pour le cryptage de données binaires et puis RSA chiffre la Clé et la IV à l'aide d'un X509Certificate. Donc, tant que le certificat avec la clé privée est disponible, la Clé et IV peuvent être déchiffrées, et ensuite tour à tour l'AES données chiffrées peuvent être déchiffrées ..
Vous pouvez configurer votre certificat de magasins, de sorte que le "crypteurs" seulement a accès à la clé publique du certificat, alors que le "déchiffreur" a accès à la clé privée.
Cela vous permet de crypter à l'aide de différentes Clés et IV à chaque fois et d'éviter de coder en dur quoi que ce soit.. je crois que c'est plus sûr. Il devrait y avoir rien dans le code source, qui pourrait facilement permettre à quelqu'un de décrypter vos données - et si votre système n'a jamais été compromise, vous n'aurez qu'à échanger les certificats avec des de nouveaux. Pas besoin de recompiler l'application avec de nouvelles valeurs codées en dur.. 🙂
L'exemple de code peuvent être légèrement différentes de votre utilisation, mais je pense que la technique et une partie du code peut être utile pour vous.
OriginalL'auteur markt
Vous trouverez ci-dessous une classe qui fournit l'AES Chiffrement/Déchiffrement des méthodes qui prévoient explicitement URL-amicale des chaînes pour l'utilisation dans des applications comme la vôtre. Il a aussi les méthodes de travail avec des tableaux d'octets.
REMARQUE: vous devez utiliser différentes valeurs dans la Clé et le Vecteur des tableaux! Vous ne voudriez pas que quelqu'un de comprendre vos clés par juste en supposant que vous avez utilisé ce code tel qu'il est! Tout ce que vous avez à faire est de changer certaines de nombres (doit être <= 255) dans la Clé de Vecteur et matrices.
Son utilisation est facile: il suffit d'instancier la classe et puis les appeler (en général) EncryptToString(string StringToEncrypt) et DecryptString(string StringToDecrypt) que des méthodes. Il ne pouvait pas être plus facile (ou plus sûr) une fois que vous avez cette classe.
Je suis en désaccord entièrement! Cela signifierait que j'aimerais aussi avoir à envoyer le IV avec chaque message - avec des inconvénients évidents. Il y a très moyens faciles autour de votre coin de cas (par exemple, séparer les IVs pour chaque classe de message, l'ajout d'un séparateur et certains "sel" de votre message (qui est ce que je fais), etc.
Votre downvote était complètement inapproprié ici, surtout depuis que, malgré toutes vos critiques, vous les fournissez pas de code source qui fait dos de l'un de vos points.
Sel au début du message? C'est exactement ce que une intraveineuse (IV). J'avais normalement pas downvote pour un simple bug, sauf que c'est un peu d'un problème plus important quand on fait de la crypto. Mais depuis, il semblerait qu'elle vous ennuie tellement que je vais le prendre...
Un horodatage à la fin du message de ne pas modifier le début du texte chiffré, ce qui signifie que vous pouvez fuite d'informations. Peut-être que votre application n'est pas affectée par cela, mais il est certainement pas un ensemble sécurisé approche.
OriginalL'auteur Mark Brittingham
Markt a souligné que Rijndael utilise l'algorithme de chiffrement AES. Car un géré la mise en œuvre des navires avec la .net framework (et depuis au moins 1.1), à l'aide, il devrait satisfaire les OP.
La Les docs de l'API ont une assez simple exemple d'utilisation de Rijndael comme un chiffrement et de déchiffrement des flux.
Si vous avez un moyen d'obtenir le secret partagé (par exemple, la clé privée) pour les autres site web, alors vous pourriez être en mesure de s'en tirer avec l'aide de la plaine de vieux de chiffrement symétrique (pas de clé publique, des deux côtés connaître le IV et la clé privée). C'est particulièrement le cas si votre cerveau est le "insécurité canal" à travers lequel la clé est partagée (par exemple, vous administrez les deux sites). 🙂
Vous avez absolument raison. Je ne savais pas que Rijndael utilisé l'algorithme AES.
OriginalL'auteur Arnshea