[Gpg4win-devel] Kleopatra creates keys without separate subkey

[Ben McGinnes]

On 24/04/2015 6:47 pm, Andre Heinecke wrote:
> Hi,
> 
> On Tuesday, April 21, 2015 08:43:33 AM Werner Koch wrote:
>> Ben raised this problem on the OpenPGP WG list: It seems that Kleopatra
>> creates an sign+encrypt primary key instead of a sign primary and
>> encrypt subkey.
> 
> This was done before my time. I guess the Rationale (and what I also
> thinking) is that having a separate subkey does not increase your
> Key Security by default and thus unnecessarily complicates things.

Right up until the point where a weaker hash digest is used to bleed
info about the key which can then be used to leverage an attack
against the encrypting component.  I think that rationale may have
been true when we first moved from v2 keys to the DSA-1 keys back in,
um, 1997 or so (I think), as your key is an example of, but the
compartmentalisation has subsequently been proven to be a benefit.

It doesn't really complicate things from a practical point of view.
The vast majority of current keys use the current GPG defaults (RSA
primary & signing with RSA encrypting subkey) and once it's made the
end user generally doesn't question it because GPG automatically
equates one with the other.

The exception is those of us who deliberately step outside the
defaults to add more subkeys or play with alternative algorithms (my
key is an example of that, with an RSA primary, an RSA signing subkey
and El-Gamal encrypting subkey).  I've only been questioned once by
someone who actually noticed that the key ID/fingerprint of the
signing subkey didn't match the primary and a quick explanation
settled that (I was actually quite impressed that they noticed).

> If you want to separate storage of your primary and your subkey you
> can do this and at this point it is assumed that the user knows what
> a subkey is and is not confused by the concept.

Yes, but people doing that are usually already playing around on the
command line already.

>> That is very bad and does not match GnuPG's defaults.
> 
> Ok. If you say so I accept that ;-).

Heheh.  I've found that if just posting something which might be
clever or might be a really bad idea to gnupg-users will generally
tell me whether or not I'm on the right track within a day, two at
most.  Then just sit back and wait to see how forceful the response is
and from which quarter.  ;)

> I'm currently thinking that just using Key-Type: default
> Subkey-Type: default etc. in the GnupgKeyParams xml would be the
> best way to go here (as long as the user does not use advanced
> options) instead of hardcoding it or making in configurable (It
> currently is configurable) in Kleopatra.

It's generally been assumed by the rest of us training people in GPG
that Kleopatra was either broken or misconfigured when added to
gpg4win; I now realise that's not the case and it is just that
Kleopatra deliberately diverged from the standards according to what I
will politely call its own methodology.

The fix ought to be to have the Kleopatra default settings for new
keys in gpg4win match the defaults for GPA or, indeed, the command
line without expert settings.  The means by which this is achieved is,
of course, entirely up to you.

> There is a little bit of a Problem that we then would only show the user that 
> we are about to create a Key with default values but for this case we could 
> probably just remove the Dialog "We are about to create a key with this 
> values" to reduce UI Steps.

From the end user's perspective there should be no extra steps since
the encryption subkey is generated at the same step as the primary
key.  It's only when you're playing with alternatives (as I did) that
you would need to edit the primary key and manually add subkeys.
Obviously that is a step you want to avoid with the default
configuration (which is why it's also avoided on the command line).

> This should be small enough that I can fit it in for the next gpg4win 
> maintenance release.

Woohoo!  I look forward to being able to recommend it without needing
to say, "install this, but remove that and use this other thing
instead and then tweak this bit here" and so on.  I still don't trust
Kleopatra, but I suspect that gpg4win predates GPA and so that was why
it was never the default and why Kleopatra may have been the only
option for a GUI when the project launched.  I can't be certain,
though, because the last key I generated on Windows was made with PGP
for Desktop 5.5 (I think).  It was a long time ago, so I'm not certain
of that.  ;)

> Ideally we would have something like gpgme_inquire_genkey_defaults
> or something so that we could show the defaults to the user and fill
> the "advanced keygen options" default values accordingly. But I
> would not want to implement this for the next gpg4win release.

From an end user POV, if the defaults are selected then they should
not see anything structurally different between their keys generated
with gpg4win when compared to Linux users and OS X users or whatever
else is floating around (*BSD, Solaris, whatever).  Likewise, a
gpg4win user who uses GPA should generate the same default key type as
all of these, so it ought to be easy to verify.

Currently those of us working with tools other than gpg4win (or any
Windows system) know precisely when someone used gpg4win and Kleopatra
based solely on the key structure (and it always scares them when the
first encrypted message they receive says, "don't use Kleopatra").
It's as clearly identifiable as an nmap scan, on account of there only
being one stand alone GPG implementation to do this.  The extent to
which that can be used to determine more detail regarding a user's
system is presently unknown, though obviously certain assumptions are
often made regarding the security of any Windows system.


Regards,
Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20150424/0e0b3f89/attachment.sig>