On 1 Jun 2015 22:07 -0700, from [email protected] (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 • [email protected] 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) _______________________________________________ Endymail mailing list [email protected] https://www.ietf.org/mailman/listinfo/endymail
