(question réécritement, veuillez consulter l'historique de l'original).
La question est là dans le titre.
Pourquoi n'y a-t-il pas de mise en œuvre MD5 gérée dans la framework .NET?
Je parle spécifiquement d'un code Dans l'espace de noms System.Security.Cryptography, je suis au courant de la catégorie MD5 abstraite (qui doit être héritée et ne peut être utilisée comme), et je suis également au courant MD5CryptoServiceProvider et MD5CNG Les deux fournissent à la fois des implémentations du CSP sous-jacent du système d'exploitation (fournisseur de services de cryptographie) et de la GNC (cryptographie de la génération de la prochaine génération), cependant, toutes ces deux implémentations sont < fort> non géré code.
J'apprécie que, tandis que là-bas devrait être "une vraie réponse" à cette question, nous (la communauté de la communauté) peut ne pas savoir si un concepteur de Microsoft Framework (ou une personne qui le sait directement) fait partie de Cette communauté, cependant, de nombreuses personnes ont offert de «suppositions éduquées» très raisonnables quant à la pensée qui entamait une mise en œuvre de MD5 gérée à partir du cadre, cependant, je suis toujours curieuse de savoir si quelqu'un connaît la "vraie" réponse à cette question.
7 Réponses :
MD5CryptoServiceProvider a été dans le .NET framework du premier jour, en fait: Notez que toutes les classes de BCL .NET qui encapsulent des algorithmes hachage héritent de HASHALGORITHM classe, donc ceux-ci peuvent être utilisés polymorphiquement ... P> public HashAlgorithm HashAlgorithm { get; set; }
-1 C'est pas correct . MD5CryptoServiceProvider n'est pas une mise en œuvre gérée.
@Anton - merci pour la modification. J'apprécie que cela peut être la spéculation en votre nom, mais le lien de blog de sécurité .NET est exactement le genre de chose que je m'attendais à poser la question (à court de concepteur-cadre de MS qui sort sur cette question! :)
De quoi parlez-vous?
System.security.Cryptography.md5
System.Security.Cryptography.md5CryptoServiceProvider < / p>
Tort! MD5CryptoServiceProvider n'est pas une mise en œuvre gérée . S'il vous plaît voir la modification à ma question.
La distinction est assez stupide. Pourquoi se déranger si le système d'exploitation fournit déjà la fonctionnalité pour vous? Beaucoup de choses dans .Net appellent simplement l'API sous-jacente directement.
@Joel - Et si vous ciblez le cadre mono ou un système d'exploitation différent? Il est parfois agréable de savoir que tout le code de votre application est entièrement géré et exécuté dans le cadre sans dépendance aux bibliothèques extérieures. Bien sûr, si vous êtes sous Windows, la distinction est plus discutable, je suis toujours curieuse sur la raison pour laquelle la mise en œuvre gérée a été omise.
Dans ce cas, Mono n'est pas pertinent. Une implémentation conforme doit fournir la fonctionnalité, mais peu importe d'où cela vient.
@Joel - Intéressant ... Je viens de vérifier les documents mono et j'ai constaté qu'ils ont inclus une classe MD5CryptoServiceProvider, mais cela utilise un code géré purement la mise en œuvre, plutôt que de déléguer la fonctionnalité au système d'exploitation / Csp! Voir ici: Go-Mono.com / Docs / ...
Il y a été là depuis le début
// Create a new instance of the MD5CryptoServiceProvider object.
MD5 md5Hasher = MD5.Create();
// Convert the input string to a byte array and compute the hash.
byte[] data = md5Hasher.ComputeHash(Encoding.Default.GetBytes(input));
// Create a new Stringbuilder to collect the bytes
// and create a string.
StringBuilder sBuilder = new StringBuilder();
// Loop through each byte of the hashed data
// and format each one as a hexadecimal string.
for (int i = 0; i < data.Length; i++)
{
sBuilder.Append(data[i].ToString("x2"));
}
// Return the hexadecimal string.
string hexMD5hash = sBuilder.ToString();
Tort! MD5.Create () Crée en interne une instance de la MD5CryptoServiceProvider (Vérifiez-la dans le réflecteur). MD5CryptoServiceProvider n'est pas une mise en œuvre gérée . S'il vous plaît voir la modification à ma question.
@Monkey_p - Pour être juste, la question a toujours spécifié une implémentation gérée .
Puisque je n'ai conçu pas le cadre, je ne peux pas dire avec certitude, mais je crois qu'ils ne se sont probablement pas pris la peine de décourager son utilisation pour des raisons de sécurité.
J'avais pensé à l'origine que la mise en œuvre non gérée serait plus rapide, mais nous savons maintenant que ce n'est pas le cas, voir: https: / /Stackoverflow.com/a/14850676/58391
Mon prochain meilleur devin d'alignement avec ce que Pavel dit dans les commentaires ci-dessus. Comme avec la plupart des caractéristiques de .NET et C #, il n'était probablement pas suffisamment avantages sur le coût pour mettre en œuvre, tester et expédier la fonctionnalité lorsque le sous-jacent non managé était déjà assez bon.
Il serait intéressant de voir une vraie réponse de quelqu'un qui a conçu la langue.
+1 C'est la seule vraie réponse jusqu'à présent. La page MSDN pour MD5CryptoServiceProvider a une note encourageant l'utilisation d'un hachage plus moderne, alors je suppose que ce n'était jamais une priorité suffisante de ré-mise en œuvre d'un algorithme qu'ils ne recommandent pas. msdn.microsoft.com/en-us/Library/ ...
Une certaine mesure contradictote votre affirmation selon laquelle un CSP natif est plus rapide: byterot.blogspot.de/2013/01/...
En outre, plus de mesure indique que la performance n'est pas la raison: Stackoverflow.com/a/14850676/58391
@CODAIZEN - Merci, j'ai mis à jour la réponse pour refléter ces données.
MD5 ne convient pas à un objectif cryptographique ou de vérification de fichier, à l'exception de l'erreur éventuellement de la détection d'erreurs de transmission. Ceci est probablement un effort pour amener les gens à se déplacer vers des hachages mieux comme Sha-1 ou préférables SHA-256.
En .NET Tout ce qui se termine à CryptoServiceProvider enveloppe l'API de Windows Windows non gérés. Tout ce qui se termine dans Géré est écrit entièrement dans une langue gérée. Link Texte
Au fur et à mesure que d'autres personnes ont déclaré que vous ne devriez plus utiliser MD5. Vous devez utiliser SHA-256 qui, dans .NET, a une implémentation gérée. Vous êtes prêt à aller commercialiser jusqu'à un meilleur algorithme. (Edit) Comme MD5 n'est plus casher, il y a peu de chances d'être mis à jour dans une version ultérieure de .NET pour être entièrement gérée car vous ne devez plus l'utiliser de toute façon.
Ceci est entièrement de spéculation basé sur la lecture de nombreux postes de divers blogueurs de Microsoft (bien que la personne particulière qui ait pris cette décision). Il n'y a pas de mise en œuvre MD5 gérée dans la structure .NET, car:
1) Une implémentation était déjà disponible dans l'API de Crypto Windows non gérées et ils ne pouvaient pas se permettre, ou plus probablement qu'ils avaient mieux à faire que, consacrer des ressources à la mise en œuvre de quelque chose qui pourrait déjà être enveloppé d'un sous-jacent non géré. la mise en oeuvre. Plus d'informations sur les raisons pour lesquelles ils peuvent faire cette décision peut être trouvée en lisant Combien d'employés de Microsoft faut-il pour changer d'ampoule? , moins 100 points (s'applique au compilateur C # mais démontre la même mentalité de dépenses de ressources où elles font le plus de bons), Pourquoi ne peut-il pas mettre en œuvre des méthodes" Top Niveau "? (un autre regarde Les ressources nécessaires à une fonctionnalité unique) et Les fonctionnalités n'existent pas par défaut (liée à partir de ici ). Aucune de ces réponses à la question spécifique, mais elles démontrent tous que la rédaction du nouveau code nécessite de nombreuses ressources, des ressources pouvant être mieux dépensées ailleurs. Vous pouvez affirmer que l'emballage du code non gérée sous-jacent nécessite toujours des ressources, mais je ne pense pas qu'il ne reste aucun doute sur le fait qu'il y aurait une économie nette par le code de réécriture qui est déjà disponible, testée et travaillant.
2) plus tard, ou éventuellement près du même moment, Les recherches ont prouvé la faisabilité d'attaques de collision contre MD5 . À ce stade, la barre déjà élevée à la ré-écrite de MD5 dans le code géré est probablement encore plus élevée. Une fois le cycle de vie du développement de la sécurité dicté N'utilisez pas de crypto banni , je peux imaginer une version gérée de MD5 serait la dernière chose à laquelle ils consacreraient des ressources à.
Bien que ma réponse soit entièrement spéculative, il n'est pas difficile de comprendre que même Microsoft a des ressources limitées et une grande liste de fonctionnalités qu'ils souhaitent inclure. Les choix doivent être faits et ces décisions affecteront presque toujours un certain segment de développeurs.
En clôture, vous avez dit vous-même qu'il y ait des classes de 3ème partie MD5Gutée, ou vous pouvez toujours rouleau votre propre . Une version gérée de MD5 pourrait être un " Fonction de cinq minutes ", mais si c'est vraiment, alors comme programmeurs nous pouvons nous écrire nous-mêmes.
Ongledge - Bien que j'apprécie cela, c'est une spéculation (comme vous l'indiquez par votre propre admission), cette réponse est très utile et offre une grande perspicacité. +1 Merci.
Tout le monde a raté le point de votre question parce que c'était trop frickin 'long . Garder simplement le titre + Deux derniers paragraphes seront parfaits.
Étant donné que c'est une partie de la bibliothèque standard de CLI, pourquoi voudriez-vous vous soucier? La façon dont il est fait est un détail de mise en œuvre.
Array.copy est également non géré, mais cela ne dérange personne et n'a pas de conséquences réelles pour les clients. Qu'est-ce qui changerait si vous aviez un fournisseur MD5 géré dans le cadre?@WCOENEN - OK, j'ai fait des gaufres sur un peu, cependant, l'étendue et les détails de ma question étaient là-bas dans le titre, et j'utilise spécifiquement les mots "Mise en œuvre gérée" au moins 9 fois. !!! Pourquoi est-ce si difficile à saisir? Néanmoins, j'ai édité ma question pour raccourcir, clarifier et fournir une mise à jour.
Il est intéressant de noter que .NET conserve l'accès à l'API Cryptoapi (ou Cryptong), car ces alglorithmes sont des fiducies conformes. Les versions purement gérées peuvent être plus rapides et garantie sûre et non spécifique à la plate-forme - mais si vous activez la stratégie de la machine à autoriser uniquement les algorithmes conformes à FIPS, les gérées deviennent indisponibles.
MD5 n'est pas conforme à aucune implémentation.