On Fri, Jul 22, 2005 at 11:12:10AM +0900, Curt Sampson wrote:
> On Thu, 21 Jul 2005, Thor Lancelot Simon wrote:
> 
> My thought on the matter is, first, create a user interface which as
> transparently as possible models what's going on inside.

This is what GPG does.  I think that it is a reasonable user interface
for cryptographers, and an extremely poor one for those who need a good
user interface the most: those who do not, in fact, understand the
mechanics of what they are doing.

Look what happens when even cryptography-savvy NetBSD developers try to
generate RSA encryption and signing keys with GPG: until we wrote a
cookbook example for them, about half the time they ended up with DSA
primary keys with RSA subkeys tacked onto them.  This is of course a
Bad Thing because at the same key length, it takes less computational
effort to be able to forge messages with a DSA than an RSA key; and
if you can forge messages in the primary key, you can make as many
(bogus) subkeys as you want -- not good.

Not everyone does understand the underlying cryptographic operations;
not everyone *can* understand the underlying cryptographic operations;
not everyone *should have to* understand the underlying cryptographic
operations.

Joe User ought to be able to walk up and say bpg --generate-key (or
whatever the command-line syntax is) and get a resulting object that
he can sign and encrypt with using the best current practice for
signing and encrypting (probably RSA keys somewhere north of 1024
bits, these days, with the key properties set to prefer AES and SHA512).

At least, that's how I see it.  Remember the terrible fact that those
least competent in any particular area are most likely to overestimate
their own competence; this is an area for very simple knobs and brightly
colored, large buttons, with the expert functionality tucked safely
away where you actually have to read the manual to get at it. ;-)

Thor