Pourquoi ai-je besoin d'utiliser la classe Rfc2898DeriveBytes (dans .NET) au lieu d'utiliser directement le mot de passe comme clé ou IV?

Question

Quelle est la différence entre l'utilisation de Rfc2898DeriveBytes et l'utilisation de Encoding.ASCII.GetBytes(string object);?

J'ai eu un succès relatif avec l'une ou l'autre approche, la première est une approche plus longue où, comme la dernière est simple et pertinente. Les deux semblent vous permettre de faire la même chose par la suite, mais je me bats pour voir le point en utilisant le premier sur le second.

Le concept de base que j'ai pu comprendre est que vous pouvez convertir les mots de passe string en tableaux d'octets à utiliser par exemple pour une classe de chiffrement symétrique, AesManaged. Via la classe RFC mais vous pouvez utiliser des valeurs salt et un mot de passe lors de la création de votre objet rfc. Je suppose que c'est plus sûr mais c'est encore une supposition sans instruction au mieux! Aussi, cela vous permet de retourner des tableaux d'octets d'une certaine taille, et bien quelque chose comme ça.

Voici quelques exemples pour vous montrer où je viens:

byte[] myPassinBytes = Encoding.ASCII.GetBytes("some password"); 

ou

string password = "P@%5w0r]>"; 
byte[] saltArray = Encoding.ASCII.GetBytes("this is my salt"); 
Rfc2898DeriveBytes rfcKey = new Rfc2898DeriveBytes(password, saltArray); 

L'objet « rfcKey » peut maintenant être utilisé pour la mise en place du .key ou Propriétés .IV sur une classe d'algorithme de chiffrement symétrique.

ie.

RijndaelManaged rj = new RijndaelManaged(); 
rj.Key = rfcKey.Getbytes(rj.KeySize/8); 
rj.IV = rfcKey.Getbytes(rj.Blocksize/8); 

'rj' devrait être prêt! La partie confuse ... donc plutôt que d'utiliser l'objet 'rfcKey', ne puis-je pas simplement utiliser mon tableau 'myPassInBytes' pour aider à configurer mon objet 'rj'? 'myPassInBytes'

J'ai essayé de le faire dans VS2008 et la réponse immédiate est NON. Mais avez-vous eu une réponse plus éclairée sur la raison pour laquelle la classe RFC est utilisée par rapport à l'autre alternative que j'ai mentionnée ci-dessus?

Answer 1

Vous ne voulez vraiment pas utiliser un mot de passe utilisateur directement comme clé de chiffrement, en particulier avec AES.

Rfc2898DeriveBytes est une implémentation de PBKDF2. Ce qu'il fait est de hacher à plusieurs reprises le mot de passe de l'utilisateur avec le sel. Cela a plusieurs avantages:

Tout d'abord, vous pouvez utiliser des mots de passe de taille arbitraire - AES ne prend en charge que des tailles de clé spécifiques.Deuxièmement, l'ajout du sel signifie que vous pouvez utiliser la même phrase secrète pour générer plusieurs clés différentes (en supposant que le sel n'est pas une constante, comme c'est le cas dans votre exemple). Ceci est important pour la séparation des clés. La réutilisation de clés dans différents contextes est l'une des façons les plus courantes de briser les systèmes cryptographiques.

Les multiples itérations (1000 par défaut) ralentissent les attaques par devinettes. Considérez quelqu'un qui essaie de deviner votre clé AES. Si vous avez juste utilisé le mot de passe, ce serait simple - essayez simplement chaque mot de passe possible comme clé. D'autre part, avec PBKDF2, l'attaquant doit d'abord effectuer 1000 itérations de hachage pour chaque deviner le mot de passe. Ainsi, même s'il ralentit légèrement l'utilisateur, il a un effet disproportionné sur un attaquant. (En fait, il est assez courant d'utiliser des comptes d'itération beaucoup plus élevés, 10000 étant généralement recommandés).

Cela signifie également que la clé de sortie finale est uniformément distribuée. Si vous avez utilisé le mot de passe, par exemple, 16 des 128 bits de la clé seraient généralement 0 (le bit ASCII élevé). Ce droit rend immédiatement la recherche de clés 65536 fois plus rapide qu'elle ne devrait l'être, même en ignorant les devinettes de mot de passe.

Enfin, AES a des vulnérabilités spécifiques avec des attaques de clés associées. Des attaques par clé associées sont possibles lorsqu'un attaquant connaît des données cryptées avec plusieurs clés, et qu'il existe une relation connue (ou supposée) entre elles. Par exemple, si vous avez crypté des données avec à la fois une clé de mot de passe "My AES key sucks" (16 octets, pour AES-128) et "MY AES KEY SUCKS", une attaque par clé associée pourrait être possible. Les attaques les plus connues actuellement ne permettent pas réellement de casser l'AES complet de cette manière, mais elles s'améliorent progressivement au fil du temps - la semaine dernière, une nouvelle attaque a été publiée qui brise 13 rounds (sur 14 au total) d'AES-256 en utilisant une attaque clé associée. Il serait profondément imprudent de croire que de telles attaques ne s'améliorent pas avec le temps.

Answer 2

Réponse courte: C'est plus sûr. Pour la même raison, il existe également un générateur aléatoire spécial dans l'espace de noms System.Security.

Pour plus de détails, voir RFC2898

Je comprends un peu partie:

avec Encoding.ASCII.GetBytes(), lorsque vous utilisez un mot de passe long, vous utiliserez au maximum les premiers octets de rj.KeySize de cela. Le reste est ignoré. Et quand votre mot de passe est plus court que le keysize, vous devrez ajouter un padding (et ajouter juste une séquence de 0 augmente la vulnérabilité).