Question:
Puis-je utiliser le hachage SHA-512 comme clé AES?
Kaushal Khamar
2016-03-21 10:20:33 UTC
view on stackexchange narkive permalink

Je souhaite combiner le hachage et le chiffrement pour une meilleure sécurité. Alors puis-je utiliser une clé de hachage générée à partir de SHA-512 comme clé dans AES.

Par exemple, j'ai un mot de passe "secret", je calcule le hachage SHA-512 pour cela et je veux les nourrir octets comme clé pour AES.

De quoi dois-je faire attention lors de l'implémentation de ceci?

Je commencerais par lire [PBKDF2] (https://en.wikipedia.org/wiki/PBKDF2) sur Wikipedia.
Merci pour la réponse @techraf. Donc, je peux utiliser PBKDF2 au lieu de SHA pour générer la clé?
Vérifiez simplement si ce que vous voulez inventer n'est pas déjà standardisé.
Donc PBKDF2 est plus sûr que SHA? Je vais utiliser PBKDF2 pour générer la clé pour AES.
http://security.stackexchange.com/questions/16354/whats-the-advantage-of-using-pbkdf2-vs-sha256-to-generate-an-aes-encryption-key
Vous avez un mot de passe, vous avez besoin d'une clé. C'est exactement ce qu'est une "fonction de dérivation de clé" - c'est quelque chose qui crée une clé à partir d'un mot de passe. SHA-512 n'est pas une fonction de dérivation de clé, c'est un hachage, c'est le mauvais type de chose à utiliser.
Deux réponses:
d1str0
2016-03-21 11:20:22 UTC
view on stackexchange narkive permalink

Techniquement, pas comme indiqué. AES-256 nécessite une clé de 256 bits. SHA-512 produira 512 bits donc à moins que vous ne coupiez la moitié du résumé, cela ne fonctionnera pas.

Une meilleure solution est d'utiliser une fonction de dérivation de clé standard et bien testée telle que pbkdf2.

Ne lancez pas votre propre crypto à moins que cela ne soit absolument nécessaire. Utilisez des constructions approuvées.

Une chose à noter à propos du découpage de la moitié du hachage: cela supprimera la moitié de l'entropie des mots de passe! Une fonction de hachage a le grand avantage de répartir uniformément une quantité arbitraire d'entropie inégalement distribuée sur la valeur de sortie. Malheureusement, lorsque l'entrée est déjà pauvre en entropie et que vous jetez la moitié de la sortie, c'est un énorme inconvénient.
@Damon ce n'est pas vrai. Pour une fonction de hachage bien conçue, la troncature d'un hachage de 512 bits à 256 bits doit être équivalente à l'utilisation d'un hachage similaire de 256 bits. En fait, c'est exactement ainsi que fonctionne SHA-512/256. Si votre affirmation était vraie, l'utilisation de SHA-256 perdrait également la moitié de l'entropie d'un mot de passe simple (disons 64 bits), par rapport à SHA-512.
@marcelm: Étant donné n bits d'entrée d'entropie et un hachage qui a m> n bits de sortie, le hachage conserve toute l'entropie (il est peu probable qu'un mot de passe ait plus d'entropie qu'il n'en conviendra pour un hachage, alors ignorons ce cas). Mais le problème est que vous ne savez pas où se trouve l'entropie, donc jeter une partie est problématique. 512 = 8 * 64, donc chaque bit d'entrée doit affecter 4 bits de sortie en moyenne. Peut-être 4 bits dans l'une ou l'autre moitié, ou peut-être 4 au premier trimestre et 4 au deuxième trimestre, vous ne pouvez pas le savoir avec certitude (si vous pouviez le dire si facilement, le hachage serait un peu inutile). Il y a un très ...
... exemple similaire que j'ai rencontré avec curve25519 et qui m'a une fois fait réfléchir pendant un moment. DJB vous recommande de hacher la clé générée plutôt que de simplement prendre les 128 bits inférieurs. Cela semble "OK", mais un peu du côté de la paranoïa, non? Le hachage _ne fait pas mal_, mais ne devrait pas être nécessaire. Mais la vérité est que ces 256 bits sortant de l'échange de clés contiennent environ 128 bits de "force cryptographique" _et vous ne savez pas où ils se trouvent_. Prendre la moitié de la sortie ne garantit pas que votre clé a une force de 128 bits (en fait, cela garantit que ce n'est pas le cas).
@Damon Ce n'est pas ainsi que fonctionnent les fonctions de hachage.
@Damon Vous avez raison de dire qu'il est possible de perdre de l'entropie en utilisant des fonctions de hachage (en fait, c'est extrêmement probable). Cependant, cela est très éloigné de votre commentaire original indiquant que vous perdrez la moitié de l'entropie du mot de passe en passant d'un hachage de 512 bits à un hachage de 256 bits, ce qui est toujours faux pour les mots de passe typiques. Un hachage SHA-512 d'un mot de passe avec 64 bits d'entropie aura (presque) 64 bits d'entropie, tout comme un hachage SHA-512/256.
@Damon En outre, votre déclaration "Étant donné n bits d'entrée d'entropie et un hachage qui a m> n bits de sortie, le hachage conserve toute l'entropie" n'est pas catégoriquement vrai, car certaines des entrées possibles peuvent entrer en collision et produire le même hachage. Donc, si vous avez 2 ^ 64 entrées possibles, vous pourriez vous retrouver avec (2 ^ 64) -1 hachages distincts, perdant un tout petit peu de l'entropie d'origine;)
Alexey Vesnin
2016-03-21 18:54:08 UTC
view on stackexchange narkive permalink

Jusqu'ici tout va bien, mais utiliser SHA-256 comme clé AES est une bonne pratique, à mon humble avis. Surtout dans le cas de la "phrase de passe de texte" - valider la longueur et la complexité minimales - et vous êtes prêt à partir.

Ce n'est pas un bon plan. Voir l'autre réponse et commentaires sur l'utilisation d'un PBKDF.
@Xander pourquoi ce n'est pas bon? Je ne discute pas de l'utilité de PBKDF2 - mais quel est le problème * exact * de l'utilisation de sha-256 de 64+ caractères de la valeur de hachage SHA-256 de la phrase secrète non répétitive? Auriez-vous la gentillesse de le signaler?
@AlexeyVesnin Le fait qu'il n'ait pas été vérifié et jugé sûr est généralement une raison suffisante pour éviter quoi que ce soit en matière de sécurité. Si vous ne vous occupez pas de casser la crypto tous les jours, je ne vous fais pas confiance pour créer votre propre schéma de cryptographie. Comment avez-vous * quelque * confiance que cela ne crée pas une vulnérabilité subtile?
@jpmc26 * juste * par le fait qu'il n'y a pas d'attaque pour casser le sha-256 jusqu'à présent. Si vous ne pouvez pas falsifier une phrase de passe, c'est-à-dire créer deux phrases de passe avec le même hachage et une phrase de passe doit être plus courte (pour attaquer à des fins d'accélération), vous serez donc obligé de forcer brutalement au moins 64 octets dans la phrase de passe, c'est-à-dire que la complexité est TRÈS élevée, et il y a plus de 2 ^ 128 variantes, même en utilisant simplement des lettres alphabétiques anglaises en minuscules.
@AlexeyVesnin Votre argument est un homme de paille. Cela n'a rien à voir avec la question posée par l'affiche originale, ni avec la façon dont nous concevons réellement des systèmes à usage général dans le monde réel.
@Xander peut-être * vous * le concevez * comme ça, mais aucun des * made by me * n'a été piraté 18 ans d'affilée et jusqu'à présent: à partir d'un moment où j'ai appris à le faire. Et ce schéma a été utilisé plus de 5 fois dans une * variété * de tâches. Et ils travaillent toujours sans entrave, FYI.
@AlexeyVesnin d'après [cette réponse] (https://security.stackexchange.com/a/16357/97720), vous avez raison de dire qu'il n'y a pas de différence pratique entre l'utilisation de SHA-256 et PBKDF2 *** à condition que *** votreLa phrase secrète est longue et suffisamment aléatoire pour résister à une énumération systématique.L'avantage pratique de PBKDF2 est qu'il est "lent par conception" afin de rendre le forçage brutal de la pré-image beaucoup plus difficile qu'avec SHA-256 (qui est "rapide par conception").Je ne suis pas un expert, c'est exactement ce que j'ai lu dans la réponse liée


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...