Re: Public Encryption Key

From: Anne & Lynn Wheeler (lynn@garlic.com)
Date: 04/04/03

Next message: Bill Marcum: "Re: Cryptography"

Previous message: Lazy Geek: "Cryptography"
Maybe in reply to: security_india: "Re: Public Encryption Key"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: Anne & Lynn Wheeler <lynn@garlic.com>
Date: Fri, 04 Apr 2003 20:28:52 GMT

"eric" <sopuiki@hotmail.com> writes:

> Consider the following scenerio:
>
> 1. A sends B (A, EUKb[M], B)
> 2. B acknowledges receipt by sending to A (B, EKUa[M],A).
>
> Being a user of the network, a attacker has his own public encryption key
> and is able to send his own messages to A or to B and to receive theirs.
>
> My question is, in what way can the attacker obtain message M user A has
> previously send to B??

public key technology has two different business processes defined for
it.
1) privacy; only the recepient can decode the message
2) authentication, only the sender can have sent the message

to achieve #1, encrypt the message with the recipient's public key (or
more frequently generate a random secret key, encrypt the message with
the random secret key, and encrypt the secret key with the recepient's
public key). only the recipient with the appropriate private key can
decrypt the message.

to achieve #2, encrypt the message with the sender's private key (or
more frequently take some trusted/secure hash of the message, and
encrypt the hash with the sender's private key). only that sender's
public key can decrypt/verify the message. typically it is just the
hash that is encrypted with the sender's private key and referred to
as a digital signature.

previous discussions of two distinct business processes:
http://www.garlic.com/~lynn/aadsm10.htm#keygen Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/2002f.html#9 PKI / CA -- Public Key & Private Key
http://www.garlic.com/~lynn/2003b.html#64 Storing digital IDs on token for use with Outlook

the two can be combined by: first do a digital signature of the
message and then encrypt the combination of the original message
and the digital signature.

so the vulnerabilities have to do with

1) the sender really having the recipient's real public key before
starting the process
2) the recipient really having the sender's real public key

so the business process typically somes down to each (sender and
recipient) having a table of public keys that traditionally have some
trust information conveyed by some out-of-band process.

in the pgp web-of-trust ... the parties exchange public keys and use
some additional trusted process to really validate that the keys that
have been received are really for the parties.

The traditional certification authority (PKI or CADS) model defines
things called certificates ... that is the body of the certificate has
some assertion and a public key; the CA then digitally signs the
certificate, certifying the validity of the assertion (ex: an email
address or a person's name).

In this scenario .... the sender can create a message, digitally sign
it, and then transmit to the recipient: 1) the message, 2) the
original digital signature and 3) the certificate. The recipient still
needs to have a table of public keys (aka like the web-of-trust model)
for at least certification authorities (that have been independantly
validated by some out-of-band trust process).

This addresses the scenario where the recipient has had no prior
contact or interface to the sender .... the sender can transmit a
spontaneous message to just about anybody. The recipient then can be
sure that the message has originated from an entity that matches the
assertion in the appended certificate.

However, the CA, spontaneous communication paradigm doesn't address
the privacy issue. In order for the sender to encrypt the message with
the recipient's public key, that public key needs to have been
previously stored in some table kept at the sender. That means that
the sender and recipient have had to made some previous contact and
exchanged information.

The AADS scenario assertions is that for all serious business process
communication, the sender and recipient have established some sort of
previous business relationship .... making the CA, spontaneous
communication model redundant and superfluous.
http://www.garlic.com/~lynn/aadsover.htm

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ 
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Next message: Bill Marcum: "Re: Cryptography"

Previous message: Lazy Geek: "Cryptography"
Maybe in reply to: security_india: "Re: Public Encryption Key"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Relevant Pages

Re: Public Encryption Key
... encrypt the message with the recipient's public key (or ... the two can be combined by: first do a digital signature of the ... certificate, certifying the validity of the assertion (ex: ...
(sci.crypt)
Re: how do i encrypt outgoing email
... > I am looking for a way to encrypt out going email messages in Outlook. ... public key ... ... decodes the digital signature (resulting in the ... key repositories with public keys belonging to *certification ...
(microsoft.public.outlook.installation)
Re: Entourage mail and PGP/GPG?
... You can digitally sign messages and encrypt them using CA. ... using a certificate for each recipient. ... certificate (public key) and the validation chain. ...
(microsoft.public.mac.office.entourage)
Re: RSA Encrypt/Decrypt Problems
... CAPICOM is extremely easy to use in .NET. ... use CAPICOM, you really need the certificate, not just the public key. ... > then encrypt it with the other public key. ...
(microsoft.public.dotnet.security)
Re: very basic quextions: public key encryption
... is allowed to know your public key ... ... encode the secure hash with my private key. ... i combine the message and the digital signature ... ... possible to simply encrypt the data w/o a digital signature. ...
(comp.security.ssh)