In a regular C# application which class to use for hashing: xxxManaged
or xxx
(i.e SHA1Managed
vs SHA1
) and why?
-
1The unmanaged SHA1 algorithms are in SHA1Cng and SHA1CryptoServiceProvider. SHA1 is the abstract base class these two and SHA1Managed. – R. Martinho Fernandes Mar 17 '11 at 16:15
-
Also see the answers for [this question](https://stackoverflow.com/questions/211169/cng-cryptoserviceprovider-and-managed-implementations-of-hashalgorithm). – Ioanna Aug 29 '18 at 10:26
6 Answers
The Non-managed hashes which end in ***Cng
, ie SHA256Cng, will also have platform restrictions. They are quite a bit faster than the managed alternatives, but will fail at runtime on Windows XP, for example. If you know your program will always be run on Windows 7, Vista SP1, or 2008, however, they will generally perform quite a bit better than the managed versions, even with the native interop overhead.
If you're writing a general purpose program, the ***Managed
classes will be easier to work with, as they will always work.

- 554,122
- 78
- 1,158
- 1,373
-
2@SLaks: On large hash jobs, on my box, it was nearly 12x the speed of the managed version in my last profiling run ;) YMMV, of course... (I believe the speed is highly dependent on hardware + OS, though, since it depends on whether you get the hardware acceleration.) – Reed Copsey Mar 17 '11 at 16:25
-
-
1@SLaks: No idea - I don't think my system has them, but it's still **much** faster in my testing here. That being said, I ended up using the managed versions, just because I need to support XP, and the perf. wasn't worth the development/maintenance overhead of supporting 2 versions. – Reed Copsey Mar 17 '11 at 16:32
-
1@Reed: I never knew that; thanks! It shouldn't be hard to write a wrapper method that checks `Environment.OS` and returns an `SHA512`. – SLaks Mar 17 '11 at 16:33
-
@SLaks: Nope - Easy enough to do, which is I'm sure why they implemented it the way they did... I didn't bother in my case, because I didn't care so much, but I did profile it originally (before I realized they were platform specific, which bit me later - always have to read the docs :) ) – Reed Copsey Mar 17 '11 at 16:37
-
+1 For the real-world feedback :P I'd suspect the *size* of the data being processed may make a difference (is the number of interop. calls fixed relatively fixed/a low asymptotic growth?), cypto-hardware or not. – Mar 17 '11 at 16:37
-
@pst: Yes, I suspect so as well. It's easy enough to test if you need the performance or if this will be a common operation, though. – Reed Copsey Mar 17 '11 at 16:38
-
@Reed: If the non managed classes (i.e, `SHA1`) are platform dependent, why they are available in .NET library? The main purpose of .NET is coding platform independent applications, is n't it ? It seems part of `JIT` responsibility is delegated to programmers! – Xaqron Mar 17 '11 at 21:49
-
@Xaqron: No idea why they're that way - but every method in the .NET library does show platforms - this was the first one that "bit" me for including it without checking, which is why I know about it... – Reed Copsey Mar 17 '11 at 23:50
-
1Here is some measurements which indicate the managed ones are faster: http://stackoverflow.com/questions/14850674/how-much-faster-is-the-native-implementation-of-the-native-cryptographic-hashes – codekaizen Jan 18 '15 at 06:10
-
@codekaizen That's specific to the MD5 hashing algorithm - but a lot of these are very hardware specific, as mentioned above. With SHA256, I was getting (measured) 12x speed ups. It's something that needs to be tested, though. – Reed Copsey Jan 19 '15 at 18:01
-
Here is a nice blogpost (https://wintermute79.wordpress.com/tag/sha1cng/) including a benchmark on all 3 versions of the SHA1 algorithms in .NET. I am willing to assume that the patterns observed would be similar to all triplets of Managed/Unmanaged/Cng versions of hash algorithms – Ivaylo Slavov Mar 28 '16 at 21:22
-
1@Xaqron "then why are they available" -- because unlike the "*Managed" variants, the CSP-based variants are "secure" according to Windows. The managed versions are user-space bits of code that are not "Secure" according to Windows. Unlike some OSes available today, Windows has (and has had for some time) cryptography functions which are secure from user-space tampering. This is the reason for two versions, as some projects (government) will require the use of secure cryptography components (where results, such as hashes or symm/asymm results, cannot be tampered with from a user-space process.) – Shaun Wilson Jul 21 '16 at 18:27
-
I have a wpf app which does hashing. Example ~4,5GB ISO file. `SHA1Managed` is much faster than `Sha1` – Legends Aug 15 '16 at 23:36
-
Since the SHA*Managed implementations are not a part of Windows Platform FIPS the sentence with ***Managed classes will always work is not right a bit. – Lukáš Koten Apr 17 '20 at 10:14
You should use the *Managed
variants; they're usually faster.
The *CryptoProvider
and *CNG
classes use native interop, and are usually slower.
However, I've heard that they can use hardware crypto accelerators. (I haven't checked that)
Also, the native versions are FIPS-certified; the managed versions aren't.

