Mailing List Archive: GnuPG: devel

[PATCH] Make update_keysig_packet honour cert-digest-algo

Index | Next | Previous | View Threaded

cruicky at cruicky

May 10, 2009, 8:11 AM

Post #1 of 13 (1351 views)
Permalink

[PATCH] Make update_keysig_packet honour cert-digest-algo

Hi there,

Firstly, I should warn you this is the first set of patches I've
submitted for any software ever, so please accept my apologies if
something is out of order. :)

With all the recent SHA-1 related news, I decided to test gpg to ensure
that updated self-signatures used the algorithm specified in
cert-digest-algo. I discovered that gpg takes the digest algorithm from
the previous self-signature. This patch allows this behaviour to be
overridden by using the digest specified by cert-digest-algo. I will be
honest and say that I haven't read the full PGP specification, so this
might be against it so feedback on this would be welcome.

I have included 2 patches, one against 1.4.9 for people still using
1.4.9 who wish to patch, and a patch against the current SVN. Both
patches have been tested to the point that they produce valid signatures
using an RSA key that can be checked with --check-sigs. The patches were
applied to the current source packages of gnupg and gnupg2 in Ubuntu
Intrepid.

I welcome your feedback on these patches.

Regards
J Cruickshanks

P.S. Sorry to the people on the gcrypt-devel list for sending it to the
wrong list first. :)

Attachments:

update_keysig_packet.diff (0.50 KB)

update_keysig_packet_svn.diff (0.61 KB)

dshaw at jabberwocky

May 12, 2009, 6:42 AM

Post #2 of 13 (1285 views)
Permalink

Re: [PATCH] Make update_keysig_packet honour cert-digest-algo [In reply to]

On May 10, 2009, at 11:11 AM, J Cruickshanks wrote:

> Hi there,
>
> Firstly, I should warn you this is the first set of patches I've
> submitted for any software ever, so please accept my apologies if
> something is out of order. :)
>
> With all the recent SHA-1 related news, I decided to test gpg to
> ensure
> that updated self-signatures used the algorithm specified in
> cert-digest-algo. I discovered that gpg takes the digest algorithm
> from
> the previous self-signature. This patch allows this behaviour to be
> overridden by using the digest specified by cert-digest-algo. I will
> be
> honest and say that I haven't read the full PGP specification, so this
> might be against it so feedback on this would be welcome.

I don't think it's against the standard, and I do think the patch does
what you set out to do, but I have a concern whether this is something
we want to do in the code. update_keysig_packet is called for
expiration changes, backsig additions, setting the primary uid,
updating preferences and the preferred keyserver, and adding
notations. All of these items involve manipulating an existing, and
presumably working, signature (i.e. the update cases, hence the
function name).

This patch would mean that when updating these signatures, the
signature hash may also be changed, as a secondary item. So if the
user changes the primary UID flag, they'll get a new cert hash at the
same time. This is fine if someone intended to do that, but less fine
if it happens as an unexpected side-effect of doing something as
simple as setting the primary UID flag.

We still live in a world where a good percentage of the installed code
base cannot understand things like SHA256 (and fewer can understand
SHA512 or 384), so I think this violates the principle of least
surprise - people should not be able to easily render their keys
unusable by some percentage of the population without doing that on
purpose. (It's actually a bit more complex than this if people are
using the keyserver net to distribute their keys, but the basic point
is the same).

So all that said, if the goal is a new self sig, just sign your own
UID like you'd sign any other UID. GPG will recognize that it needs
to make a self-signature, and will properly add the various self-sig
things like preferences and such.

gpg --cert-digest-algo the-new-algo -u mykey --edit-key mykey
delsig (the old sig)
sign (make the new sig)
save

David

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

dkg at fifthhorseman

May 12, 2009, 8:13 AM

Post #3 of 13 (1292 views)
Permalink

Re: [PATCH] Make update_keysig_packet honour cert-digest-algo [In reply to]

