Miscellaneous questions

David Shaw dshaw at jabberwocky.com
Wed Apr 16 00:04:15 CEST 2008

On Mon, Apr 14, 2008 at 11:22:59PM +0200, Herbert Furting wrote:

> > > While the standard seems to allow this,.. gpg does not (it won't sign a UID
> > > when the a self-sig has been revoked before).
> > > How can I solve this?
> > GPG allows this.  Add "--expert" to your command line when you want to
> > re-sign the UID, and GPG will allow you to do what you want.
> Ah great,... and it will work with gpg,... I mean a layout like,
> [pubkey packet]
> [UID packet]
> [positive user certification 1]
> [revoc of positive user certification 1]
> ???[positive user certification 2 (with better algos)]

It will work with GPG.  I can't speak for other programs, but it's
legal by the spec, so it should work everywhere.

Mind you, you're going to hurt yourself, but it's legal by the spec.

> > Mind you, while GPG can do it, I don't think what you are doing is a
> > good idea: OpenPGP itself uses SHA1 in a number of places.
> I know,.. but in the signatures,.. only the revocation key subpacket
> uses it, right?
> The signatures (even the certification sigs) are made directly on the
> key (and additional data like the UID), right?
> So as far as I understand,.. I should actually gain some security, at
> least from the point that an attacker could no longer concentrate on
> attacking my SHA1 sigs.
> If he want's to do a downgrade attack (recreate an new SHA1 selfsig) he
> would have to attack the signature algorithm itself (e.g. RSA) ... or
> kick me until I gave him my private key ;)

No, if he wants to do a downgrade attack, he can just strip off your
revocation packet and the new selfsig packet and use the old selfsig.
Revoking it doesn't make it vanish.

> > These are
> > not changeable, so even if you purge SHA1 from your key, note that
> > you're still using SHA1.
> btw: When is this going to be changed? i.e. the fingerprint algorithm?

Most likely not until we tackle V5 keys.  Current keys are V4.

> > Also, SHA512 is not widely implemented yet.
> > You can very easily render your key not usable by a large percentage
> > of the population if you pick a hash they don't have.
> Yeah,... I know this,... unfortunately (at least from my point of view)
> gpg and this list, seems to be very conservative it such issues :-/
> (don't want to offend you ;) )

I'm not insulted.  Being conservative with crypto is a compliment.

> > > 3) On an existing key,.. how can I change the key usage flags with gpg?
> > Modify the source.
> Ok, if I modify it,.. and create a 0x1F with key usage, key
> server-prefs, algorithm prefs, and so on... Will gpg understand this?


> Last but not least,.. I've already browsed through the source code...
> could you please point me at the functions where I can put together the
> bits for a (signature) packet (the type of the sig, date, hashed
> subpacktes, and so on),... and the function that creates the actual
> signature (MPI and so on) on this data and the (in case of an 0x1F) on
> the key and UID?

See sign.c:make_keysig_packet(), and the functions that it calls


More information about the Gnupg-users mailing list