# 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"

http://www.directoryprogramming.net

"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>

wrote:

> 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:

>

> http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/7fd9ab5...

>

> http://www.eggheadcafe.com/software/aspnet/31582085/no-way-to-encrypt...

>

> 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!

Hi,

"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

signatures.

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...

-Valery.

.

**References**:**RSA Decryption with public key?***From:*Rob Cooke

**Re: RSA Decryption with public key?***From:*Valery Pryamikov

**Re: RSA Decryption with public key?***From:*Rob Cooke

- Prev by Date:
**Re: RSA Decryption with public key?** - Next by Date:
**Re: Authenticode signing with keys on smart cards** - Previous by thread:
**Re: RSA Decryption with public key?** - Next by thread:
**problem accesing to a folder in another machine** - Index(es):