Re: Death of PGP Key 0xFBAF5E44 at 19:03 02 Jan 1999 UTC

Mike Rosing (eresrch@msn.fullfeed.com)
Sun, 3 Jan 1999 22:22:38 -0600 (CST)

• Next message: Bruce Schneier: "Twofish speedup -- 258 clocks per block!"
• Previous message: Anonymous: "Re: Death of PGP Key 0xFBAF5E44 at 19:03 02 Jan 1999 UTC"
• Maybe in reply to: Ryan Lackey: "Death of PGP Key 0xFBAF5E44 at 19:03 02 Jan 1999 UTC"
• Next in thread: Peter Gutmann: "Re: Death of PGP Key 0xFBAF5E44 at 19:03 02 Jan 1999 UTC"

On Sun, 3 Jan 1999, Eric Rescorla wrote:

> > On Sun, Jan 03, 1999 at 02:57:04PM -0800, EKR wrote:
> > > Of course, if you use a discrete log scheme, then you can
> > > just use X=SHA(passphrase).
> >
> > How about using X=SHA(salt||passphrase), where salt is some 32-bit random
> > value stored on your hard drive? That way if the hard drive is destroyed,
> > you only have to brute force a 32-bit value, but an attacker has to brute
> > force the salt and the passphrase simultaneously which is unfeasible even
> > if the passphrase only has 40-bit entropy.
> Yeah, this is a good idea.

Make the salt something you have and the passphrase something you know.
Seems to be the ideal solution. The advantage of EC is identical to DL
in this respect, it takes much less time to regen the secret key than
using a seed to find a prime number.

Doesn't have to be stored on the hard drive, could be on a smart card
or floppy, but it's the same thing.

The math is simple: private key = SHA(what you have||what you know)
public key = (private key)*(public point) over the public curve. Simplicity
is pretty easy to implement too.

Patience, persistence, truth,
Dr. mike

• Next message: Bruce Schneier: "Twofish speedup -- 258 clocks per block!"
• Previous message: Anonymous: "Re: Death of PGP Key 0xFBAF5E44 at 19:03 02 Jan 1999 UTC"
• Maybe in reply to: Ryan Lackey: "Death of PGP Key 0xFBAF5E44 at 19:03 02 Jan 1999 UTC"
• Next in thread: Peter Gutmann: "Re: Death of PGP Key 0xFBAF5E44 at 19:03 02 Jan 1999 UTC"