AW: Why do Key Fingerprints include Creation Timestamp?

Daniel Kahn Gillmor dkg at fifthhorseman.net
Wed Jan 31 16:54:45 CET 2018


On Wed 2018-01-31 09:37:54 +0000, Fiedler Roman wrote:
> Including it provides a fast way to generate keys without changing 
> cryptographic material (slow),

I think you mean "to generate fingerprints", not "to generate keys" --
right?  in particular, i think you're talking about the computational
expense of searching the fingerprint space for certain properties.

fwiw, cryptographic material generation itself is also super cheap these
days (in particular, ecc keys just need a small and predictable amount
of entropy to find).  And if you're trying to do something devious where
you don't care about the security of the key, even key formats that
require searching for primes don't have a large cost.

> thus speeds up creating keys with given 32 key-ID, 64 key-id might
> also be possible. Thus making it easier to provoke human errors
> (fingerprints where first/last 16 bit are matching another key,
> identical key-ID) ...

These are great reasons to never use key IDs for any purpose [0].
They're not particularly compelling reasons to avoid including the
creation date, given that the computational expense of fingerprint
search is basically the same whether you include the creation timestamp
or not.  If the goal is to increase computational expense of fingerprint
search, there are better ways to do that (though they require changing
the spec for OpenPGP, and most proposals i've seen to do so incur
additional costs at other places in an OpenPGP workflow, which may or
may not be a cost worth paying).

Regards,

        --dkg

[0] i agree, and i've argued this more comprehensively here:
    https://debian-administration.org/users/dkg/weblog/105
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180131/ddb34d6e/attachment.sig>


More information about the Gnupg-users mailing list