# Re: very basic quextions: public key encryption

**From:** Anne & Lynn Wheeler (*lynn_at_garlic.com*)

**Date:** 08/06/04

**Next message:**Richard E. Silverman: "Re: SFTP Batch without key"**Previous message:**Per Hedeland: "Re: SFTP Batch without key"**In reply to:**walterbyrd: "very basic quextions: public key encryption"**Next in thread:**walterbyrd: "Re: very basic quextions: public key encryption"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Thu, 05 Aug 2004 16:51:09 -0600

walterbyrd@iname.com (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

relationship

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

identical.

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

the origin.

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

encrypted session.

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

technology issues:

http://www.garlic.com/~lynn/2004h.html#30

recent thread discussion what might a digital signature actually

mean:

http://www.garlic.com/~lynn/2004h.html#13

http://www.garlic.com/~lynn/2004h.html#14

recent thread in this (comp.security.ssh) newsgroup about basics of

(public) key authentication

http://www.garlic.com/~lynn/2004h.html#21

http://www.garlic.com/~lynn/2004h.html#23

http://www.garlic.com/~lynn/2004h.html#32

http://www.garlic.com/~lynn/2004h.html#37

which included some side-thread about whether some of these questions

were class assignments ... and the etiquette of using usenet for doing

homework

-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

**Next message:**Richard E. Silverman: "Re: SFTP Batch without key"**Previous message:**Per Hedeland: "Re: SFTP Batch without key"**In reply to:**walterbyrd: "very basic quextions: public key encryption"**Next in thread:**walterbyrd: "Re: very basic quextions: public key encryption"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ] [ attachment ]