Cryptage avec AES-256 et le vecteur D'initialisation
j'ai une question concernant l'utilisation d'un vecteur D'initialisation dans le cryptage AES. Je suis référençant les articles suivants / posts pour intégrer le chiffrement dans mon programme:
[1]Java 256-bit AES Password-Based Encryption
[2] http://gmailassistant.sourceforge.net/src/org/freeshell/zs/common/Encryptor.java.html
je suivais à l'origine la solution d'erickson depuis le premier lien mais, de ce que je peux dire, PBKDF2WithHmacSHA1 n'est pas supporté lors de mon implémentation. Donc, je me suis tourné vers le deuxième lien pour obtenir une idée pour ma propre création itérative de hachage SHA-256.
ma question vient de la façon dont L'IV est créé. Une implémentation ([1]) utilise des méthodes de la classe Cypher pour dériver le IV où sont les autres ([2]) utilise les 16 seconds octets du hachage comme IV. Tout simplement, pourquoi la différence et ce qui est meilleur du point de vue de la sécurité? Je suis un peu confus à la dérivation et l'utilisation de IVs ainsi (je comprends ce qu'ils sont utilisés pour, mais pas les différences plus subtiles), de sorte que toute clarification est également très bienvenue.
j'ai remarqué que le second lien utilise AES-128 plutôt que AES-256 ce qui me suggère que je devrais aller à SHA-512 si je voulais utiliser cette méthode. Cela semble comme il serait une exigence malheureuse que le mot de passe de l'utilisateur devrait être 16 caractères plus longtemps pour assurer un hachage sécurisé à distance et cette application est destinée à une cellule téléphone.
la Source est disponible sur demande, mais elle est encore incomplète.
je vous Remercie à l'avance.
5 réponses
L'IV ne doit pas être générée uniquement à partir du mot de passe.
le point de L'IV que même avec la même clé et plaintext est réutilisé, un crypto différent sera produit. Si L'IV est produit de façon déterministe à partir du mot de passe seulement, vous obtiendrez le même cryptogramme à chaque fois. Dans l'exemple cité, un sel est choisi au hasard, donc une nouvelle clé est générée même avec le même mot de passe.
il suffit d'utiliser un générateur de nombres aléatoires pour choisir une IV. C'est ... ce que le cryptogramme fait en interne.
je tiens à souligner que vous avez à stocker de l'IV (si vous utilisez la première méthode) ou un sel (si vous utilisez la deuxième méthode) ainsi que le cryptogramme. Vous n'aurez pas une bonne sécurité si tout est dérivé du mot de passe; vous avez besoin d'un peu d'aléatoire dans chaque message.
les cryptographes devraient générer des IV en utilisant un générateur de nombres aléatoires pseudo-aléatoires sécurisé.
les développeurs D'applications devraient utiliser la cryptographie standard existante. Je vous suggère D'utiliser SSL avec des certificats pour sécuriser votre trafic réseau et GPG pour sécuriser les données des fichiers.
il y a tellement de détails qui peuvent rendre une implémentation peu sûre, comme timing des attaques. Lorsqu'un développeur d'application prend des décisions entre AES 128 et AES 256 it est presque toujours inutile puisque vous avez probablement laissé une attaque temporelle qui rend la clé bits inutiles.
D'après ce que j'ai compris, le vecteur D'initialisation n'est qu'une entrée aléatoire dans l'algorithme de chiffrement, sinon vous obtiendriez toujours le même résultat pour la même entrée. Le vecteur d'initialisation est stocké avec le texte de chiffrement, il n'est pas secret d'aucune façon. Il suffit d'utiliser la fonction aléatoire sécurisée pour générer le vecteur d'initialisation. Les algorithmes PBKDF* sont utilisés pour dériver des clés secrètes de longueur désirée pour les algorithmes de chiffrement à partir de mots de passe entrés par l'utilisateur.
première implémentation à laquelle vous vous liez simplement permet à L'objet de chiffrer de générer un vecteur D'initialisation. Puis il récupère ce produit IV pour le stocker avec le texte de chiffrement.
le Second utilise une partie des octets de hachage. Toute approche qui génère des IV non répétitives est suffisante.
la propriété la plus importante de IV est qu'il ne répète pas (très souvent).
L'IV n'est qu'une conséquence de l'utilisation de l'enchaînement par blocs. Je présume que c'est plus qu'une simple question de conception D'API. Je suppose que vous savez que le raisonnement pour l'utiliser est de sorte que le même plaintext ne se montrera pas comme le même cryptogramme dans des blocs multiples.
pensez à la récursion à partir du dernier bloc où le bloc de chiffrement Nth dépend en quelque sorte du bloc (N-1)th, etc. Lorsque vous arrivez au premier bloc, le bloc 0th, vous avez besoin de quelques données pour commencer. Il peu importe ce que sont ces données tant que vous les connaissez avant d'essayer de les déchiffrer. L'utilisation de données aléatoires non secrètes comme vecteur d'initialisation fera apparaître des messages identiques chiffrés sous la même clé comme totalement différents.
c'est similaire dans le concept à saler un hash. Et ce code source me semble un peu louche. Une IV devrait tout simplement être frais-à-chiffrement-temps des bits aléatoires qui ne dépendent de rien, comme un nonce. L ' IV est fondamentalement partie du message crypté. Si vous re-cryptez des données identiques avec la clé identique, vous ne devriez pas être en mesure de corréler les messages. (Hey, pensez aux conséquences de corréler par longueur de cryptogramme aussi bien.)
comme tout le monde ici, j'ai toujours su que les IV devaient être choisies au hasard en utilisant les algorithmes standards.
la deuxième référence que vous avez fournie, cependant, ne semble pas faire cela. On dirait qu'il salit un mot de passe et le hache. Puis prend ce hash et le divise en deux. La moitié est la clé de cryptage, l'autre est la IV. Donc L'IV est dérivé du mot de passe.
Je n'ai pas de rupture forte pour une telle méthode, mais c'est un mauvais design. Le IV devrait être indépendant et aléatoire tout seul. Peut-être s'il y a une faiblesse dans l'algorithme de hachage ou si vous choisissez un mot de passe faible. Vous ne voulez pas être en mesure de dériver L'IV d'autre chose ou il est concevable de lancer des attaques de pré-calcul.