On Thu, 21 Jul 2005, Thor Lancelot Simon wrote:

> 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.

This gives me an idea, actually; perhaps BPG should include a sort of
a "lint" that could criticise the security of various settings, and
provide suggestions on improvements.

E.g., you go through all of the steps of specifying what's needed to
create a key (chosing algorithms, key sizes, etc.) and then this tool
could tell you what the security trade-offs are for your various choices.

It might know things such as what you mentioned with DSA versus RSA
keys above, that 4096-bit keys are more secure than 2048, but will not
be interoperable with certain versions of other PGP programs (ideally
telling you which ones), and so-on.

Then you could decide to change your options or not.

It would also be good if organizations could publish profiles of some
sort (even if it's as simple as a scripted use of the bpg command-line
interface) for things like key generation. Then the lint checker could
critisise proposed key generation parameters against the profile, as
well. NetBSD could publish one for developers to use to check their
existing keys, as well as proposed new keys.

Ideally, this sort of thing could criticize the trust model as well.
It's very easy right now, I think, for NetBSD developers to get a false
sense of security due to using a poor trust model.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.NetBSD.org
      Make up enjoying your city life...produced by BIC CAMERA