[4173] in cryptography@c2.net mail archive
Re: Strengthening the Passphrase Model
daemon@ATHENA.MIT.EDU (Anonymous)
Tue Feb 9 13:23:43 1999
Date: Tue, 9 Feb 1999 19:00:28 +0100
From: Anonymous <nobody@replay.com>
To: cryptography@c2.net
Arnold G. Reinhold writes:
> 1. PGP should suggest a passpharse to the user when a new key pair is
> generated. PGP already has a trusted source of randomness. Why not offer a
> passphrase? There could be a choice of formats --Diceware words, random
> syllables, random letters -- and strengths (5 Diceware words provide 64 bit
> of entropy, 6 words 77 bits, 7 words 90 bits). The user could, of course,
> choose to enter his own passphrase.
It's not clear that any machine-generated passphrase with this much
entropy is going to be remembered by the users. Here are a couple of
examples of passphrases generated with Arnold's diceware tables, based
on the digits of pi:
gog gail harem full hedge allot rein
gown gas haze fz herb alley rif
You'd have to have an excellent memory to be able to remember these words
after just a few moments' study.
Some incremental improvements might be possible with a more sophisticated
generator, for example one which knew parts of speech and could produce
grammatically correct (if nonsensical) sentences. But it is still
doubtful that anything with 64-90 bits of entropy is going to be easily
remembered.
> 2. PGP should burn computer time hashing the passphrase. While you cannot
> increase the entropy of a passphrase with an algorithm, you can make
> exhaustive search far more difficult.
It does do this. PGP hashes the passphrase + salt repeatedly, until a
configurable number of bytes has been hashed. The default configuration
hashes 32768 bytes. You could patch your version of PGP to increase the
count. The maximum is 65 million. That should take a while to hash.
> One of my pet ideas is a "computational intensive" hash algorithm.
> Cryptography usually strives for algorithms that are fast and have a small
> footprint. I propose a hash algorithm tuned to use as much of the resources
> of a typical PC as possible, consistant with an acceptible user delay. This
> means lots of memory, 32 bit multplies, maybe even floating point (I say
> maybe because of the Intel FP fiasco). The algorithm should be
> parameterized in memory use and in running time such that each level jump
> increases by (say) 50%. This would allow tha user to select a delay that
> was acceptable on her machine and allow the algorithm to keep up with the
> growth in PC power.
> I have some ideas for such an alogrithm that I would be glad to share. I
> think we need a forum to develop and agree on such an algorithm.
What's wrong with iterating a cryptographically strong hash algorithm, like
PGP does?
> 3. PGP should be available on a bootable CD-ROM for the major platforms.
> (This is easy to do on a Mac, I do not know how hard it is on Wondows or
> Linux.) Running off a CD while performing encryption would make a
> virus/trojan attack difficult if not impossible. A separate utility could
> be distributed to do an SHA-1 hash of the CD.
Wouldn't you have to reboot your computer every time you wanted to encrypt
something? Or will you boot off your CD-ROM all the time? If the latter,
would you keep all your programs on CD-ROM, or just PGP? If you don't
keep all your programs on CD-ROM, then if you run a trojan-containing
word processor, for example, it can leave malicious code in memory which
will catch your PGP passphrase later.
Granted, booting off CD-ROM raises the bar for virus attackers,
which is good, but if it has any offsetting inconveniences then most
people probably won't use it. Booting from CD-ROM would be valuable in
thwarting virus attacks independent of any use of encryption, but most
people don't do it today.
> 4. We should reconsider the time honored advice to never write down one's
> passphrase. I believe most users are more fearful of forgetting their
> passphrase than of having it compromised. This is a major reason why they
> choose weak passphrases.
>
> One compromise is to suggest that users come up with the best phrase they
> are comfortable with committing to memory and then add more words chosen at
> random, with the extra words written down and kept in a safe place. This
> approach would also be useful for users who need multiple passphrases. The
> written random ones would differ and the memorized secret would remain the
> same.
This is not a bad idea, the traditional combination of "something you
have" (the written, computer generated list of words) and "something you
know" (your relatively low-entropy, memorized passphrase). If you're
going to go with computer-generated passphrases this is probably the
best way to do it.
But it does force you to clarify your threat model. What are the costs to
an attacker of acquiring a copy of the written passphrase? Where will
users put the notes? Post-its stuck to the monitor, in many cases,
no doubt. Any cracker who scams his way into a tour of the area can reap
useful information.
Such considerations may not be an issue in some applications, but it
is clear that this method will not work in all cases.
