Pourquoi dois-je utiliser la classe Rfc2898DeriveBytes (dans .NET) au lieu d'utiliser directement le mot de passe comme clé ou IV?
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 seconde est simple et directe. Les deux semblent vous permettre de faire la même chose finalement, mais j'ai du mal à voir l'intérêt d'utiliser le premier plutôt que le second.
Le concept de base que j'ai pu comprendre est que vous pouvez convertir des mots de passe de chaîne en tableaux d'octets à utiliser pour, par exemple, une classe de chiffrement symétrique, AesManaged. Via la classe RFC mais vous pouvez utiliser des valeurs de sel et un mot de passe lorsque vous créez votre objet rfc. Je suppose que c'est plus sûr mais c'est toujours une supposition sans instruction au mieux! De plus, cela vous permet de renvoyer des tableaux d'octets d'une certaine taille, enfin quelque chose comme ça.
Voici quelques exemples pour vous montrer d'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 configurer les propriétés .Key ou .IV sur une classe d'algorithme de chiffrement symétrique.
c'est à dire.
RijndaelManaged rj = new RijndaelManaged ();
rj.Key = rfcKey.Getbytes(rj.KeySize / 8);
rj.IV = rfcKey.Getbytes(rj.Blocksize / 8);
'rj' devrait être prêt à partir!
La partie déroutante ... donc plutôt que d'utiliser l'objet 'rfcKey', ne puis-je pas simplement utiliser mon tableau 'myPassInBytes' pour aider à configurer mon objet 'rj'?
J'ai essayé de le faire dans VS2008 et la réponse immédiate est NON. Mais avez-vous une réponse plus instruite quant à la raison pour laquelle la classe RFC est utilisée par rapport à l'autre alternative que j'ai mentionnée ci-dessus?
Vous ne voulez vraiment, vraiment pas utiliser un mot de passe utilisateur directement comme clé de cryptage, en particulier avec AES.
Rfc2898DeriveBytes est une implémentation de PBKDF2. Ce qu'il fait, c'est hacher à plusieurs reprises le mot de passe utilisateur avec le sel. Cela présente de multiples 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 dans votre exemple). Ceci est important pour la séparation des clés; la réutilisation des 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 de mot de passe. Considérez quelqu'un qui essaie de deviner votre clé AES. Si vous venez d'utiliser le mot de passe, ce serait simple - essayez simplement chaque mot de passe possible comme clé. En revanche, 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 un utilisateur, il a un effet disproportionné sur un attaquant. (En fait, il est assez courant d'utiliser un nombre d'itérations beaucoup plus élevé; 10000 est généralement recommandé).
Cela signifie également que la clé de sortie finale est uniformément distribuée. Si vous avez utilisé le mot de passe, par exemple, généralement 16 des 128 bits de la clé seraient 0 (le bit haut ASCII). Cela rend immédiatement la recherche de clés 65536 fois plus facile qu'il ne devrait l'être) , ignorant même la devinette du mot de passe.
Enfin, AES présente des vulnérabilités spécifiques avec des attaques clés associées. Des attaques de clés associées sont possibles lorsqu'un attaquant connaît des données chiffrées avec plusieurs clés et qu'il existe une relation connue (ou supposée) entre elles. Par exemple, si vous chiffrez des données avec à la fois une clé de mot de passe "Ma clé AES aspire" (16 octets, pour AES-128) et avec "MES CLÉS AES SUCE", une attaque de clé associée peut être possible. Les attaques actuellement les plus connues ne permettent pas de briser l'intégralité de l'AES de cette manière, mais elles se sont progressivement améliorées au fil du temps - la semaine dernière, une nouvelle attaque a été publiée qui rompt 13 tours (sur 14 au total) d'AES-256 en utilisant une attaque clé connexe. Il serait profondément imprudent de compter sur de telles attaques qui ne s'améliorent pas avec le temps.