security patches

Florian Weimer fw@deneb.enyo.de
Sat Oct 6 22:29:01 2001


Johan Wevers <johanw@vulcan.xs4all.nl> writes:


> As far as I know vulnerability to Klima-Rosa attacks was completely
> solved in GnuPG 1.0.5 and up, but if I'm wrong here please have
> someone correct me.
I don't understand DSA at all, but IIRC somebody suggested a modified attack which is not caught by the signature computation check. [Expiration problems]
> So unlikely to be solved in the near futire anyway. However, I
> consider this more a feature than a problem. This means that if you
> use a key with an expiration date and consider it still safe on that
> date, you can simply increase the expiration date without the hassle
> of getting new signatures.
Yes, there is some disagreement. ;-)
>> Trust import
>> ------------
>> Ordinary key import might introduce trusted keys without user
>> intervention.
>
> Isn't that the whole point of assigning trust values to other people's
> signing anyway?
Oops, I wanted to write: "ultimately trusted keys". Thanks.
>> V3 secret key import
>> --------------------

> So this one not really belongs in this list.
Yes and no, the list covers both security defects and defects related to misleading wording in the OpenPGP specification. (This was not clear from the context, and I should have chosen another headline for the this section, sorry.)
>> Exportable local signatures
>> ---------------------------
>> Signatures on V3 keys marked non-exportable are not properly
>> generated so that they are exportable nevertheless.
>
> Doesn't the whole issue of non-exportable signatures not depend on the
> implementation not exporting them anyway?
V3 signatures on V3 keys can never be non-exportable, and GnuPG used to use them even if the user requested a local signature.
> I.e., is it possible to export such a signature which is correctly
> generated anyway with a hacked version of gpg?
No need to hack GnuPG, you can do this with GNU Emacs. ;-) With the current development version, you can even strip the local flag without invalidating the signature.