[RC5] How are keys kept secret?

John Campbell jcampbel at lynn.ci-n.com
Fri Apr 30 18:11:41 EDT 1999


On Fri, 30 Apr 1999, Giorgio Elsner wrote:
>
> Hi all
> Having followed for some time the discussions going on in this list, a
> question came up in my mind which clearly shows that I am completely
> dumb in the crypto business (which may come from the fact that I have no
> secrets). 

	Actually, you're not dumb. Everything you say is true - for
single-key encryption systems, like RC5 and DES. Those systems weren't
designed for network communications, though, they were designed from
protecting data that only a single entity should have access to. For that,
they're sufficient (given a large enough key size). As you point out,
though, all sorts of problems come up when you need to transfer the key to
someone else so that they can read the data. At that point, single-key
encryption becomes pretty much useless, because you need a secure channel to
send them the key, and if you have a secure channel, why don't you just send
the data over it?

	Fortunately for those of us concerned with our privacy, the
encryption systems used to protect network traffic aren't single-key
systems, they're public-key systems (actually, some of them - ssh, for
example - are single-key systems, but the transfer of the single key is
protected by a public-key system, thus circumventing most of these
difficulties - the secure channel mentioned above is set up using a
public-key system, then it reverts back to single-key because it's easier on
the CPU).

	The idea behind public-key encryption is that there's not one key,
but two related ones. Anything encrypted with the one key can only be
decrypted with its mate, and vice versa. This means that you can generate a
pair of keys, keep one of them secret, and post the other for the entire
world to see. If someone wants to send you a secure message, they can
encrypt it using your publicly known key. Your public key is useless for
decrypting this message, however. For that, its mate - your private key,
which only you have - is required.

	Similarly, if you want to send a message signed so that there's no
doubt it's from you, you can encrypt it with your private key. The recipient
(or anyone else) can then decrypt it with your public key, and, upon
recovering the plaintext, they can be certain that the original encryption
was done with your private key, and therefore that the message was from you.
Note that this doesn't prevent other people from reading your messages, only
from forging them. 

	You can, of course, combine these procedures and use both your
private key and the recipient's public key to encrypt a message. When they
get it, they'll decrypt it with their private key - thus ensuring that
they're the only one that can read it, and your public key - thus ensuring
that you're the only one who could have sent it. 

---
John Campbell
jcampbel at lynn.ci-n.com

QotD:  Look at it like this:  we either don't have the parties, or we do
have the parties.  One way involves a lot more partying than the other.  Do
I have to explain further?

--
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list