On 05/12/2009 09:42 AM, David Shaw wrote:
> This patch would mean that when updating these signatures, the signature
> hash may also be changed, as a secondary item. So if the user changes
> the primary UID flag, they'll get a new cert hash at the same time.
> This is fine if someone intended to do that, but less fine if it happens
> as an unexpected side-effect of doing something as simple as setting the
> primary UID flag.

So what if the update process produced a warning prompt to query if the
user really wants the digest algorithm to change?

If people don't like the idea of adding an additional warning in some
cases, (e.g. it might interrupt automated workflow for some users), why
not instead at least warn that --cert-digest-algo is not being honored?

> We still live in a world where a good percentage of the installed code
> base cannot understand things like SHA256 (and fewer can understand
> SHA512 or 384), so I think this violates the principle of least surprise

I understand what you're saying. However, i also think it violates the
principle of least-surprise to do something that you *know* updates your
self-sig (e.g. setpref) and see gpg not honor the explicitly-specified
--cert-digest-algo).

> So all that said, if the goal is a new self sig, just sign your own UID
> like you'd sign any other UID. GPG will recognize that it needs to make
> a self-signature, and will properly add the various self-sig things like
> preferences and such.
>
> gpg --cert-digest-algo the-new-algo -u mykey --edit-key mykey
> delsig (the old sig)
> sign (make the new sig)
> save

For users with several UIDs where each UID has dozens of signatures, the
delsig step at least is a serious pain in the neck. Why should the user
need to go through such a rigamarole just to be able to publish a
stronger self-sig for those clients capable of consuming it?

Here's an idea that might answer both concerns:

Making a self-signature when cert-digest-algo is set to something other
than SHA1 could generate *two* self-signatures per UID:

* an SHA-1-based self-sig (timestamped X) for consumption by clients
who cannot handle other digests, and

* a self-sig using cert-digest-algo (timestamped X+1) for consumption
by clients who *can* handle the newer digests (and who may wish at some
point to deprecate SHA-1 sigs).

Both self-sigs would contain identical subpackets other than the digest
algo and the timestamp.

The result of this would be that all compliant OpenPGP clients would get
the same information, and clients who prefer stronger digests can get
the additional assurance provided by the --cert-digest-algo. Since
self-sigs are made over data entirely under the control of the
keyholder, there is no risk that the act of making a self-signature over
SHA-1 could be abused by someone exploiting the digest's weakened
collision resistance.

Thoughts?

--dkg

Attachments:

signature.asc (0.87 KB)

cruicky at cruicky

May 12, 2009, 8:23 AM

Post #4 of 13 (1290 views)
Permalink

Re: [PATCH] Make update_keysig_packet honour cert-digest-algo [In reply to]

David Shaw wrote:
> This patch would mean that when updating these signatures, the signature
> hash may also be changed, as a secondary item. So if the user changes
> the primary UID flag, they'll get a new cert hash at the same time.
> This is fine if someone intended to do that, but less fine if it happens
> as an unexpected side-effect of doing something as simple as setting the
> primary UID flag.
>
> We still live in a world where a good percentage of the installed code
> base cannot understand things like SHA256 (and fewer can understand
> SHA512 or 384), so I think this violates the principle of least surprise
> - people should not be able to easily render their keys unusable by some
> percentage of the population without doing that on purpose. (It's
> actually a bit more complex than this if people are using the keyserver
> net to distribute their keys, but the basic point is the same).
>
> So all that said, if the goal is a new self sig, just sign your own UID
> like you'd sign any other UID. GPG will recognize that it needs to make
> a self-signature, and will properly add the various self-sig things like
> preferences and such.
>
> gpg --cert-digest-algo the-new-algo -u mykey --edit-key mykey
> delsig (the old sig)
> sign (make the new sig)
> save

The method you have described appears to work successfully. It does
however have the side effect of wiping away any preferences you already
have set, therefore they need to be set again. I would also assume that
expiry dates and primary UIDs would also have to be set again.

I agree that the user must be fully aware of what they are doing when
making a change like this as it is pretty aggressive. Perhaps an
alternative to the above method could be the addition of a new option
called something along the lines of '--force-cert-digest-algo'. This
would be used in addition to '--cert-digest-algo' for updating self
signatures when changing preferences, expiry dates, etc. along with
changing the digest algorithm for the first time the user wishes to use
a new digest algorithm. We can then be reasonably sure the user intended
for the digest function to be changed. This option would then of course
be accompanied by a warning much like for the '--cert-digest-algo'
option in the man page.

