No way to encrypt with private key in C#?

[Sin Jeong-hun]

Hello.
As far as my naive textbook knowledge goes;
1)if a file is encrypted with the private key, then it can be
decrypted with the public key,
2)if a file is encrypted with the public key, then it can be decrypted
with the private key.

But the RSA class comes with C# only supports 2). I've searched the
internet and found C# designers thought I should use SignData instread
when I need to do 1). BUT, what if I need to do 1) anyway? Please
don't tell me things like "Why would do that?", "That's not what C#
RSA is designed for, use SingData". I'm in a situation which requires
me do 1), long story.

So, basically there's no way to do 1) with the BCL RSA class? If so,
is there any other third party class that does this? It doen't have to
be RSA, but any asymmetric algorithm is OK. Thank you for reading.

 

[Alun Harford]

Hello.
As far as my naive textbook knowledge goes;
1)if a file is encrypted with the private key, then it can be
decrypted with the public key,
2)if a file is encrypted with the public key, then it can be decrypted
with the private key.

Only (2) is true.

Alun Harford

 

[Jesse McGrew]

Only (2) is true.

Really? I thought (1) was how digital signatures worked: you make a
hash of the data you're signing, then encrypt it with your private
key, and everyone else decrypts it with your public key to verify that
it came from you.

Jesse

 

[Alun Harford]

Really? I thought (1) was how digital signatures worked: you make a
hash of the data you're signing, then encrypt it with your private
key, and everyone else decrypts it with your public key to verify that
it came from you.

Well the question is whether they need the public key to verify that it
came from you. In 'standard' implementations, the encryption exponent is
chosen to be something 'nice' - by default, in .NET, that's 2^16 + 1.

Your adversary now just needs to compute

m = c^(2^16+1) mod N

I'm sure this is easy (although it's 3:30am here so I'm going to bed - I
might think about it tomorrow and verify that it really is easy)

Alun Harford

 

[Alun Harford]

Well the question is whether they need the public key to verify that it
came from you. In 'standard' implementations, the encryption exponent is
chosen to be something 'nice' - by default, in .NET, that's 2^16 + 1.

Your adversary now just needs to compute

m = c^(2^16+1) mod N

I'm sure this is easy (although it's 3:30am here so I'm going to bed - I
might think about it tomorrow and verify that it really is easy)

Um... no, ignore that - it's clearly nonsense.

Alun Harford

 

[Alun Harford]

Only (2) is true.

Re-reading the question, they're both true.

I'm just not sure about 'if and only if' on (1).

Alun Harford

 

[Peter Webb]

Re-reading the question, they're both true.

No.

1. is not true. I think the OP (and possibly yourself) is confused by the
fact that most real systems have two public and two private keys - one for
each end of the link. If a file encrypted with the private key could be
decrypted with just the public key, it would be a pretty piss-poor security
mechanism. What actually happens is that the sender encrypts with the
recipient's public key, not his own (public or private) key.

 

[Marc Gravell]

Really? I thought (1) was how digital signatures worked

Yes, you can *sign* with a private key (and verify with the public),
but that isn't encryption; the payload is still unencrypted, just with
the authenticating signature/hash bundled.

Marc

 

[Peter Morris]

RSA is for encrypting keys only. If you encrypt a book for example then
someone can easily work out what the original data is by using frequency
analysis.

The trick is to encrypt using a system such as TripleDES and then use RSA to
communicate the key needed to decrypt it.

If it is possible to encrypt with your private key and decrypt with your
public key then this would be pointless because *every* can read it and in
this case you may as well send it unencrypted. The only benefit I can think
of attempting this is to prove that the document came from you.

The technique you need therefore is signing.

You say not to ask "Why would you do that" but I think it is necessary. It
might simply be the case that you are unable to do what you *think* you
want. I always say "Tell me what you need to do, not how you are trying to
do it".


http://mrpmorris.blogspot.com/2008/01/rsa-signed-streams.html


Pete

 

[Lasse Vågsæther Karlsen]

No.

1. is not true. I think the OP (and possibly yourself) is confused by
the fact that most real systems have two public and two private keys -
one for each end of the link. If a file encrypted with the private key
could be decrypted with just the public key, it would be a pretty
piss-poor security mechanism. What actually happens is that the sender
encrypts with the recipient's public key, not his own (public or
private) key.

You should be able to run data through the RSA algorithm both ways, when
thinking about the keys.

The two ways are usually called encryption and signing, from public to
private and back again.

The fact that signing *typically* works on a hash does not mean that it
can only work on a hash, and this is what the .NET algorithm seems to be
limited to. There is nothing prohibiting an application using RSA to
"encrypt" the entire file using the private key and release it, so that
everyone that wants to use it must first decrypt it with the public key.
Since most people associate cryptography with secure information hiding,
this usually rings wrong.

The reason this isn't typically done is usually both practicality and
performance. To use the file, *everyone* must decrypt it. Decryption
using RSA is much slower than ordinary symmetrical encryption algorithms.

So to first take a hash of the file and then encrypt that using the
private key (in fact, signing the data), is both more practical (only
people that wants to verify the signature needs to decrypt it) and
speedier (much less data to run through like this).

