Home All Groups Group Topic Archive Search About

RSACryptoServiceProvider usage question

Author
13 Apr 2005 12:05 PM
Artem Kliatchkine
Hi All,

I have two applications which need to exchange data in a secured manner. The
communication is one way only. I would like to do it the following way:
sender application "knows" the public key and uses it to encrypt the
message. Than it saves it to some known location like file. Receiver
application knows the private key, reads the message and decrypts it. Public
and private keys aren't generated ot the fly, they are saved inside the
applications permanently. Receiver application must not know the public key.
The problem is that RSACryptoServiceProvider.ToXmlString allows to save only
publicKey (ToXmlString(true) or to save public AND private keys.
Is it possible to save the private key only? Will it work if I manually
delete public key part from the resulting xml file? (I'm going to try it
now).

Thanks,
Artem Kliatchkine

Author
18 Apr 2005 10:18 AM
swat
The whole idea of private communication using asymmetric encryption is
that the private key is known to only 1 person (or application in your
case) and that the public key is known to everyone. That's why the
latter key is called 'public'. :)

I'm not sure why you would want the application that knows what the
private key is not to know what the public key is. Am I missing
something?

Furthermore, it is generally not a good security practice to store
secrets (in this case, the private key) within an application.
Author
18 Apr 2005 12:01 PM
Artem Kliatchkine
> I'm not sure why you would want the application that knows what the
> private key is not to know what the public key is. Am I missing
> something?

Actually, I wanted to somehow unify encryption and digital signature
mechanisms. Client application would keep a key which allows to decrypt data
stored on server (this key is called 'private' if RSA is used or 'public' in
case of DSN). It also must ensure that server's data hasn't been changed.
Client application can potentially be hacked so it must not contain the key
which allows to encrypt the data. Since the digital signature is more
important than keeping information in secret, I currently just use
DSNCryptoServiceProvider.

Artem Kliatchkine
Author
18 Apr 2005 10:30 AM
Valery Pryamikov
Hi,
The form of RSA private used by RSACryptoProvider (long RSA key with primes
p and q and their inverses) allows calculate public key easily just by using
information inside private key (just to calculate multiplicative inverse of
the private exponent mod (p-1)(q-1) )...
Additionally, RSACryptoProvider actually expects standard recommended public
exponent 2^16+1 and it doesn't work with a random public exponent (you can
easily see in reflector that field for public exponent uses Int32 storage
location). So, even if used with short form of RSA key - public exponent
could be easily discoverd by the owner of private key.
So, the answer to your question is: with RSACryptoProvider you can't hide
anything about public key from the owner of private key.

-Valery.
http://www.harper.no/valery


Show quoteHide quote
"Artem Kliatchkine" <el***@rambler.ru> wrote in message
news:uoDhXECQFHA.4024@TK2MSFTNGP10.phx.gbl...
> Hi All,
>
> I have two applications which need to exchange data in a secured manner.
> The communication is one way only. I would like to do it the following
> way: sender application "knows" the public key and uses it to encrypt the
> message. Than it saves it to some known location like file. Receiver
> application knows the private key, reads the message and decrypts it.
> Public and private keys aren't generated ot the fly, they are saved inside
> the applications permanently. Receiver application must not know the
> public key. The problem is that RSACryptoServiceProvider.ToXmlString
> allows to save only publicKey (ToXmlString(true) or to save public AND
> private keys.
> Is it possible to save the private key only? Will it work if I manually
> delete public key part from the resulting xml file? (I'm going to try it
> now).
>
> Thanks,
> Artem Kliatchkine
>