[858] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: Tea Leaves: Ephemeral Shared Entropy

daemon@ATHENA.MIT.EDU (David P. Jablon)
Fri May 16 16:36:31 1997

Date: Fri, 16 May 1997 16:24:18 -0400
To: Bill Stewart <stewarts@ix.netcom.com>
From: "David P. Jablon" <dpj@world.std.com>
Cc: cryptography@c2.net
In-Reply-To: <3.0.1.32.19970515203153.0064c360@popd.ix.netcom.com>

t 06:42 PM 5/14/97 -0700, Nick Szabo wrote:
>> If Alice meets Bob at a party, how many bits of entropy can they
>> privately generate to use for future remote communications between them?
>> What I'm after is "shared entropy": unguessable numbers known only 
>> to Alice and Bob.
>> With this we can construct an add-on to public key cryptosystems which 
>> provides forward secrecy and parallel fallback mechanisms for 
>> confidentiality and authentication.

At 08:31 PM 5/15/97 -0700, Bill Stewart replied:
> How many bits of shared secret are you looking for?
> Will rolling a few dice do?  Pulling Scrabble(tm) tiles out of a bag? [...]
> The advantage of public-key cryptosystems is that you don't need
> shared secrets; you can share public keys to support future signatures,
> and if you want to generate shared secrets, you can use Diffie-Hellman
> (with signatures to prevent MITM.) 

Public-keys are great, but they can be cumbersome to
pass around at a party.  One of the nice things about a strong
password method (EKE, SPEKE, etc.) is that you can memorize
the shared secret.  Even the commonly used "fingerprint" for a
public-key must be larger than what most people can easily
remember in order to resist brute-force attack.  And writing the
key down introduces added risk.

> [With public-keys] you're also far more secure,
> since you can keep the public keys for your correspondents in
> less protected storage than you'd need for N secret keys.
> (That yellow sticky note on your wall is fine, for instance,
> as long as you write in ink and use very good glue :-)

I agree that relying upon long-term protected storage for N
secret keys is usually a needless risk.  But strong password
methods can be an easy and low-risk way to get things started,
and they don't require sticky notes.

As one example, a temporary small password is a convenient
way to initiate a secure conversation based on ad-hoc communication,
whether at a cocktail party, or during a private phone conversation.
Once the connection is established using the small shared-secret,
a large secret key, public-key, certificate-chain, or whatever can be
transmitted for more traditional encryption of future connections.

------------------------------------
David P. Jablon
Tel: +1 508 898 9024
http://world.std.com/~dpj/
E-mail: dpj@world.std.com


home help back first fref pref prev next nref lref last post