sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] Long keyids (64-bit) instead of short (32-bit)?


From: Kristian Fiskerstrand
Subject: Re: [Sks-devel] Long keyids (64-bit) instead of short (32-bit)?
Date: Wed, 25 Jan 2017 20:20:40 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0

On 01/25/2017 08:04 PM, Gunnar Wolf wrote:
> Hi,
> 
> When queried for a key, SKS answers with just the short keyid — Just
> 32 bits. In my case, just "C1DB921F". We have already been "attacked"
> (each of us will say whether it's a true attack or just an academic
> excercise) by the Evil32 keyring.

This isn't really an issue, using 32 bit keyid as short reference is
perfectly fine, and internal references are done using 64 bit already.

> 
> Even more, as keys are presented in reverse creation time order,
> naturally, Evil32 keys are always presented before the keys they
> "cloned". Fortunately, yes, they have all been revoked.

The order doesn't matter, a keyblock anyways needs to be downloaded and
verified by a local client to ensure proper self-signatures etc.

> 
> Anyway — I was looking for a way to make SKS present 64-bit long
> keyids (say, 673A03E4C1DB921F) instead of only 32-bit ones — Not only
> for the two keys to be clearly different, but to help get our users to
> change their mindset and identify long keyids as the default. I know
> that is still not optimal and that there is a long discussion in that
> regard, but it is clearly better than an easily forgeable 32-bit ID.

It is a false sense of security and if relying on the keyserver response
without validation is a failure in operational security practices. I
have written some about that for the evil32 attack specifically at
https://blog.sumptuouscapital.com/2016/08/openpgp-duplicate-keyids-short-vs-long/

> 
> Any ideas on how to do this? Is it a configurable option even (or
> should we expect this change only for a new release)?

Its not a configuration option, changing it is actually trivial enough
(I seem to recall doing it at one point just to test a bit) - but it
doesn't improve security in any form.

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Adde parvum parvo magnus acervus erit
Add little to little and there will be a big pile

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]