Re: very basic quextions: public key encryption
From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: Thu, 05 Aug 2004 16:51:09 -0600
firstname.lastname@example.org (walterbyrd) writes:
> Q: What exactly is my private key? How do I get it? Where is it
> stored? Do I only use it once? Do I have some special program that
> generates it? Do I have to be using a specific software application
> that is in sync with the senders software application?
the fundamental technology is asymmetric key cryptography ... a key
pair ... where either key is used for encoding and you need the other
of the key pair for decoding (as opposed to symmertic key cryptography
uses the same key for both encoding and decoding). the generation is
somewhat more envolved than secret key generation since there is a
complex relationship between the two keys in an asymmetric key pair.
public key cryptography is a business process using asymmetric key
cryptography technology. one of the key pair has a business
designation of "private" and the other of the key pair has the
business designation of "public".
this is can be used to address two business problems/opportunities in
symmetric key cryptography
1) secure key distribution
the designation of "public" (in theory) means you don't care who
is allowed to know your public key ... it can be sprayed all over
the world so that everybody has it. this actually only addresses
the security confidentiality problem of hiding the key. there is
still the security integrity problem of whether somebody actually
knows any specific public key is yours.
2) needing a unique shared secret (symmetric key) for every
since everybody can know your public key ... there is no security
confidentiality requirement for a unique shared secret for every
relationship ... say worst case (for shared secret symmetric key):
N*(N-1)/2 .. where N is the number of people in the world (and every
key might have to be changed every month). The problem reduces to N
asymmetric key pairs (or 2*N keys).
... so the full process ... replacing an exchanged share-secret
symmetric key ... we each have the other's public key. Instead
of symmetrically encrypting the message, where you know only
I could have encrypted the message and I know only you can
decrypt the message ....
1) I compute a secure hash (say fips180) of the message and
encode the secure hash with my private key. this is typically
referred to as the digital signature
2) i combine the message and the digital signature ... and
encrypt the combination with your public key.
3) i transmit the message
4) only you, with your corresponding private key are capable
of decrypting the message (nobody else can see it)
5) once you have decrypted the message, you verify the digital
sigatnure with my public key; i.e. a) decode the digital signature
with my public key to get the original secure hash, b) recalculate
the secure hash on the message, c) compare if the recalculated
secure hash and the decoded digital signature secure hash are
only your private key could decode the message and only my
public key can verify the digital signature.
If there isn't a concern about the secrecy of the data, then it is
possible to only digitally sign it ... this still gives you whether or
not the data has been modified in transit (integrity) and the verifies
If there isn't a concern about the origin of the data, then it is
possible to simply encrypt the data w/o a digital signature. This is
sort of like when you send off you credit card number in a SSL
SSL does an additional modification. asymmetric encryption tends to be
a lot more expensive than symmetric encryption. So when the
client-side starts up ... it generates a random session secret key
... which it uses to encrypt the actual data ... and then the session
secret key is encrypted with the server's public key. Since only the
server's private key can decrypt and obtain the random session secret
key ... it is still viewed as public key operation (from the
stand-point of key distribution problem) ... but the performance is
that of symmetric cryptography since the server then decrypts the
actual data with the randomly generated session secret key (that they
got from the client). The server doesn't actually know who the client
is ... but the client is (pretty) sure that only the server (with the
correct private key) will see the actual data.
sender/receiver or client/server ... at least need to have the other's
public key ... and have support for commonly selected cryptography
algorithms (i.e. there can be variables like key sizes and/or specific
type of asymmetric cryptography technology).
recent thread discussing RSA and ECC asymmetric cryptography
recent thread in this (comp.security.ssh) newsgroup about basics of
(public) key authentication
which included some side-thread about whether some of these questions
were class assignments ... and the etiquette of using usenet for doing
-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/