If you look up RSA on wikipedia and read the signing messages section,
you'll see the following text:

"Suppose Alice wishes to send a signed message to Bob. She produces a
hash value of the message, raises it to the power of d mod n (as she
does when decrypting a message), and attaches it as a "signature" to the
message. When Bob receives the signed message, he raises the signature
to the power of e mod n (as he does when encrypting a message), and
compares the resulting hash value with the message's actual hash value."

The important thing to notice is that with a private and public key of
the RSA algorithm, the two ways are *typically* called encryption and
signing, because people tend to associate cryptography with "hiding
information securely".

Another source of information is this:
http://www.di-mgt.com.au/rsa_alg.html

If you read through encryption/decryption and digital signing/signature
verification you'll notice it's the exact same thing, except for which
key is being used, and the addition of a message digest.

Especially noteworth is the 5th note, which reads:
"Decryption and signing are identical as far as the mathematics is
concerned as both use the private key. Similarly, encryption and
verification both use the same mathematical operation with the public key."

While I would typically still hold that producing a hash and signing
that using the RSA algorithm with a private key, the .NET implementation
is still not as useful to every and all cases as it could've been, if it
had implemented both ways identicaly, and just documented how to sign
and verify using one of the many hash algorithms also provided.

 

[Ben Voigt [C++ MVP]]

Yes, you can *sign* with a private key (and verify with the public),
but that isn't encryption; the payload is still unencrypted, just with
the authenticating signature/hash bundled.

You can also encrypt with the private key and decrypt with the public. This
doesn't provide confidentiality, but it does work.

 

[Marc Gravell]

You can also encrypt with the private key and decrypt with the public.  This

doesn't provide confidentiality, but it does work.

OK; happy to accept that; just out of curiosity, what are the intended
use-cases of this approach? Purely to broaden my knowledge?

Marc

 

[Lasse Vågsæther Karlsen]

OK; happy to accept that; just out of curiosity, what are the intended
use-cases of this approach? Purely to broaden my knowledge?

Marc

There typically is no practical use-case for this scenario that I know
of. That, however, does not mean there is none. I can think of one,
although I would probably do it differently (which is why I won't count
this as a practical scenario) where you would produce a license block,
and encrypt it with your private key. The recipient would decrypt it
with a copy of your public key, embedded into the software, and use the
license block to license the software. Think of it as a large scale
serial number. Nobody except you could produce new license codes that
the application would accept (without modifying the application).

However, signing data is using this method, it's just hidden behind one
layer of code. Basically what you do is that you make the hash of the
original data, then "encrypt" it with your private key, the same method
you could use to encrypt the original data in its entirety.

The signature can thus only be decrypted by the public key, and as
pointed out, can be used to signal that you, and only you, signed the file.

Wether you "encrypt" a small hash, or an entire file, the method is the
same.

The .NET implementation took choice in this matter out of the equation.
You can either encrypt with the public key, or sign with the private key.

 

[Ben Voigt [C++ MVP]]

It's authorization/non-repudiation and as everyone has discussed, is
normally applied to a hash to reduce the amount of data encrypted. However,
having the hash does weaken the cryptographic guarantee somewhat, as the
difficulty of finding a collision is related to the length of the encrypted
data, as well as providing two means of attacking the channel. Or in other
cases, the data itself could be not much larger than the hash, or even
smaller, in which case a hash isn't really beneficial.

You can also encrypt with the private key and decrypt with the public.
This
doesn't provide confidentiality, but it does work.

OK; happy to accept that; just out of curiosity, what are the intended
use-cases of this approach? Purely to broaden my knowledge?

Marc

 

[Arne Vajhøj]

OK; happy to accept that; just out of curiosity, what are the intended
use-cases of this approach? Purely to broaden my knowledge?

Only in the context of encrypt with own private key *and*
receiver public key.

Arne

 

[Arne Vajhøj]

RSA is for encrypting keys only.

The trick is to encrypt using a system such as TripleDES and then use RSA to
communicate the key needed to decrypt it.

That is the normal way of using it.

If you encrypt a book for example then
someone can easily work out what the original data is by using frequency
analysis.

I believe there are agreement that RSA are not suitable for
large texts, but I don't think it is simple frequency analysis that is
the problem.

I will assume that a n-bit RSA encryption will be used to
encrypt blocks of n bit text.

To do frequency analysis on that you will need to do
it on n bit items.

That is not possible. There are not atoms enough in the
universe to store a frequency table for n bit items with
the values of n used by RSA today.

Arne

 

[Sin Jeong-hun]

You can also encrypt with the private key and decrypt with the public.  This
doesn't provide confidentiality, but it does work.






- Show quoted text -

It does work? I mean, in .Net base class libraries? If so, how?

 

[rossum]

I believe there are agreement that RSA are not suitable for
large texts, but I don't think it is simple frequency analysis that is
the problem.

RSA is slow compared to Symmetric Key methods, hence the use of RSA to
encypher the short symmetric key and the use of the symmetric cypher
to encypher the bulk of the data.

rossum