As I mentioned above, this option would probably only be used once or
twice depending on the future of cryptography, so we could stick with
the method you have provided for updating the digest. The only worry I
have with that approach is the potential for the user to forget to
reapply their preferences, expiry dates, etc. or getting caught out by
other side effects that I didn't witness in my quick test. I guess it
depends on how much usage this option will get as to whether to warrant
its inclusion, but it would make the process much easier for users who
do wish to change digest algorithms.

If you believe that this approach would be better, I will be quite
willing to write a patch for the option.

Regards
J Cruickshanks

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

dshaw at jabberwocky

May 12, 2009, 8:45 AM

Post #5 of 13 (1290 views)
Permalink

Re: [PATCH] Make update_keysig_packet honour cert-digest-algo [In reply to]

On May 12, 2009, at 11:13 AM, Daniel Kahn Gillmor wrote:

> On 05/12/2009 09:42 AM, David Shaw wrote:
>> This patch would mean that when updating these signatures, the
>> signature
>> hash may also be changed, as a secondary item. So if the user
>> changes
>> the primary UID flag, they'll get a new cert hash at the same time.
>> This is fine if someone intended to do that, but less fine if it
>> happens
>> as an unexpected side-effect of doing something as simple as
>> setting the
>> primary UID flag.
>
> So what if the update process produced a warning prompt to query if
> the
> user really wants the digest algorithm to change?
>
> If people don't like the idea of adding an additional warning in some
> cases, (e.g. it might interrupt automated workflow for some users),
> why
> not instead at least warn that --cert-digest-algo is not being
> honored?
>
>> We still live in a world where a good percentage of the installed
>> code
>> base cannot understand things like SHA256 (and fewer can understand
>> SHA512 or 384), so I think this violates the principle of least
>> surprise
>
> I understand what you're saying. However, i also think it violates
> the
> principle of least-surprise to do something that you *know* updates
> your
> self-sig (e.g. setpref) and see gpg not honor the explicitly-specified
> --cert-digest-algo).

You know that. I'd be shocked to my core to find out that more than
5-10% of randomly chosen OpenPGP users have any understanding at all
that preferences are stored on the self-sig, that a valid self-sig is
required to have a usable key, and that remaking the self-sig using a
hash that doesn't exist on the recipient side will cause that
recipient to not be able to use the key at all.

>> So all that said, if the goal is a new self sig, just sign your own
>> UID
>> like you'd sign any other UID. GPG will recognize that it needs to
>> make
>> a self-signature, and will properly add the various self-sig things
>> like
>> preferences and such.
>>
>> gpg --cert-digest-algo the-new-algo -u mykey --edit-key mykey
>> delsig (the old sig)
>> sign (make the new sig)
>> save
>
> For users with several UIDs where each UID has dozens of signatures,
> the
> delsig step at least is a serious pain in the neck. Why should the
> user
> need to go through such a rigamarole just to be able to publish a
> stronger self-sig for those clients capable of consuming it?

Because there are vastly more users who don't want to do this.

> Here's an idea that might answer both concerns:
>
> Making a self-signature when cert-digest-algo is set to something
> other
> than SHA1 could generate *two* self-signatures per UID:
>
> * an SHA-1-based self-sig (timestamped X) for consumption by clients
> who cannot handle other digests, and
>
> * a self-sig using cert-digest-algo (timestamped X+1) for consumption
> by clients who *can* handle the newer digests (and who may wish at
> some
> point to deprecate SHA-1 sigs).
>
> Both self-sigs would contain identical subpackets other than the
> digest
> algo and the timestamp.

It's always possible to come up with a complex solution, but then that
complexity may have other side effects down the road, and will also
have to be maintained as a feature in GPG for the indefinite future.

> Since
> self-sigs are made over data entirely under the control of the
> keyholder, there is no risk that the act of making a self-signature
> over
> SHA-1 could be abused by someone exploiting the digest's weakened
> collision resistance.

