"Rob Cooke" <Rob Co***@discussions.microsoft.com> wrote in message
news:1F898FF1-4B59-4155-9BCF-ABD7509D5F4D@microsoft.com...
> 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/7fd9ab50-40c7-47c2-ae80-04e5ccad839d/
>
> http://www.eggheadcafe.com/software/aspnet/31582085/no-way-to-encrypt-with-pr.aspx
>
> 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,
>
> and thanks for your opinion
>
> >Completely wrong, totally insecure, grossly inefficient.
>
> - I do not think wrong: why i want signing my data. with .net you can, also,
> retrieve the data parameters from strong-name ;-)
> - perhaps insecure but still better than retrieve a trivial check:
> true/false or using symmetric algorithms
> - grossly inefficient if you dont use the chinese remainder theorem ;-)
>
> always ihmo!
>
> >Hope you only use it for your own exercises sake.
>
> i just protect my software :-I
>
> Marcello Cantelmowww.cantelmosoftware.com

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

> >CRT is only useful for private key operation because having
> >multiplicative inverses required for CRT trivially allows recovering
> >factors of N.
> >public key operations are using square and multiply, therefore - the
> >less 1s you have in binary representation of you public exponent - the
> >faster it will be.
> >-Valery
>
> exactly! I have continued to respond to: "grossly inefficient". it is
> possible 'speed up' rsa with:
>
> CRT and/or Montgomery multiplication eliminates then mod n reduction step
>
> ---
> Marcello Cantelmowww.cantelmosoftware.com

"Valery Pryamikov" wrote:

> On Jan 14, 5:19 pm, Rob Cooke <Rob Co***@discussions.microsoft.com>
> 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.
>

"Rob Cooke" <RobCo***@discussions.microsoft.com> wrote in message
news:E5B61011-6D3A-41F3-8B5C-6DE39456265F@microsoft.com...
> 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***@discussions.microsoft.com>
>> 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.
>>