Long keyids (64-bit) instead of short (32-bit)?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Long keyids (64-bit) instead of short (32-bit)?

Gunnar Wolf
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.

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.

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.

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

Thanks!

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Long keyids (64-bit) instead of short (32-bit)?

Kristian Fiskerstrand-6
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


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Long keyids (64-bit) instead of short (32-bit)?

Phil Pennock-17
In reply to this post by Gunnar Wolf
On 2017-01-25 at 13:04 -0600, Gunnar Wolf wrote:
> 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

https://bitbucket.org/philpennock/sks-keyserver-philp/branch/opt-long-keyids

See my recent post to the list, subject-line mentioning ocaml.

I've been running with these changes and they seem stable.  I had one
bout of BDB corruption but (1) db_recover fixed it and (2) it hasn't
reoccurred so I'm starting to think that it's just coincidental timing.

If you're not building with the 4.02.whatever ocaml then read the
messages in the thread, see the other branch which had those changes and
generate a patch from the commits only in the opt-long-keyids branch.

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

It would have to be a new release.  Someone actually experienced with
ocaml needs to look at my changes and decide which are safe to pull in.

-Phil

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (849 bytes) Download Attachment