Re: RSA Decryption with public key?
- From: "Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 26 Jan 2009 14:18:27 -0600
As I previously stated, you are hung out to dry here because the entity you must interact with has created a protocol that is cryptographically unsound.
They would have been much better served to use something standards-based like SSL. Regular SSL server authentication sounds like exactly the type of thing they attempted to implement, especially given that X509 certs are involved. That's too bad.
Hopefully this won't come back to haunt them in other ways.
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
"Rob Cooke" <RobCooke@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:E5B61011-6D3A-41F3-8B5C-6DE39456265F@xxxxxxxxxxxxxxxx
The difficulty here is...
We do not have a digital signature.
The owner of the third party application expects us to pass their
application some data then they prove that their application knows the
private key by encrypting our data with the private key and giving us back
the cipher text.
If we can decrypt the cipher text using the public key provided on via their
X509 certificate, we consider the application verified.
Regardless of the merits and security (or lack there of) of this protocol,
it is the only one that we can use with this third party.
While, by convention, this backwards method is discouraged due to its
limited use cases and clear potential for confusion, it is, nevertheless,
technically possible. In our case, the third party (for whatever reason)
decided to employ this technicality and, as a result, we have been placed
into a position where we are required to complete our end of this backwards
protocol -but without any direct support from BCL classes.
"Valery Pryamikov" wrote:
On Jan 14, 5:19 pm, Rob Cooke <Rob Co...@xxxxxxxxxxxxxxxxxxxxxxxxx>
> We have an .NET 2.0 application that requires verifying that an > external
> application knows the private key in a public key, private key pair.
> The verification protocol developed by manufacturer of the external
> application involves sending the external application known data, > allowing
> the external application to encrypt the data using the private key, and > then
> verifying that the returned cipher text matches the original data once
> decrypted by our application with the public key.
> Note: The returned data is encrypted by the private key -not signed!
> From our research, the RSACryptoServiceProvider in the Framework does > not
> directly support this type of protocol. For reference:
> Has anyone found a suitable workaround for this? We have had some > success
> with Bouncy Castle. (http://www.bouncycastle.org/) However, we would > prefer
> not to include additional third party libraries due to legal concerns > and
> additional product requirements.
> Thanks in advance!
"Decryption with public key" is a misnomer (or nonsense) that have
actually caused lots of confusion and as result - lots of badly
designed systems. The thingy that with RSA often referred as
"Decryption with public key" is actually a *Signature Verification
With Message Recovery*.
Asymmetric algorithms are what they are - asymmetric. It is not only
concern use of two different keys (one for encryption, other for
decryption/ one for signature generation, other for signature
verification). They also have different security requirements for
encryption vs signature. As result they require different proofs of
security for any padding schemes that is used for encryption and
entirely different proofs of security for padding schemes used for
Now, if we talk RSA here:
RSA problem is believed to be hard, but when we talk about RSA problem
being hard we talk about RSA problem on *full domain* (any value
between 0 and mod M must be equally probable). But when you start
doing real life use of RSA, you encode your message to an integer
value between 0 and mod M, but do you really achieve uniformity of
distribution with your message encoding scheme? If you have used a
fixed encoding - then what you do is actually jumping from "RSA is
considered to be hard on full domain" to the naive "I hope RSA is
equally hard on a tiny-itsy-bitsy subset of the domain", which is
generally non true. Examples - there are numbers of attacks on fixed
encoding used with RSA, such as for example fault analysis attacks
(see Bleichenbacher for encryption, Bellcore for signatures, etc).
Secure use of RSA requires special use of encoding which makes message
distribution computationally indistinguishable from random. For
encryption - it is RSA OAEP, for signature it is RSA PSS.
or for even tighter security : for key transform (encryption) use RSA-
KEM; for signatures use "Full Domain Hash".
There are also different security requirements for public and private
exponents. And there are hundreds of known attacks on RSA when
something is used subtly incorrectly. If you want secure RSA - use
what is proven to be secure, and don't try to invent something new -
everything that could have been invented with RSA was already invented
and most probably broken before...