- 868,454
- 176
- 1,908
- 1,964
-
Does `SHA1.Create()` produce a Managed variant, or there are no guarantees, and it should be avoided?e. – R. Martinho Fernandes Mar 17 '11 at 16:19
-
2@SLaks: I personally feel the FIPS certification is not just an "also", it should be a decision point right at the top of the decision tree. 1 up nevertheless for mentioning it, very little people know about this nice little caveat :) – Willem van Rumpt Mar 17 '11 at 16:21
-
@Martinho: It checks configuration. The default is CSP (at least on my machine) – SLaks Mar 17 '11 at 16:21
-
-
@SLaks: Also true. But compliancy-after-the-fact may hurt your business ;) – Willem van Rumpt Mar 17 '11 at 16:27
-
@SLaks: Somehow I missed it when I read the docs. The [docs](http://msdn.microsoft.com/en-us/library/e7hyyd4e.aspx) say the default is CSP, but don't mention configuration. EDIT: Ok, I found it: [`
`](http://msdn.microsoft.com/en-us/library/hwayhcwf.aspx) – R. Martinho Fernandes Mar 17 '11 at 16:28 -
@Martinho: http://msdn.microsoft.com/en-us/magazine/ee321570.aspx I strongly discourage you from editing Machine.config, though. – SLaks Mar 17 '11 at 16:30
-
Do you know about any benchmarks? I'm not sure your statement that the `*Managed` variants are faster (still) holds. I ran a simple test comparing `SHA1Managed`, `SHA1Cng` and `SHA1CryptoServiceProvider`. The managed version was about half the speed (.NET 4.5, Win 8.1) of the unmanged ones. – Dirk Vollmar Jan 19 '16 at 14:01
-
Seems it depends on the input size, as this benchmark suggests: https://wintermute79.wordpress.com/tag/sha1cng/ – Dirk Vollmar Jan 19 '16 at 14:12
The *Managed versions are written using entirely Managed code, the *Provider versions are a wrapper around the APIs. So if you always use the managed versions, your code will be portable e.g. to Mono, but if you use the Provider version you'll be limited to Windows platforms.

- 12,511
- 5
- 46
- 68
Managed library is safer to use and does not incur the PInvoke overhead. Also for long-running applications (ASP.NET) where memory leaks can accumulate to bring down the server, managed is also preferable.

- 80,612
- 21
- 160
- 208
Another difference between the Managed and the CNG Non-Managed versions is the supported .Net Framework version: e.g.
- the AES Managed version starts from 3.5, while the CNG from 4.6.2 and for
- SHA512, Managed starts from 1.1 and Cng from 3.5.
However, I believe that if we are not constrained by the framework version or to support legacy OS versions, we should use the CNG versions:
- The hashing algorithms postfixed with Cng are the only ones that use bcrypt
- The fact that it might take longer is actually an advantage as it protects from brute force attacks: on the user side 300ms or 3ms makes no difference, while for an attacker it is an order 100 magnitude!

- 1,311
- 2
- 23
- 36
Managed classes are generally "safer" to use in .NET; they implement Framework-defined interfaces like IDisposable and ICryptoServiceProvider. However, they're a bit slower because of the managed component. You should use a managed class if you need to create and destroy these helpers at will, and/or if you need to implement interface-based design patterns.
Unmanaged classes are generally faster (because they are pre-compiled to machine code), but can be difficult to work with. Destroying an instance of an unmanaged class can be problematic and sometimes impossible. You should use these if there isn't a managed wrapper that will do the same thing (as you'll likely end up implementing your own wrapper for the unmanaged class to handle instantiation, interop and destruction), or if the usage is a one-off.

- 70,210
- 21
- 112
- 164
-
4**Totally wrong**. They all inherit the same base classes and are totally interchangeable. The unmanaged ones have no interop issues. – SLaks Mar 17 '11 at 16:23
-
3They all implement IDisposable and ICryptoTransform, because these are up there in the base class HashAlgorithm. And even if you were correct, the unmanaged versions would be the ones needing IDisposable, not the managed ones. That's why they're managed. – R. Martinho Fernandes Mar 17 '11 at 16:24
-
I am not "totally wrong"; I just took "nonmanaged" to be a COM or extern-accessed class instead of the .NET wrappers for same. If it's provided in the .NET framework it's "managed" in my book, whether it's a wrapper or a 100% .NET implementation of the algorithm. Half the classes in the Framework are wrappers, and we call them "managed" classes. – KeithS Mar 17 '11 at 17:55
-
Compared to the `*Managed` variants, they're unmanaged. Either way, you should delete your answer; it's not relevant to the question. – SLaks Mar 18 '11 at 14:56
-
Managed and unmanaged have a specific meaning here; see for example https://msdn.microsoft.com/en-us/library/ms223095(v=vs.110).aspx – Mark Sowul Oct 12 '15 at 15:02