Re: [Endymail] Why S/MIME and OpenPGP ecosystems fall short

[Michael Kjörling <[e-mail]>]

On 1 Jun 2015 22:07 -0700, from [e-mail] (Watson Ladd):
> Compare to what happens with GPG. Immediately the user is asked to
> make important choices with no guidance. Key discover is separate
> step. When sending messages, they have to choose several orders of
> operations and ciphers, with the wrong choice having consequences. I
> don't think any choices have the right semantics. A lot of this has
> been ruled out of scope as UI issues, but I don't think so: I think
> that solving these issues require removing many of the problems that
> we expose to users. Certainly some plugins do a very good job of
> fixing some of these headaches, but I don't think any of them are as
> reliable as TextSecure.

I have absolutely zero experience with TextSecure so cannot compare
against that, but are you talking about the _protocols and standards_
(OpenPGP) or the _implementation_ (GnuPG, PGP) in the above? GnuPG is
somewhat technical, but OpenPGP does not have to be exposed that way
to the user.

We can fix the _implementation_ by making sure the defaults offered
are reasonable and secure (according to current knowledge, adjusting
over time as necessary and maintaining a margin for error) and adding
a very first step asking whether the user wants a simple or advanced
key generation process. The simple process would use those default
values and only prompt the user for what is specifically needed
(perhaps only their name, email address and desired passphrase); the
advanced process would allow the user to select algorithm, key size,
etc just like the normal key generation process in GnuPG does today.
This would be reasonable because _the defaults should already be
reasonably safe_; if they aren't, then they should be adjusted.

The simple process could even start out by generating a small,
throwaway key pair (say, perhaps, a 256-bit RSA key pair) with a short
generation wallclock timeout _to determine the system's performance_
and adjust the key length to be generated upwards if the system is
fast enough to handle generating and using a longer key pair. _For
example_, set the default to RSA encrypt+sign with a 2048 bit modulus,
but if the system is fast enough to _generate_ a 256 bit RSA key pair
within, say, 200 ms, _then_ use 3072 bits instead; if 100 ms, _then_
4096 bits instead. (Modulus lengths and timings are arbitrary and for
example purposes only.) This will allow the software to gracefully
move toward longer keys when the system is fast enough to handle them,
without needing modification later, at the cost of a small amount of
entropy (which could in principle be fed back into the system PRNG).

With something like that, we remove at least _one_ of the major
obstacles you (quite rightly) point out, namely the user immediately
being confronted with the choice of (in my case) RSA/RSA
(sign/encrypt), DSA/ElGamal, DSA (sign only) and RSA (sign only),
followed by picking a key size. If the current defaults (with GnuPG,
dual-use RSA 2048 bits modulus) are reasonably sane then regular users
don't need to be confronted with those choices and we don't compromise
security compared to today, yet power users can be given the
opportunity to shoot themselves in the foot (or pick a higher degree
of security at the cost of some performance).

This doesn't solve key distribution and discovery, but it should solve
at least one part of key generation.

-- 
Michael Kjörling • https://michael.kjorling.se • [e-mail]
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)