Est-ce que Rijndael lance toujours une exception si le mot de passe n'est pas correct?

Question

J'utilise Rijndael pour crypter/décrypter certaines images sensibles qui seront utilisées sur certains documents. J'essaie d'être absolument sûr que le mot de passe fourni fonctionne et que, par une certaine bizarrerie du destin, un mot de passe incorrect se traduira par une image corrompue qui finit sur le document. Si je ne comprends pas avant ce point, beaucoup de documents et d'argent finira par être jeté. Mon plan actuel est de créer une somme de contrôle MD5 pour stocker avec les images. Si le MD5 du flux décrypté est différent du flux d'origine, je sais que le mot de passe était incorrect. Cependant, lors des tests, il apparaît qu'un mot de passe incorrect entraîne la levée d'une exception.

Est-ce vrai 100% du temps? Puis-je supprimer la somme de contrôle et attraper une exception?

Answer 1

Avec tous les algorithmes à clé symétrique dans .Net, la vérification se produit au dernier bloc, qui contient les informations de remplissage (généralement PKCS7). Si le dernier bloc déchiffré ne contient pas d'informations de remplissage valides, on supposera que les données sont 'mauvaises' (ou que la clé est 'mauvaise'). Pour cipher chainning block modes, cette méthode est assez bonne, car il y a une très faible probabilité qu'une collection accidentelle corresponde à un format d'information de remplissage valide. Pour les modes ECB, les choses changent, mais le mode ECB est brisé de toute façon et ne devrait jamais être utilisé.

De nombreuses applications utilisent des nombres et du texte «magiques» au début des données pour valider le format de contenu déchiffré. 100%, la précision pare-balles exigerait que vous ajoutez probablement un HMAC de votre choix aux données. Si vous avez le contrôle sur votre format, je vous recommande fortement de signer les données cryptées.

Answer 2

Le cryptage n'utilise pas de mot de passe, il utilise une clé. Le décryptage ne provoque pas automatiquement une exception lorsque la clé est erronée, ce qui signifierait que la clé pourrait être extraite des données cryptées, ce qui rendrait le chiffrement inutile. Le décryptage produira toujours un résultat, mais ce sera une poubelle aléatoire à moins que la clé soit la bonne. Comme Remus l'a souligné, le rembourrage du dernier bloc peut être utilisé pour attraper des données incorrectes, mais certains fichiers n'ont pas besoin de rembourrage du tout, et parfois des données incorrectes peuvent produire quelque chose qui ressemble à un remplissage correct.

Où obtenez-vous l'exception? Est-ce lorsque vous essayez de charger les données décryptées en tant qu'image? Dans ce cas, vous ne pouvez pas vous fier à cela comme une méthode sûre à 100% pour savoir si la clé était correcte, car il y a peu de chance que des données aléatoires puissent former quelque chose qui puisse être chargé en tant qu'image.

Le stockage d'une somme de contrôle MD5 des données d'origine avec les données cryptées n'est pas non plus une bonne idée. Cela signifie que vous avez des informations sur les données d'origine qui ne sont pas cryptées, et qui pourraient être utilisées pour casser la clé.