So then why is any of this necessary?

David

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

dshaw at jabberwocky

May 12, 2009, 8:52 AM

Post #6 of 13 (1295 views)
Permalink

Re: [PATCH] Make update_keysig_packet honour cert-digest-algo [In reply to]

On May 12, 2009, at 11:23 AM, J Cruickshanks wrote:

>> gpg --cert-digest-algo the-new-algo -u mykey --edit-key mykey
>> delsig (the old sig)
>> sign (make the new sig)
>> save
>
> The method you have described appears to work successfully. It does
> however have the side effect of wiping away any preferences you
> already
> have set, therefore they need to be set again. I would also assume
> that
> expiry dates and primary UIDs would also have to be set again.

That is correct, yes.

> As I mentioned above, this option would probably only be used once or
> twice depending on the future of cryptography, so we could stick with
> the method you have provided for updating the digest. The only worry I
> have with that approach is the potential for the user to forget to
> reapply their preferences, expiry dates, etc. or getting caught out by
> other side effects that I didn't witness in my quick test. I guess it
> depends on how much usage this option will get as to whether to
> warrant
> its inclusion, but it would make the process much easier for users who
> do wish to change digest algorithms.

This is exactly my concern - we can put in all sorts of options, but
every option costs something to maintain it over the life of the code,
and costs something to document, and costs something to explain it to
people, and increases the complexity of the system.

