public and private key pair in Java

[tmuldner]

Hi, I have the following question:
If I encrypted some text with the public key K, and tried to decrypt it
with a wrong key (i.e. a key which is NOT the corresponding private
key), will I get an exception, or is there is a boolean function to
test whether the right key has been used?

 

[Benji]

Hi, I have the following question:
If I encrypted some text with the public key K, and tried to decrypt it
with a wrong key (i.e. a key which is NOT the corresponding private
key), will I get an exception, or is there is a boolean function to
test whether the right key has been used?

without knowing anything about the process, I'm going to guess "no", since
as far as I know, encrypted strings are just opaque structures, and it
would have no way of being able to tell what was used to encrypt it.

that being said, why don't you just try it out rather than posting to a
newsgroup?

 

[Oliver Wong]

Hi, I have the following question:
If I encrypted some text with the public key K, and tried to decrypt it
with a wrong key (i.e. a key which is NOT the corresponding private
key), will I get an exception, or is there is a boolean function to
test whether the right key has been used?

Different implementations of different public key cryptography systems
behave differently.

Some may be able to detect a non-matching key being used and report
this, others will happily decode an encrypted stream into something which
may or may not be meaningful to you.

- Oliver

 

[solid]

I was talking about the Java implementation

 

[Oliver Wong]

I was talking about the Java implementation

My understanding is that the Sun's class library in the java.security
package (if that's what you're talking about) doesn't provide any one
specific implementation. A lot of the constructors or factory methods take,
as arguments, an algorithm to use, and a provider.

So there isn't "the" Java implementation; there are many Java
implementations.

- Oliver

 

[solid]

Ok, is there ANY Java implementation that would support checking if the
right key has been used?

 

[Oliver Wong]

Ok, is there ANY Java implementation that would support checking if the
right key has been used?

I couldn't find any documentation directly answering your question. If
you wish to pursue the research, I found a list of standard algorithms
included with the JCE at
http://java.sun.com/j2se/1.5.0/docs/guide/security/jce/JCERefGuide.html#AppA

That being said, you could always check that the right key was used in
your own code, rather than depending on the algorithm. You could, for
example, prepend every message to encryp with a magic string "URD WINNAR!",
and then, upon decrypting, check that messages still contain that same magic
string (and strip it before delivering it to the user). Or you could store
an MD5 hash of the message, etc.

- Oliver

 

[Roedy Green]

Hi, I have the following question:
If I encrypted some text with the public key K, and tried to decrypt it
with a wrong key (i.e. a key which is NOT the corresponding private
key), will I get an exception, or is there is a boolean function to
test whether the right key has been used?

If you are talking in general terms, nope, just gibberish. You can
test if it is gibberish by encrypting a digest along with it, then
when you recompute the decrypted digest, it won't match if you used
the wrong key. Some particular encrypting package may do that for you
as a matter of course. If you had signed the original message, that
step would not be necessary. The problem would show up when you went
to validate the signature.

 

[Roedy Green]

I was talking about the Java implementation

See http://mindprod.com/jgloss/jce.html

You can test out various algorithms fairly easy to find out.

Since algorithms are implemented by third party plug-ins, an
experiment is the only sure way to be safe.

 

[Gordon Beaton]

That being said, you could always check that the right key was used
in your own code, rather than depending on the algorithm. You could,
for example, prepend every message to encryp with a magic string
"URD WINNAR!", and then, upon decrypting, check that messages still
contain that same magic string (and strip it before delivering it to
the user). Or you could store an MD5 hash of the message, etc.

One shouldn't have to use the same tool to encrypt and decrypt, it
should be sufficient to use the same algorithm with the appropriate
keys, so changing the contents in order to detect that the decryption
key was correct is less than ideal.

Adding a custom header to the start of the contents will make it hard
to use that document with other decryption tools, and it will weaken
the encryption.

(sorry I don't have an answer to the original question).

/gordon

 

[Stefan Schulz]

Ok, is there ANY Java implementation that would support checking if the
right key has been used?

Just store a signature on the original content somewhere, and verify that
signature once you have decrypted the contents. If it matches, your
chances are extremely high that the right key has been used.

 

[Jan Peter Stotz]

Ok, is there ANY Java implementation that would support checking if the
right key has been used?

You can check it yourself if you have the needed cryptographic knowledge.
For example an RSA keypair can be checked by multiplying the
RSAPrivateKey.getPrivateExponent() with the RSAPublicKey.PublicExponent().
If the result is equal to RSAPublicKey.getModulus() and equal to
RSAPrivateKey.getModulus() you have a valid keypair.

Jan

 

[Chris Uppal]

That being said, you could always check that the right key was used in
your own code, rather than depending on the algorithm. You could, for
example, prepend every message to encryp with a magic string "URD
WINNAR!", and then, upon decrypting, check that messages still contain
that same magic string (and strip it before delivering it to the user).

Not a good idea, never give out more information than you have to. Adding a
known plaintext makes decryption easier.

Or you could store an MD5 hash of the message, etc.

Appending a SHA1 (or better) hash to the end of the message would certainly
allow you to tell whether you had used the right key for decryption. Or even a
simple checksum or other non-crypto-quality hash[*]. Since you aren't using
the hash to verify that the massage hasn't been tampered with, you are not
asking it to defend you against a malicious attacker, but just against bad
luck. Or the message might have enough internal structure that you can verify
that it makes sense without using a hash at all. (E.g. if it's supposed to be
an XML document then the output should be structurally valid)

I doubt if any crypto algorithm has (or is known to have) any way of verifying
a key against a message other than using the key to decrypt the message, and
then seeing if the result makes sense. If the algorithm had a structure such
that you could tell that the internal state of the decryption engine had become
invalid (i.e. that you were using a wrong key) then that would constitute a
very significant weakness in the algorithm since it would massively cut down
the effort of breaking the encryption by brute force.

-- chris

([*] such as MD5 or SHA1 ;-)

 

[Roedy Green]

then that would constitute a
very significant weakness in the algorithm since it would massively cut down
the effort of breaking the encryption by brute force.

The cracker would know too early that this was a dead end and go onto
something else . That is one of the reasons error messages when you
logon often don't tell you if the problem is the userid or password.
They don't want to give away anything to make the cracker's job
easier.

 

[Roedy Green]

You can check it yourself if you have the needed cryptographic knowledge.
For example an RSA keypair can be checked by multiplying the
RSAPrivateKey.getPrivateExponent() with the RSAPublicKey.PublicExponent().
If the result is equal to RSAPublicKey.getModulus() and equal to
RSAPrivateKey.getModulus() you have a valid keypair.

but that is not the same thing as knowing it was the public key used
to encrypt the message. That just verifies your keystore has not been
corrupted.