SHA3 IANA registration - method?

[Andrey Jivsov]

On 12/17/2012 05:01 PM, Daniel Kahn Gillmor wrote:
> On 12/17/2012 07:02 PM, Andrey Jivsov wrote:
>> On 12/17/2012 03:44 PM, Daniel Kahn Gillmor wrote:
>>> https://tools.ietf.org/html/rfc4880#page-72 :
>>>
>>>>>      Note that it is possible for there to be collisions of Key IDs -- two
>>>>>      different keys with the same Key ID.  Note that there is a much
>>>>>      smaller, but still non-zero, probability that two different keys have
>>>>>      the same fingerprint.
>
>> The quote you provided talks about keyID.
>
> It starts by talking about the key ID (64 bits, not 32 bits, fwiw -- see
> section 3.3), and it concludes by talking about the fingerprint.
>
> Regards,
>
> 	--dkg
>

I was referring to the fact that in a group of keys about 2^32 will 
likely have a pair of colliding 8 byte keyIDs. If a message or a 3d 
party signature references one of these keys, we have a collision.

OK, there is a language about fingerprint, but it will have 1/2^80 
probability of a collision, not something to worry about. Commonly used 
UUIDs will have the probability of 1/2^64, for comparison. Thus, that 
last line about fingerprints should not be taken as a practical 
consideration.

These types of collisions were mentioned in a context of a hash function 
that is viewed as a random hash function.

KeyIDs are simply the ending of the fingerprint. It's quite easy today 
to produce two keys with colliding keyIDs simply by random key 
generation. However, these 2 keys will have different fingerprints. The 
expectation is that it's safe to log these fingerprints in the audit 
log. So, while it was not safe to rely on uniqueness of the keyID, it 
was expected that the remedy to this is to use the fingerprints.

Well, not anymore if SHA-1 continues to deteriorate.