RSA private key encryption_问答_开发者_运维开发者技术经验分享

Is there any way to perform private key encryption in C#?

I know about the standard RSACryptoServiceProvider in System.Security.Cryptography, but these classes provide only public key encryption and private key decryption. Also, they provide digital signature functionality, which uses internally private key encryption, but there are not any publicly accessible functions to perform private key encryption and public key decryption.

I've found this article on codeproject, which is a very good start point for performing this kind of encryption, however, I was looking for some ready-to-use code, as the code in the article can hardly encrypt arbitrary-long byte arrays containing random values (that means any values, including zeroes).

Do you know some good components (preferably free) to perform private key encryption?

I use .NET 3.5.

Note: I know this is generally considered as bad way of using asymmetric encryption (encrypting using private key and decrypting using public key), but I just need to use it that way.

Additional Explanation

Consider you have

var bytes = new byte[30] { /* ... */ };

and you want to use 2048bit RSA to ensure no one have changed anything in this array.

Normally, you would use digital signature (ie. RIPEMD160), which you then attach to the original bytes and send over to the receiver.

开发者_运维技巧

So, you have 30 bytes of original data, and additional 256 bytes of digital signature (because it is a 2048bit RSA), which is overall of 286 bytes. Hovewer, only 160 bits of that 256 bytes are actually hash, so there is exactly 1888 bits (236 bytes) unused.

So, my idea was this:

Take the 30 bytes of original data, attach to it the hash (20 bytes), and now encrypt these 50 bytes. You get 256 bytes long message, which is much shorter than 286 bytes, because "you were able to push the actual data inside the digital signature".

ECDSA Resources

MSDN

Eggheadcafe.com

c-plusplus.de

MSDN Blog

Wiki

DSA Resources

CodeProject

MSDN 1

MSDN 2

MSDN 3

Final Solution

If anyone is interested how I've solved this problem, I'm going to use 1024bit DSA and SHA1, which is widely supported on many different versions of Windows (Windows 2000 and newer), security is good enough (I'm not signing orders, I just need to ensure that some child can't crack the signature on his iPhone (:-D)), and the signature size is only 40 bytes long.

What you are trying to design is known as a "Signature scheme with message recovery".

Designing a new signature scheme is hard. Designing a new signature scheme with message recovery is harder. I don't know all the details about your design, but there is a good chance that it is susceptible to a chosen message attack.

One proposal for signature schemes with message recovery is RSA PSS-R. But unfortunately, this proposal is covered with a patent.

The IEEE P1363 standarization group, once discussed the addition of signature schemes with message recovery. However, I'm not sure about the current state of this effort, but it might be worth checking out.

Your Public key is a sub-set of your private key. You can use your private key as a public key as it will only use the components of the full key it requires.

In .NET both your private & public keys are stored in the RSAParameters struct. The struct contains fields for:

D
DP
DQ
Exponent
InverseQ
Modulus
P
Q

If you're at the point where the data is so small that the digital signature is huge in comparison, then you have excess signature. The solution isn't to roll your own algorithm, but to cut down what's there. You definitely don't want to try to combine a key with the hash in an amateurish way: this has been broken already, which is why we have HMAC's.

So here's the basic idea:

Create a session key using a cryptographically strong RNG.
Transmit it via PKE.
Use the session key to generate an HMAC-SHA1 (or HMAC-RIPEMD160, or whatever).
If the size of the hash is absurdly large for the given data, cut it in half by XORing the top with the bottom. Repeat as needed.
Send the data and the (possibly cut-down) hash.
The receiver uses the data and the session key to regenerate the hash and then compares it with the one transmitted (possibly after first cutting it down.)
Change session keys often.

This is a compromise between the insanity of rolling your own system and using an ill-fitting one.

I'm wide open to constructive criticism...

I get it now, after reading the comments.

The answer is: don't do it.

Cryptographic signature algorithms are not algorithms from which you can pick and choose - or modify - steps. In particular, supposing a signature sig looks something like encrypt(hash), orig + sig is not the same as encrypt(orig + hash). Further, even outdated signature algorithms like PKCS v1.5 are not as simple as encrypt(hash) in the first place.

A technique like the one you describe sacrifices security for the sake of cleverness. If you don't have the bandwidth for a 256 byte signature, then you need one of: