Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Josh Triplett]

On Fri, Aug 12, 2016 at 12:32:34PM +0100, Ian Jackson wrote:
> Josh Triplett writes ("Re: use long keyid-format in gpg.conf (Re: Key 
> collisions in the wild"):
> > I'd suggest moving directly to full fingerprints; from elsewhere in this
> > thread, it sounds like the current version of gnupg has done so.
> 
> What should we do for users of jessie ?

Backport the fingerprints-only patch for the gnupg2 package, and ideally
develop a patch for jessie's gnupg 1 package that has the same effect.
If developing that patch seems non-trivial to do quickly and cleanly,
then I'd suggest backporting the 64-bit-only change to jessie's gnupg 1
package as a stopgap, but not a permanent solution.

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Henrique de Moraes Holschuh]

On Fri, 12 Aug 2016, Ian Jackson wrote:
> Josh Triplett writes ("Re: use long keyid-format in gpg.conf (Re: Key 
> collisions in the wild"):
> > I'd suggest moving directly to full fingerprints; from elsewhere in this
> > thread, it sounds like the current version of gnupg has done so.
> 
> What should we do for users of jessie ?

IMO, backport the changes.

I personally won't really care whether the new format is enabled or disabled by
default, as long as a NEWS.Debian and a security announcement are worded
clearly enough to get the word out that it should be enabled everywhere
it won't cause breakages.

-- 
  Henrique Holschuh

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Ian Jackson]

Josh Triplett writes ("Re: use long keyid-format in gpg.conf (Re: Key 
collisions in the wild"):
> I'd suggest moving directly to full fingerprints; from elsewhere in this
> thread, it sounds like the current version of gnupg has done so.

What should we do for users of jessie ?

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Josh Triplett]

Samuel Thibault wrote:
> And actually, moving to 64bit fingerprints by default is possibly not a
> good idea: who knows when 64bit will not be secure any more? Estimating
> very roughly, if a 32bit collision can be found within a few seconds
> with one GPU now as evil32 seems to show, a supercomputer with 1
> GPUs can find a 64bit collision within a month...

Worse than that.  Consider that, given a financial incentive, people
developed FPGAs and then dedicated ASICs to perform double-sha256
incredibly quickly, in order to perform proof-of-work calculations that
consisted of seeking a hash with a given number of bits specified.
Doing the same for key fingerprints seems similarly plausible.

If you could check for key fingerprint collisions as fast as the hash
rate of current ASIC miners (order of magnitude 14 terahash/s), it'd
take ~15 days to find a 64-bit collision with just one such ASIC, and
the problem trivially parallelizes across multiple.  An adversary with a
modest number of such ASICs could produce 64-bit collisions for the
entire strong set in days (producing an "evil64" set).

I'd suggest moving directly to full fingerprints; from elsewhere in this
thread, it sounds like the current version of gnupg has done so.

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Gunnar Wolf]

Gunnar Wolf dijo [Wed, Aug 10, 2016 at 02:08:12PM -0500]:
> That's the reason why a key by itself means little, but we do place
> value on the web of trust around it.
> (...blah...)

Anyway, I managed to twist my mail with many facts and make it into a
long mess :) That was my main point. Nobody should trust my key to be
"just" even AB41C1C68AFD668CA045EBF8673A03E4C1DB921F — It's not yet
feasible to willingly create a collision, but by mere chance, somebody
might just find it on their next key generation. My identity should be
trusted based on this long number plus the web of trust around
it.

It is highly unlikely somebody will find a collision with my
fingerprint by itself, but it's mindboggingly stupidly utterly
bloody unlikely some will find two, three other (even 64-bit)
collisions to sign my fake with. And I have over a hundred ;-)


signature.asc
Description: Digital signature

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Gunnar Wolf]

Samuel Thibault dijo [Wed, Aug 10, 2016 at 02:03:33PM +0200]:
> And actually, moving to 64bit fingerprints by default is possibly not a
> good idea: who knows when 64bit will not be secure any more? Estimating
> very roughly, if a 32bit collision can be found within a few seconds
> with one GPU now as evil32 seems to show, a supercomputer with 1
> GPUs can find a 64bit collision within a month...
> 
> Really, only signature paths should be looked at by people, and it seems
> like we are tending to let people think 64bit fingerprints are "secure".

That's the reason why a key by itself means little, but we do place
value on the web of trust around it. If a given 64-bit keyid takes a
month to generate¹, and the uploading developers keyring is somewhere
around the 820 keys (from which around 700 make up the strong set), it
would still take ~60 years to generate our full strong set of evil
twins. This is not trivial time.

Of course, Evil32 started aided with the power of numbers — It's not
that they search to make a evil-twin of every 32-bit keyid, but that
they generate keys as fast as they can, and just discard any key not
matching an existing keyid. The keyserver network currently carries
over 4.3 million keys, so roughly one every thousand generated keys
will match *something*¹. Of course, Evil32 is interested in the
keyservers' strong set, which I guess will be way smaller (but have no
numbers to back my hopes).

I believe we are safe to use 64-bit keys *for the time being*. Of
course, nobody will imply that it's as safe to use 64-bit as
160-bit. We should end accepting that human-usable keyids are not
worth their salt and move to full-fingerprint. But there are many
things to fix before that... Among them (and I might be mistaken here)
the PGP key format itself, as AFAICT signatures are stored based on
their long keyid (and not on full hashes)!

--

¹ Yes, the keyserver network carries several already collided keys —
  Such as the ones that prompted this thread!

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Samuel Thibault]

Ian Jackson, on Wed 10 Aug 2016 19:06:28 +0100, wrote:
> Samuel Thibault writes ("Re: use long keyid-format in gpg.conf (Re: Key 
> collisions in the wild"):
> > Ian Jackson, on Wed 10 Aug 2016 18:56:52 +0100, wrote:
> > > Did you miss that paragraph the first two times (in which case I guess
> > > me repeating it was useful) ?
> > 
> > I missed it, yes, sorry.
> 
> Thanks.  I feel less frustrated now.  I hope you don't feel shouted
> at...

No problem :)

Samuel

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Ian Jackson]

Samuel Thibault writes ("Re: use long keyid-format in gpg.conf (Re: Key 
collisions in the wild"):
> Ian Jackson, on Wed 10 Aug 2016 18:56:52 +0100, wrote:
> > Did you miss that paragraph the first two times (in which case I guess
> > me repeating it was useful) ?
> 
> I missed it, yes, sorry.

Thanks.  I feel less frustrated now.  I hope you don't feel shouted
at...

Regards,
Ian.


-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Samuel Thibault]

Ian Jackson, on Wed 10 Aug 2016 18:56:52 +0100, wrote:
> Samuel Thibault writes ("Re: use long keyid-format in gpg.conf (Re: Key 
> collisions in the wild"):
> > Ian Jackson, on Wed 10 Aug 2016 13:45:05 +0100, wrote:
> > > I don't know what side of this (one) line such a proposed gpg change
> > > falls.  I still think it's unsatisfactory that our stable release has
> > > a default behaviour which cannot be used safely.
> > 
> > Well, I'd argue that 64bit IDs are not safe either, they have not been
> > made to be.
> 
> This is precisely the kind of point I was thinking of when I wrote:
> 
>   Even if long keyids are not sufficient, they are a big improvement and
>   we should not let fixing this problem properly stand in the way of
>   doing what we can, now.
> 
> This is now the second time I have cut and pasted that into this
> thread.  I feel frustrated.
> 
> Did you miss that paragraph the first two times (in which case I guess
> me repeating it was useful) ?

I missed it, yes, sorry.

Samuel

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Ian Jackson]

Samuel Thibault writes ("Re: use long keyid-format in gpg.conf (Re: Key 
collisions in the wild"):
> Ian Jackson, on Wed 10 Aug 2016 13:45:05 +0100, wrote:
> > I don't know what side of this (one) line such a proposed gpg change
> > falls.  I still think it's unsatisfactory that our stable release has
> > a default behaviour which cannot be used safely.
> 
> Well, I'd argue that 64bit IDs are not safe either, they have not been
> made to be.

This is precisely the kind of point I was thinking of when I wrote:

  Even if long keyids are not sufficient, they are a big improvement and
  we should not let fixing this problem properly stand in the way of
  doing what we can, now.

This is now the second time I have cut and pasted that into this
thread.  I feel frustrated.

Did you miss that paragraph the first two times (in which case I guess
me repeating it was useful) ?  Or did you disagree with me ?  If you
disagreed, it would be helpful if you explained why, and what you
think we should do for users of jessie.

Thanks,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Carlos Alberto Lopez Perez]

On 10/08/16 15:19, Samuel Thibault wrote:
> Ian Jackson, on Wed 10 Aug 2016 13:45:05 +0100, wrote:
>> Adam D. Barratt writes ("Re: use long keyid-format in gpg.conf (Re: Key 
>> collisions in the wild"):
>>> [explanation]
>>
>> Thanks.
>>
>> I don't know what side of this (one) line such a proposed gpg change
>> falls.  I still think it's unsatisfactory that our stable release has
>> a default behaviour which cannot be used safely.
> 
> Well, I'd argue that 64bit IDs are not safe either, they have not been
> made to be.
> 
> Samuel
> 
> 

Upstream has introduced -keyid-format=none which shows the full fingerprint,
and then made it the default.

Issue: [default to --with-fingerprint, introduce --without-fingerprint]
https://bugs.gnupg.org/gnupg/issue2379

Commit: [gpg: Implement --keyid-format=none.]
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=b047388

Commit: [gpg: Use --keyid-format=none by default.]
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=7257ea2


This seems much safer than 64bit IDs.


Maybe a backport of this is feasible?




signature.asc
Description: OpenPGP digital signature

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Christian Seiler]

On 08/10/2016 03:44 PM, Samuel Thibault wrote:
> Christian Seiler, on Wed 10 Aug 2016 15:37:43 +0200, wrote:
>> On 08/10/2016 03:19 PM, Samuel Thibault wrote:
>>> Ian Jackson, on Wed 10 Aug 2016 13:45:05 +0100, wrote:
>>>> Adam D. Barratt writes ("Re: use long keyid-format in gpg.conf (Re: Key 
>>>> collisions in the wild"):
>>>>> [explanation]
>>>>
>>>> Thanks.
>>>>
>>>> I don't know what side of this (one) line such a proposed gpg change
>>>> falls.  I still think it's unsatisfactory that our stable release has
>>>> a default behaviour which cannot be used safely.
>>>
>>> Well, I'd argue that 64bit IDs are not safe either, they have not been
>>> made to be.
>>
>> Can we even consider key fingerprints safe in the long run?
> 
> Well, I'd say that in the end people *have* to cryptographically check
> the signatures, and not trust fingerprints.

Every key signing I've done so far has relied on verifying that the
fingerprint matches in some way or another.

> Thinking about it, I'd say we could even instead *shorten* the default
> ID to 16bit, so that people will hopefully simply just not trust them at
> all. For practical uses, 16bit hashing is enough to manage one's public
> keyring.

>From my experience with how UX works in practice, I think this will
not work at all and be rather counter-productive. I think Ian's
proposal to use 64bit for now as a stop-gap measure is actually
the best short-term solution to increase security.

Regards,
Christian

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Samuel Thibault]

Christian Seiler, on Wed 10 Aug 2016 15:37:43 +0200, wrote:
> On 08/10/2016 03:19 PM, Samuel Thibault wrote:
> > Ian Jackson, on Wed 10 Aug 2016 13:45:05 +0100, wrote:
> >> Adam D. Barratt writes ("Re: use long keyid-format in gpg.conf (Re: Key 
> >> collisions in the wild"):
> >>> [explanation]
> >>
> >> Thanks.
> >>
> >> I don't know what side of this (one) line such a proposed gpg change
> >> falls.  I still think it's unsatisfactory that our stable release has
> >> a default behaviour which cannot be used safely.
> > 
> > Well, I'd argue that 64bit IDs are not safe either, they have not been
> > made to be.
> 
> Can we even consider key fingerprints safe in the long run?

Well, I'd say that in the end people *have* to cryptographically check
the signatures, and not trust fingerprints.

Thinking about it, I'd say we could even instead *shorten* the default
ID to 16bit, so that people will hopefully simply just not trust them at
all. For practical uses, 16bit hashing is enough to manage one's public
keyring.

Samuel

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Ian Jackson]

Christian Seiler writes ("Re: use long keyid-format in gpg.conf (Re: Key 
collisions in the wild"):
> On 08/10/2016 03:19 PM, Samuel Thibault wrote:
> > Well, I'd argue that 64bit IDs are not safe either, they have not been
> > made to be.
> 
> Can we even consider key fingerprints safe in the long run? AIUI they
> are SHA1 hashes of the public key, and while there isn't a feasible
> preimage attack on SHA1 _yet_ (and we shouldn't panic), there's a
> reason why SHA1 is discouraged by experts.

This is precisely the kind of point I was thinking of when I wrote:

  Even if long keyids are not sufficient, they are a big improvement and
  we should not let fixing this problem properly stand in the way of
  doing what we can, now.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Christian Seiler]

On 08/10/2016 03:19 PM, Samuel Thibault wrote:
> Ian Jackson, on Wed 10 Aug 2016 13:45:05 +0100, wrote:
>> Adam D. Barratt writes ("Re: use long keyid-format in gpg.conf (Re: Key 
>> collisions in the wild"):
>>> [explanation]
>>
>> Thanks.
>>
>> I don't know what side of this (one) line such a proposed gpg change
>> falls.  I still think it's unsatisfactory that our stable release has
>> a default behaviour which cannot be used safely.
> 
> Well, I'd argue that 64bit IDs are not safe either, they have not been
> made to be.

Can we even consider key fingerprints safe in the long run? AIUI they
are SHA1 hashes of the public key, and while there isn't a feasible
preimage attack on SHA1 _yet_ (and we shouldn't panic), there's a
reason why SHA1 is discouraged by experts.

Regards,
Christian

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Samuel Thibault]

Ian Jackson, on Wed 10 Aug 2016 13:45:05 +0100, wrote:
> Adam D. Barratt writes ("Re: use long keyid-format in gpg.conf (Re: Key 
> collisions in the wild"):
> > [explanation]
> 
> Thanks.
> 
> I don't know what side of this (one) line such a proposed gpg change
> falls.  I still think it's unsatisfactory that our stable release has
> a default behaviour which cannot be used safely.

Well, I'd argue that 64bit IDs are not safe either, they have not been
made to be.

Samuel

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Ian Jackson]

Adam D. Barratt writes ("Re: use long keyid-format in gpg.conf (Re: Key 
collisions in the wild"):
> [explanation]

Thanks.

I don't know what side of this (one) line such a proposed gpg change
falls.  I still think it's unsatisfactory that our stable release has
a default behaviour which cannot be used safely.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Adam D. Barratt]

On 2016-08-10 12:55, Ian Jackson wrote:

Adam D. Barratt writes ("Re: use long keyid-format in gpg.conf (Re:
Key collisions in the wild"):

On 2016-08-10 11:39, Ian Jackson wrote:
> It would be much better to put out a stable release update to change
> the default.  (Probably not a security update because of the risk of
> causing currently-vulnerable scripts to become nonfunctional, which is
> not something we normally do in security updates.)

Stable updates in point releases aren't fundamentally different in 
that

respect to those issued via the security archive.


I was under the impression that the intent was that there was a
meaningful distinction in the level of conservativeness between "take
security updates" and "take security updates and stable updates too".

If that's not the case, then I don't understand what the distinction
is.


That depends on what you mean by "stable updates". If you mean those 
announced via debian-stable-announce@ then the primary difference is 
that they don't need to be (and often won't be) security-related. If 
you're talking about point releases, then from a security perspective 
the fundamental difference is the speed at which updates are made 
available to users.


Not all security updates are released via the security archive, but the 
difference is more likely to be a result of the manpower available to 
handle managing and releasing such updates and the perceived impact of 
the vulnerability. "We" assume that the majority of users will upgrade 
to stable point releases once they're available and there's a 
corresponding expectation on the part of our users as to what kind of 
updates will be included; the decision as to whether to break existing 
setups shouldn't be fundamentally different simply based on how the 
update was released.


Regards,

Adam

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Samuel Thibault]

Samuel Thibault, on Wed 10 Aug 2016 12:46:07 +0200, wrote:
> Holger Levsen, on Wed 10 Aug 2016 10:26:09 +, wrote:
> > I'm somewhat surprised by this mail… or rather by you appearantly
> > knowing about the issue but still you seem to not have acted as advised,
> > so let me repeat: everybody, please put "keyid-format long" into your
> > ~/.gnupg/gpg.conf!
> 
> Well, I did in the end, yes, but I personally have never trusted these
> IDs anyway, and would only trust signature paths.

And actually, moving to 64bit fingerprints by default is possibly not a
good idea: who knows when 64bit will not be secure any more? Estimating
very roughly, if a 32bit collision can be found within a few seconds
with one GPU now as evil32 seems to show, a supercomputer with 1
GPUs can find a 64bit collision within a month...

Really, only signature paths should be looked at by people, and it seems
like we are tending to let people think 64bit fingerprints are "secure".

Samuel

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Ian Jackson]

Adam D. Barratt writes ("Re: use long keyid-format in gpg.conf (Re: Key 
collisions in the wild"):
> On 2016-08-10 11:39, Ian Jackson wrote:
> > It would be much better to put out a stable release update to change
> > the default.  (Probably not a security update because of the risk of
> > causing currently-vulnerable scripts to become nonfunctional, which is
> > not something we normally do in security updates.)
> 
> Stable updates in point releases aren't fundamentally different in that 
> respect to those issued via the security archive.

I was under the impression that the intent was that there was a
meaningful distinction in the level of conservativeness between "take
security updates" and "take security updates and stable updates too".

If that's not the case, then I don't understand what the distinction
is.

Ian.


-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Adam D. Barratt]

On 2016-08-10 11:39, Ian Jackson wrote:

It would be much better to put out a stable release update to change
the default.  (Probably not a security update because of the risk of
causing currently-vulnerable scripts to become nonfunctional, which is
not something we normally do in security updates.)


Stable updates in point releases aren't fundamentally different in that 
respect to those issued via the security archive.


Regards,

Adam

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Sam Morris]

On Wed, 10 Aug 2016 10:26:09 +, Holger Levsen wrote:

> Hi Samuel,
> 
> On Wed, Aug 10, 2016 at 12:47:43AM +0200, Samuel Thibault wrote:
>> As a late follow-up of the gpg key collision thread from debian-private
>> (but posted on debian-devel, there is nothing private here, I prefer to
>> see this information publicized actually):
>> 
>> € gpg --search-key samuel.thiba...@gnu.org
>> ...
>> (1) Samuel Thibault 
>> 4096 bit RSA key 7D069EE6, created: 2014-06-16
>> (2) Samuel Thibault 
>> 4096 bit RSA key 7D069EE6, created: 2010-09-14
>> 
>> So somebody *does* try to fake my gpg key too...
>> 
>> For the reminder,
>> https://gwolf.org/node/4070
> 
> I'm somewhat surprised by this mail… or rather by you appearantly
> knowing about the issue but still you seem to not have acted as advised,
> so let me repeat: everybody, please put "keyid-format long" into your
> ~/.gnupg/gpg.conf!
> 
> then, the output will look like this:
> 
> $ grep keyid-format .gnupg/gpg.conf 
> keyid-format long
> $ gpg --search-key samuel.thiba...@gnu.org
> ...
> (1) Samuel Thibault 
>   4096 bit RSA key E2992EA47D069EE6, created: 2014-06-16
> (2) Samuel Thibault 
> Samuel Thibault 
> Samuel Thibault 
> Samuel Thibault 
> Samuel Thibault 
>   4096 bit RSA key D0178C767D069EE6, created: 2010-09-14
> 
> 
> voila.

FYI, --search-key looks like this by default in 2.1. And when listing 
keys and in other operations, the output is even more verbose:

$ gpg2 -k sam@robots
pub   rsa4096 2014-04-08 [SC] [expires: 2019-04-07]
  CA1ACA69A83A892B1855D20B42025CDA27B9
uid   [ultimate] Sam Morris 
sub   rsa4096 2014-04-08 [E] [expires: 2019-04-07]

pub   dsa1024 2003-12-01 [SC] [expired: 2014-11-21]
  3412EA181277354B991BC869B2197FDB5EA01078
uid   [ expired] Sam Morris 

IMO this should be made consistent and the full fingerprint should be 
used for --search-key as it is with other operations, by default.

-- 
Sam Morris
https://robots.org.uk/
 
PGP: rsa4096/5CDA27B9
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Samuel Thibault]

Holger Levsen, on Wed 10 Aug 2016 10:26:09 +, wrote:
> I'm somewhat surprised by this mail… or rather by you appearantly
> knowing about the issue but still you seem to not have acted as advised,
> so let me repeat: everybody, please put "keyid-format long" into your
> ~/.gnupg/gpg.conf!

Well, I did in the end, yes, but I personally have never trusted these
IDs anyway, and would only trust signature paths.

Samuel

use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Ian Jackson]

Holger Levsen writes ("use long keyid-format in gpg.conf (Re: Key collisions in 
the wild"):
> I'm somewhat surprised by this mail… or rather by you appearantly
> knowing about the issue but still you seem to not have acted as advised,
> so let me repeat: everybody, please put "keyid-format long" into your
> ~/.gnupg/gpg.conf!

I am dismayed to once again see advice which suggests that systematic
security bugs in the default behaviour of gnupg should be addressed on
an ad-hoc basis by individual users editing their personal
configuration.

It would be much better to put out a stable release update to change
the default.  (Probably not a security update because of the risk of
causing currently-vulnerable scripts to become nonfunctional, which is
not something we normally do in security updates.)

Even if long keyids are not sufficient, they are a big improvement and
we should not let fixing this problem properly stand in the way of
doing what we can, now.

Ian.

use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Holger Levsen]

Hi Samuel,

On Wed, Aug 10, 2016 at 12:47:43AM +0200, Samuel Thibault wrote:
> As a late follow-up of the gpg key collision thread from debian-private
> (but posted on debian-devel, there is nothing private here, I prefer to
> see this information publicized actually):
> 
> € gpg --search-key samuel.thiba...@gnu.org
> ...
> (1) Samuel Thibault 
> 4096 bit RSA key 7D069EE6, created: 2014-06-16
> (2) Samuel Thibault 
> 4096 bit RSA key 7D069EE6, created: 2010-09-14
> 
> So somebody *does* try to fake my gpg key too...
> 
> For the reminder,
> https://gwolf.org/node/4070

I'm somewhat surprised by this mail… or rather by you appearantly
knowing about the issue but still you seem to not have acted as advised,
so let me repeat: everybody, please put "keyid-format long" into your
~/.gnupg/gpg.conf!

then, the output will look like this:

$ grep keyid-format .gnupg/gpg.conf 
keyid-format long
$ gpg --search-key samuel.thiba...@gnu.org
...
(1) Samuel Thibault 
  4096 bit RSA key E2992EA47D069EE6, created: 2014-06-16
(2) Samuel Thibault 
Samuel Thibault 
Samuel Thibault 
Samuel Thibault 
Samuel Thibault 
  4096 bit RSA key D0178C767D069EE6, created: 2010-09-14


voila.


-- 
cheers,
Holger, puzzled to still see people using short-ids,
especially people who seem to be aware of the problem…


signature.asc
Description: Digital signature