[8208] in cryptography@c2.net mail archive
Re: migration paradigm (was: Is PGP broken?)
daemon@ATHENA.MIT.EDU (Arnold G. Reinhold)
Tue Dec 5 14:31:13 2000
Mime-Version: 1.0
Message-Id: <v04210100b652b1e6dc42@[24.218.56.92]>
In-Reply-To: <20001204192026.23882.qmail@nym.alias.net>
Date: Tue, 5 Dec 2000 10:23:29 -0500
To: cryptography@c2.net
From: "Arnold G. Reinhold" <reinhold@world.std.com>
Cc: William Allen Simpson <wsimpson@greendragon.com>
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
At 7:20 PM +0000 12/4/2000, lcs Mixmaster Remailer wrote:
>William Allen Simpson <wsimpson@greendragon.com> writes:
>> My requirements were (off the top of my head, there were more):
>>
>> 4) an agreed algorithm for generating private keys directly from
>> the passphrase, rather than keeping a private key database.=A0
>> Moving folks from laptop to desktop has been pretty hard, and
>> public terminals are useless. AFS/Kerberos did this with a
>> "well-known" string-to-key algorithm, and it's hard to convince
>> folks to use a new system that's actually harder to use. We need
>> to design for ease of use!=A0
>
>This is a major security weakness. The strength of the key relies
>entirely on the strength of the memorized password. Experience has
>shown that keys will not be strong if this mechanism is used.
I agree that the average, untutored user is likely to select a=20
passphrase too weak to achieve adequate security. On the other hand,=20
storing high-quality keys on a typical server or Internet-connected=20
PC presents security risks that are comparable in magnitude.
I believe there are applications where a passphrase generated key is=20
preferable. These include situations were keys must be retained for a=20
very long time (we know paper lasts) and where people such as=20
reporters or NGO workers have to travel to parts of world where any=20
physical keying material in their possession could get them in=20
trouble.
>
>There must be something more. At a minimum it can be a piece of paper
>with the written-down, long passphrase. Or it can be a smart card
>with your key on it. Conceivably it could also be a secure server that
>you trust and access with a short passphrase, where the server can log
>incorrect passphrase guesses. But if you can attack a public key purely
>by guessing the memorized passphrase which generated the secret part,
>the system will not be secure.
Writing down the passphrase is reasonable in many, but not all=20
situations. Hardware tokens can be damaged or lost. That risk may be=20
unacceptable in some applications. And is there is really such a=20
thing as a trustworthy, secure server? Will Santa bring me one?
I think a standard such as Mr. Simpson suggests is a worthwhile idea.=20
No one is forced to use a standard just because it exists. One size=20
does not fit all. However I would propose including an option for key=20
stretching in any such standard. Key stretchers can bridge the gap=20
between what people are willing to memorize and reasonable levels of=20
security. I have some ideas for methods that would be more effective=20
than mere repeated hashing that I would be glad to contribute.
Arnold Reinhold
