none
Digital Signature with RSA and SHA-512

    Question

  • Hello,

    I am attempting to create a digital signature using the RSACryptoServiceProvider with a 2048 bit key as the signing algorithm and SHA-512 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 SHA-512 with the RSACryptoServiceProvider?
    2. I am constrained by requirements to create the signature using SHA-512 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 SHA-1 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.
    Thursday, January 12, 2006 8:30 PM

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

    Tuesday, January 17, 2006 11:58 PM
  • Generally asymmetric algorithms are used to:

    1. Encrypt (with the public key, decrypted with the private key)
    2. 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.  Diffie-Hellman 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

    Tuesday, January 24, 2006 2:00 AM
  • I tend to lump Diffie-Hellman 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 SHA-512 and AES) is on our radar for the next release of the runtime.

    -Shawn

    Thursday, January 26, 2006 9:12 PM

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

    Tuesday, January 17, 2006 11:58 PM
  • 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:
    1. Encrypt with Public Key
    2. Decrypt with Private Key
    3. Encrypt with Private Key
    4. Decrypt with Public Key
    Standard encryption, signing, and signature verification are all built on these four operations.  My question was why are only two of them exposed by the interface of the CAPI RSA CSP, and in turn the .Net wrapper of that implementation?

    Shawn, thanks again for your response.  Any additional clarification or insight you could provide on this question would be greatly appreciated.

    - Patrick Joyce
    Monday, January 23, 2006 5:00 PM
  • Generally asymmetric algorithms are used to:

    1. Encrypt (with the public key, decrypted with the private key)
    2. 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.  Diffie-Hellman 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

    Tuesday, January 24, 2006 2:00 AM
  • Shawn,

    Thanks again for your response.  However, I still have a few questions.

    Diffie-Hellman 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:
    1. 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.
    2. Encrypt the message digest generated in step 1 with the signer's private key.
    3. Transmit this encrypted hash along with the message.
    The verification process is as follows:
    1. Apply the message digest algorithm to the transmitted message.  This is the hash of the received message.
    2. Decrypt the signature with the signer's public keyThis is the hash of the message as generated by the signer.
    3. 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)
    The application of the message digest algorithm and signature (encryption) algorithm are independent.  My issue with the API provided by both .Net and the CAPI implementations of RSA is that it needlessly ties these two discrete steps together.  Because both SignData and SignHash limit the hashing algorithms to MD5 and SHA1 one cannot generate signatures with stronger message digest algorithms.  Were it possible to encrypt with the private key and decrypt with the public key this limitation would not exist.

    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
    Thursday, January 26, 2006 7:35 PM
  • I tend to lump Diffie-Hellman 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 SHA-512 and AES) is on our radar for the next release of the runtime.

    -Shawn

    Thursday, January 26, 2006 9:12 PM
  • Shawn,

    Thanks so much for all of your help.

    I look forward to the improved cryptographic support in future releases of the runtime.

    Thanks again for taking the time to answer my questions.

    Sincerely,

    Patrick Joyce
    Thursday, January 26, 2006 9:45 PM

  • leventozturk.com/engineering/sha3/

    Online CRC Calculator and code generator in C,C++,Java,Verilog,VHDL

    Wednesday, November 13, 2013 12:58 AM