[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
signature.asc
Description: OpenPGP digital signature