If hashes were falling like flies and people were having to update
their keys frequently, I'd probably feel differently about this, but
the SHA-1 problem (which I must mention still hasn't even happened) is
the very first time this situation has come up in OpenPGP. (MD5 was
already deprecated by the time it was broken, and was never the
default signing hash in any OpenPGP application).

David

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

dkg at fifthhorseman

May 12, 2009, 9:51 AM

Post #7 of 13 (1293 views)
Permalink

Re: [PATCH] Make update_keysig_packet honour cert-digest-algo [In reply to]

On 05/12/2009 11:45 AM, David Shaw wrote:
> On May 12, 2009, at 11:13 AM, Daniel Kahn Gillmor wrote:
>> Since
>> self-sigs are made over data entirely under the control of the
>> keyholder, there is no risk that the act of making a self-signature over
>> SHA-1 could be abused by someone exploiting the digest's weakened
>> collision resistance.
>
> So then why is any of this necessary?

Because while *making* self-sigs doesn't make the keyholder more
vulnerable to a digest compromise, *trusting* self-sigs leaves the
interpreter vulnerable to a digest compromise. See my followup
yesterday on ietf-openpgp:

http://www.imc.org/ietf-openpgp/mail-archive/msg33452.html

So anyone checking signatures for validity has a good reason to ignore
signatures (self-sigs or otherwise) made over untrustworthy digests.

Since this is the case, people who want their certifications to be
deemed valid by everyone have an incentive to make those certifications
over digests that are not known to be compromised.

At the moment, you're saying there is a non-zero installed base of
clients that do not support signatures made over SHA-256.

In the future, there may be a non-zero base of clients who prefer to
disbelieve (blacklist) signatures made over SHA-1.

If gpg wants its generated self-signatures to be acceptable to members
of both of these sets, it must issue two signatures (one over each
digest). You cannot issue two self-sigs like this in gpg right now
without the --expert option, which indicates that it's probably the
wrong way to do things.

If a gpg user wants to ignore either set of clients, the obvious way to
do that is by setting cert-digest-algo. But that doesn't currently
behave as expected, as J Cruickshanks pointed out.

--dkg

Attachments:

signature.asc (0.87 KB)

dshaw at jabberwocky

May 12, 2009, 10:27 AM

Post #8 of 13 (1285 views)
Permalink

Re: [PATCH] Make update_keysig_packet honour cert-digest-algo [In reply to]

On May 12, 2009, at 12:51 PM, Daniel Kahn Gillmor wrote:

> If gpg wants its generated self-signatures to be acceptable to members
> of both of these sets, it must issue two signatures (one over each
> digest). You cannot issue two self-sigs like this in gpg right now
> without the --expert option, which indicates that it's probably the
> wrong way to do things.

I do understand what you are asking for. I just disagree that it is
warranted for SHA-1 at this time. This is not a perfect world where
as soon as there was a question even asked about an algorithm, we
could just shove it aside and use something else. This is a very
messy world where the vast majority of users don't upgrade, don't use
the latest algorithms, and don't even understand the problem.

There are tools within GPG to accomplish what you want to do today.
It may not be as neat as a new feature, but you, nor anyone else who
feels the need to do this, are not being blocked for lack of this
feature.

Again, if we were in the position of changing digest hashes more often
than once a decade, I might feel differently about some spiffy new
feature to automate it, but this is the first time it's been necessary
since 1997.

David

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

dkg at fifthhorseman

May 12, 2009, 1:05 PM

Post #9 of 13 (1286 views)
Permalink

Re: [PATCH] Make update_keysig_packet honour cert-digest-algo [In reply to]

On 05/12/2009 01:27 PM, David Shaw wrote:
> This is not a perfect world where as
> soon as there was a question even asked about an algorithm, we could
> just shove it aside and use something else. This is a very messy world
> where the vast majority of users don't upgrade, don't use the latest
> algorithms, and don't even understand the problem.

Agreed, and i'm *not* suggesting that we should cast SHA-1 aside right
now. The fact that the majority of users don't understand the problem
and take a long time to upgrade is an indication that we need tools to
do the Right Thing proactively, well before the "weaponized" attacks are
created. The tools we release this year will likely still be in use 5
years from now, in a different cryptographic landscape, on behalf of
those same users who don't understand the issues.

I can think of two situations where the set of users who decline to rely
on SHA-1-based signatures will be a significantly larger than the empty set:

* When an "weaponized" attack against SHA-1's collision-resistance does
come out, or

* When a large organization decides that SHA-1 is no longer
trustworthy, and mandates that signatures based on it be disregarded
(for example, the US Federal Gov't will do this at the end of 2010).

When either event happens, the current WoT will suffer. For example,
all the published sigs (self-sigs and those made by others) on
0x99242560 are made with either MD5 or SHA1. Even if all of your
correspondents were to re-issue their certifications over stronger
digests, your key would not be considered valid by someone choosing to
deprecate SHA-1 because your self-sigs are made over the compromised
algorithm.

So, before either of these two events happen, we need a couple things to
already be comfortably in place:

A) we'll need tools that are capable of simply deprecating signatures
made over SHA-1 (see the earlier discussion about blacklist-digest-algo)

B) we'll need a WoT with sufficient post-SHA1 certifications to provide
useful connectivity.

As the widest-used free implementation of OpenPGP, gnupg is in a unique
position to make sure that both of these things happen.

My proposal adds no new UI features to gpg, and is a simple rule:

* if cert-digest-algo is not SHA-1, gnupg generates all self-signatures
twice, over SHA-1 and cert-digest-algo

If blacklist-digest-algo was currently implemented, we could consider
expanding this rule to:

* if cert-digest-algo is not SHA-1, and SHA-1 is not blacklisted, gnupg
generates all certifications (self-sigs and otherwise) twice, over SHA-1
and cert-digest-algo.

If we make this change now, then users stuck on, say, debian oldstable 3
years from now (about the time SHA-3 will be finalized, if i'm reading
the timetable correctly, and well after the US Gov't has started
ignoring SHA-1 signatures) have a chance at being able to interact with
the OpenPGP WoT where a significant set of their correspondents have
deprecated SHA-1-based signatures.

Since gpg would make SHA-1 self-sigs as well under this scenario, it
would not cause users today to cut themselves off from current
populations of users with minimal implementations which can only handle
SHA-1.

> There are tools within GPG to accomplish what you want to do today. It
> may not be as neat as a new feature, but you, nor anyone else who feels
> the need to do this, are not being blocked for lack of this feature.

I've already done it, but it was confusing and more complicated than it
needed to be, even for someone who is heavily invested in understanding
the detailed issues here.

