Answered by:
Digital Signature with RSA and SHA512

Hello,
I am attempting to create a digital signature using the RSACryptoServiceProvider with a 2048 bit key as the signing algorithm and SHA512 as the message digest algorithm.
It appears that this is not possible using the default RSACryptoServiceProvider class provided with the framework.
For instance, the following code generates an exception:
<code>
string plainText = "This is the text to encrypt";
RSACryptoServiceProvider RSA = new RSACryptoServiceProvider();
RSA.FromXmlString(this.PrivateKey);
SHA512Managed hash = new SHA512Managed();
UnicodeEncoding encoding = new UnicodeEncoding();
byte[] hashedData = hash.ComputeHash(encoding.GetBytes(plainText));
byte[] signedData = RSA.SignHash( hashedData,
CryptoConfig.MapNameToOID("SHA512")
);
</code>
This is the exception:
System.Security.Cryptography.CryptographicException: Object identifier (OID) is unknown.
at System.Security.Cryptography.RSACryptoServiceProvider.MapOIDToCalg(String str)
at System.Security.Cryptography.RSACryptoServiceProvider.SignHash(Byte[] rgbHash, String str)
I have several questions:
1. Is it possible to create a signature with SHA512 with the RSACryptoServiceProvider?
2. I am constrained by requirements to create the signature using SHA512 and RSA. If I cannot do this with the default RSACryptoServiceProvider, how can I accomplish this?
3. Why does the RSACryptoServiceProvider.SignHash method only allow MD5 and SHA1 to be used as hashing algorithms?
4. While I understand that the typical use case of asymmetric encryption is to encrypt with the public key and decrypt with the private key I believe that encrypting with the private key and decrypting with the public key is an equally valid operation. Furthermore it is the essence of signing. Why isn't it possible to encrypt with the private key and decrypt with the public key using the RSACryptoServiceProvider?.
Any help would be greatly appreciated as I have spent the past week ramming my head against this problem.
Thanks in advance.
Question
Answers

Hi Patrick,
The problem here is that RSACryptoServiceProvider is a wrapper around the Windows RSA implementation, while SHA512Managed is purely managed code. Windows doesn't know anything about it.
In order to accomplish this you'd need to find a managed RSA implementation that can work with the managed SHA implementation.
For question #5, the encrypt / decrypt key pairing is also how Windows supports using RSA. While it's technically possible to go the other way, it doesn't make much sense. If you sign with your public key, then someone would need your private key to verify. In that case the private key actually becomes public
Shawn

Generally asymmetric algorithms are used to:
 Encrypt (with the public key, decrypted with the private key)
 Sign (with the private key, verified with the public key)
Operation 1 is generally called key exchange, while operation 2 is digital signatures. Not all asymmetric algorithms support all operations. For instance DSS can only be used safely for digital signatures not for key exchange. DiffieHellman can only be used for key exchange, not for digital signatures. RSA can be used for both.
You noted that the operations exposed by the RSACryptoServiceProvider mirror those provided by Windows itself. Windows uses the keys to implement patterns 1 and 2 since that is the standard way that asymmetric algorithms are used.
Shawn

I tend to lump DiffieHellman with the other public key cryptosystems in my head, but I agree its not germaine to this conversation
I'm not sure exactly why CAPI limits the operations to the one way other than that is the conventional way to use the key. There may be historical export restrictions, but not being on that team I cannot say for sure.
Getting newer CSP algorithms into the runtime (such as SHA512 and AES) is on our radar for the next release of the runtime.
Shawn
All replies

Hi Patrick,
The problem here is that RSACryptoServiceProvider is a wrapper around the Windows RSA implementation, while SHA512Managed is purely managed code. Windows doesn't know anything about it.
In order to accomplish this you'd need to find a managed RSA implementation that can work with the managed SHA implementation.
For question #5, the encrypt / decrypt key pairing is also how Windows supports using RSA. While it's technically possible to go the other way, it doesn't make much sense. If you sign with your public key, then someone would need your private key to verify. In that case the private key actually becomes public
Shawn

Thank you for your response. I had eventually come across the fact that the RSA implementation is just a thin wrapper of the Windows CAPI RSA implementation, and that is why it cannot use an algorithm implemented in managed code.
For anyone else encountering these issues, the Mono project provides managed implementations of RSA.
I agree that signing with the public key doesn't make much sense.
However, my question was not about how to sign with the public key, but rather why it is not possible to encrypt arbitrary data with the private key. Were it possible to encrypt arbitrary data with the private key the limitations of the Windows CAPI RSA implementation would not prevent signatures using stronger message digest algorithms. One could hash the message using whatever algorithm was desired and then encrypt the resulting hash with the private key to create the digital signature.
I understand the desire to simplify signing by providing convenience methods such as SignData and SignHash. However, those methods are just that: convenience methods. As I understand it, there are four atomic operations for any asymmetric algorithm implementation: Encrypt with Public Key
 Decrypt with Private Key
 Encrypt with Private Key
 Decrypt with Public Key
Shawn, thanks again for your response. Any additional clarification or insight you could provide on this question would be greatly appreciated.
 Patrick Joyce 
Generally asymmetric algorithms are used to:
 Encrypt (with the public key, decrypted with the private key)
 Sign (with the private key, verified with the public key)
Operation 1 is generally called key exchange, while operation 2 is digital signatures. Not all asymmetric algorithms support all operations. For instance DSS can only be used safely for digital signatures not for key exchange. DiffieHellman can only be used for key exchange, not for digital signatures. RSA can be used for both.
You noted that the operations exposed by the RSACryptoServiceProvider mirror those provided by Windows itself. Windows uses the keys to implement patterns 1 and 2 since that is the standard way that asymmetric algorithms are used.
Shawn

Shawn,
Thanks again for your response. However, I still have a few questions.
DiffieHellman is a Key Agreement algorithm. It is used to jointly create a shared secret over an insecure channel. It is neither used to encrypt data, nor to create digital signatures. As such, while certainly important to the field of public key cryptography, I would argue that it cannot be classified as a "Asymmetric Encryption Algorithm".
I apologize if I was not clear enough in describing my issue with the signature API. A digital signature is generated through the successive application of two algorithms a message digest (hashing) algorithm, and an asymmetric encryption (signing) algorithm. The process is as follows: Apply the message digest algorithm to the message to generate a message digest. This message digest (hash) is a one way, practically unique sequence of bits that is generated from the message.
 Encrypt the message digest generated in step 1 with the signer's private key.
 Transmit this encrypted hash along with the message.
 Apply the message digest algorithm to the transmitted message. This is the hash of the received message.
 Decrypt the signature with the signer's public key. This is the hash of the message as generated by the signer.
 If the hash generated in step 1 matches that from step 2, then the message is the same as was signed by the holder of the private key. This establishes the integrity of the message (via the matching hashes) and the identity of the sender (via the signature being signed with the private key of the sender)
My question remains: why is encryption with the private key and decryption with the public key not exposed in the RSA implementation? I've read that this may be due to historical export restrictions. Is this the case?
Thanks for your continued assistance,
Patrick Joyce 
I tend to lump DiffieHellman with the other public key cryptosystems in my head, but I agree its not germaine to this conversation
I'm not sure exactly why CAPI limits the operations to the one way other than that is the conventional way to use the key. There may be historical export restrictions, but not being on that team I cannot say for sure.
Getting newer CSP algorithms into the runtime (such as SHA512 and AES) is on our radar for the next release of the runtime.
Shawn

