Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild
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
Reply to: