This is not true.

http://msdn.microsoft.com/en-us/library/9tsc5d0z(v=vs.110).a...

The second parameter is the digest algorithm.

That's if you sign the data. If you just run Decrypt, it does not ask for a hash function. Under the hood, it uses Sha-1.

Edit: Here is a link to the golang implementation http://golang.org/pkg/crypto/rsa/#DecryptOAEP It takes a hash as the first param Here is the C# counterpart http://msdn.microsoft.com/en-us/library/system.security.cryp... It does not take in a hash function though I believe you can modify how it works although I never tried to.

I wasn't referring to explicitly signing the data.

Ah, I see. The problem is that it uses PKCS #1 v2, which defaults to SHA-1. It seems OpenSSL does the same. That is unfortunate.

Seriously? I don't do much encryption, but which .NET framework lib still uses Sha-1?

Of course, this is one of those cases where I'd imagine that MS's approach to protecting backwards compat will mean nothing but a warning thrown when you reference the old lib, and any new libraries sport a completely different API making them unsuitable as a drop-in replacement. MS protects compatibility religiously while simultaneously applying a Not Invented Here mentality to code that actually was Invented Here.

RSACryptoServiceProvider uses Sha-1. It does not ask for a hash function. I learned this recently while trying to port over a client C# program to Golang.