I'm concerned about the majority of users who, as you say, don't even
understand the problem. gnupg can make things work securely for them,
and help to maintain the global WoT without requiring each user to jump
through the same hoops i did.

> Again, if we were in the position of changing digest hashes more often
> than once a decade, I might feel differently about some spiffy new
> feature to automate it, but this is the first time it's been necessary
> since 1997.

So how do you suggest we prepare for this transition?

--dkg

Attachments:

signature.asc (0.87 KB)

dshaw at jabberwocky

May 12, 2009, 8:04 PM

Post #10 of 13 (1287 views)
Permalink

Re: [PATCH] Make update_keysig_packet honour cert-digest-algo [In reply to]

On May 12, 2009, at 4:05 PM, Daniel Kahn Gillmor wrote:
> So how do you suggest we prepare for this transition?

By not assuming things. We don't know the details. What we don't
know is much greater than what we do know.

Do you know what doubling signatures with do for the various currently
deployed OpenPGP clients out there? Will they all do the right
thing? How many will break? It's not enough to test against yourself
here - from your blog posting, I understand you are communicating
mainly with Debian developers, virtually all of which are running a
somewhat recent version of GPG.

And all this before the paper describing the attack is even
published! Do we know the details of the attack? No. Do we know if
the attack works against SHA-2? It might - both SHA-1 and the SHA-2
family share the same basic construction. Does the extra size of
SHA-2 give enough buffer to avoid the attack? Probably, but we don't
know yet. Are we safe until SHA-3 is ready? Maybe, maybe not. We've
only seen a few powerpoint slides.

Have you ever heard the old trope "Something must be done. This is
something. Therefore, this must be done" ? This is a bit like that.
Coming up with a defense against what we *think* the attack is is a
dicey business, especially when we can wait just a little while for
the paper to be published and then we can come up with a defense
against what we *know* the attack is. No matter what the attack turns
out to be, I feel confident in saying that we are at least safe until
the paper appears.

David

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

wk at gnupg

May 13, 2009, 5:53 AM

Post #11 of 13 (1276 views)
Permalink

Re: [PATCH] Make update_keysig_packet honour cert-digest-algo [In reply to]

On Tue, 12 May 2009 22:05, dkg [at] fifthhorseman said:

> do the Right Thing proactively, well before the "weaponized" attacks are
> created. The tools we release this year will likely still be in use 5
> years from now, in a different cryptographic landscape, on behalf of
> those same users who don't understand the issues.

We should get things back to reality.

First of all there is no attack on SHA-1. Maybe it will be possible to
mount a collision attack in a couple of years. Maybe it will then be
possible to attack the web of trust or do any other collision based
evil. These are and will be targeted attacks on certain
infrastructures. Folks responsible for these infrastructures need to
care about it and put possible collision attacks on their list of
attack scenarios.

This is nothing the average user needs to care about. We don't need to
prioritize pro-active changes of active keys either. If real harm will
be possible everyone who cares about security just creates a vanilla new
key and is done. A key replacement strategy needs to be in place
anyway. Those who don't like that should have the knowledge how to
modify their own keys.

Things to keep in mind:

- The web-of-trust is an ad-doc structure and its security margin is
for sure far far less then 2^52. Attacking the WoT is far easier
than mounting an collision attack on SHA-1. Even without doing
rubber hose cryptanalysis.

- There are tools implementing the security (e.g. gpg). Assuming that
these tools are bug free or at least that these bugs are harder to
find and exploit than to mount a real world SHA-1 collision attack,
is plainly wrong. Those who believe that should do a reality check.

- There are other application on the box running the tools: Are they
secure enough? I doubt that.

- There is an operating system involved. Is it really secure enough?
I doubt that too.

- I guess that at least 99 percent of all users are not able to keep
their environment hardened against simple attacks.

Why should we then harden the existing keys automagically and risking
interoperability problems which will in turn lead to decreased security.

Again: Those who rely on nearly perfect security know about the problems
and can develop ways to mitigate that.

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

micah at riseup

May 14, 2009, 7:35 AM

Post #12 of 13 (1285 views)
Permalink

Re: [PATCH] Make update_keysig_packet honour cert-digest-algo [In reply to]

Werner Koch <wk [at] gnupg> writes:

> On Tue, 12 May 2009 22:05, dkg [at] fifthhorseman said:
>
>> do the Right Thing proactively, well before the "weaponized" attacks are
>> created. The tools we release this year will likely still be in use 5
>> years from now, in a different cryptographic landscape, on behalf of
>> those same users who don't understand the issues.
>
> We should get things back to reality.
>
> First of all there is no attack on SHA-1. Maybe it will be possible to
> mount a collision attack in a couple of years. Maybe it will then be
> possible to attack the web of trust or do any other collision based
> evil.

I appreciate you bringing us back to reality(tm), grounding this
discussion is helpful. However, the first sentence of what you said was
grounded in reality, but then you immediately stepped into
speculation. You are right that 'maybe it will be possible to mount a
collision attack in a couple of years', but I would be just as right to
say that 'maybe it will be possible to mount a collision attack in a
couple of weeks'.... we do not really know where this will fall. I think
the 'reality' is that we can all agree that a collision attack on SHA-1
will come, *at some point*. It might be in 4 years, or it might be in 2,
or someone might be working on polishing their powerpoint slides right
now.

The reality here is the following: the reduction in keyspace travel
could point to a trend similar to what happened with MD-5 (ie. further
reductions are to be expected). Based on this, we can expect that some
point SHA-1 will have a collision attack that is relatively trivial. At
the moment, we have a strong indication that collisions with SHA-1 are
within the reach of Well Funded Organizations, but we do not have the
actual published paper yet.

> This is nothing the average user needs to care about. We don't need
> to prioritize pro-active changes of active keys either.

Ok, if this is nothing that the average user needs to care about, then
what does the gnupg development need to think about? I don't want to
claim that interoperability is not important, but I do think that gnupg,
as the flagship free OpenPGP implementation, should take the responsible
lead and push the Web of Trust to do the right thing. GnuPG already
drives the WOT, and has the ability to nudge it in positive and
coherent directions, or not.

We all recognize the reality that key transitions take a long time, a
really long time. Anyone who has done it understands this very well. We
know, without any conjecture, that there is no demonstrated problem
right now (if you ignore the fact that collisions in the key space are
now within the reach of Well Funded Organizations, which I personally do
not think is something that should be ignored in a cavalier
manner). Because there is no problem right now, we have the space to
work on this problem, without a hasty rush that could lead to
problems.

Lets think a couple of steps ahead, be slightly cautious, and come out
the other end as having the foresight to deal with this problem
gracefully before it hit us. Lets actually plan for the future, instead
of deferring that planning.

> - The web-of-trust is an ad-doc structure and its security margin is
> for sure far far less then 2^52. Attacking the WoT is far easier
> than mounting an collision attack on SHA-1. Even without doing
> rubber hose cryptanalysis.
>
> - There are tools implementing the security (e.g. gpg). Assuming that
> these tools are bug free or at least that these bugs are harder to
> find and exploit than to mount a real world SHA-1 collision attack,
> is plainly wrong. Those who believe that should do a reality check.
>
> - There are other application on the box running the tools: Are they
> secure enough? I doubt that.
>
> - There is an operating system involved. Is it really secure enough?
> I doubt that too.
>
> - I guess that at least 99 percent of all users are not able to keep
> their environment hardened against simple attacks.

There are always going to be other weaknesses, but thats not an excuse
for gnupg to not try to be better. All of these things need to be
improved, but doing so is not the role of gnupg. This list is for gnupg
development, not a list about Windows security, or whatever. Each one of
these pieces does need work, I'm not going to dispute that, but that
work should not lull gnupg into inaction. Gnupg has its role to play and
it should take that role and run with it, blazing the crypto trail.

> Why should we then harden the existing keys automagically and risking
> interoperability problems which will in turn lead to decreased security.

I may be an outlier here, but those 5-year old programs that will have
interoperability problems are going to have other issues that
significantly reduce their security. We should not let old software that
has *worse* security holes hold us back. We *can* lead and people *will*
upgrade.

At some point Firefox was also faced with this decision: should they
push for a better web, knowing that they will cause the older browsers
to have interoperability problems with modern websites? The answer was
yes. We dont need a world filled with IE3 and Netscape Navigator any
more, anymore than we need encryption tools that provide a false sense
of security.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

wk at gnupg

May 17, 2009, 11:04 PM

Post #13 of 13 (1252 views)
Permalink

Re: [PATCH] Make update_keysig_packet honour cert-digest-algo [In reply to]

On Thu, 14 May 2009 16:35, micah [at] riseup said:

> discussion is helpful. However, the first sentence of what you said was
> grounded in reality, but then you immediately stepped into
> speculation. You are right that 'maybe it will be possible to mount a

Predicting the future is always speculation. My point is that from an
attackers point of view there are far easier attack vectors than the use
of any kind of modern cryptanalysis. We need to keep this in mind when
talking about the *immediate* need to change algorithms.

> The reality here is the following: the reduction in keyspace travel
> could point to a trend similar to what happened with MD-5 (ie. further

By the time we started the OpenPGP WG in fall 1997 it was already known
that MD5 had severe weaknesses. Thus PGP5 and thus OpenPGP used the
best hash algorithm available at that time: SHA-1. We knew that it
would not last forever and that SHA-1 doesn't match the strength of the
other algorithms; we eagerly waited for the SHA-2 series of algorithms
to get released by the NSA. It is 6 years since we implemented them and
only now we can be somewhat sure that they are widely available. Thus
we are now discussing how to make use of them.

Deploying a new algorithm takes time, a lot of time. Peter Gutmann has
a paper on this topic. We, the OpenPGP community, are quite good in
deploying new algorithms - way faster than other groups.

> what does the gnupg development need to think about? I don't want to
> claim that interoperability is not important, but I do think that gnupg,
> as the flagship free OpenPGP implementation, should take the responsible
> lead and push the Web of Trust to do the right thing. GnuPG already

We are doing exactly this. Deploying a code base which allows to use
newer algorithms without to much hassles. This all started 6 years ago
with SHA-2, now continues by changing the default algorithms for new
keys and will eventually deprecate the default use of SHA-1 and
DSA-1024.

> right now (if you ignore the fact that collisions in the key space are
> now within the reach of Well Funded Organizations, which I personally do
> not think is something that should be ignored in a cavalier
> manner). Because there is no problem right now, we have the space to

GnuPG has all features to use stronger algorithms; what we are
discussing are the default algorithms for users who are not security
experts and need something which just works and is secure enough for
their use cases.

> gracefully before it hit us. Lets actually plan for the future, instead
> of deferring that planning.

As said we are doing exactly this. We need to take some care because we
don't want to fall into the X.509/CMS trap where it took more than a
decade that the major applications achieved a little interoperability - on
the least common denominator.

> There are always going to be other weaknesses, but thats not an excuse
> for gnupg to not try to be better. All of these things need to be

Right, I listed them to show that it is much harder to deploy secure
systems than just replacing an algorithm.

> improved, but doing so is not the role of gnupg. This list is for gnupg
> development, not a list about Windows security, or whatever. Each one of

It is not about Windows. Windows is not worse than other major OSes.
Code quality is a major problem and unfortunately one which can't be
solved as "easily" as creating a more secure algorithm.

> I may be an outlier here, but those 5-year old programs that will have
> interoperability problems are going to have other issues that
> significantly reduce their security. We should not let old software that

Maybe, we don't know. GNU/Linux distributions usually keep on fixing
security bugs even for very old software. GnuPG 1.2 reached end of
life a bit more that 4 years ago but it is still widely enough in use.
We even did a security update on our own 2 years after end of life.

Those who really need state of the art security will use a more recent
version. The default key sizes are not a problem for them and they can
cope with possible interop problems.

> At some point Firefox was also faced with this decision: should they
> push for a better web, knowing that they will cause the older browsers

<ot> Supporting EV certificates for a better web? I beg to differ; they
are merely shoveling more coal into the the big certificate vending
machine. </>.

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads