Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation

[Zac Medico <zmedico@gentoo.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tiziano Müller wrote:
> Am Samstag, den 07.02.2009, 15:23 -0800 schrieb Zac Medico:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Tiziano Müller wrote:
>>> Am Montag, den 02.02.2009, 12:34 -0800 schrieb Zac Medico:
>>>> For the digest format, I suggest that we use the leftmost 10
>>>> hexadecimal digits of the SHA-1 digest. The rationale for limiting
>>>> it to 10 digits (out of 40) is to save space. Due to the avalanche
>>>> effect [2], 10 digits should be sufficient to ensure that problems
>>>> resulting from hash collisions are extremely unlikely.
>>> I'd recommend to prefix the digest with a "{TYPE}" (like for hashed
>>> passwords) to be able to change the digest algorithm as needed
>>> (especially in regards to the current SHA successor competition).
>>> This allows a future package manager which might use SHA-3 for hashing
>>> (once it's released) to still check old digests. Furthermore it would
>>> allow for easier transition and only needs a definition of allowed
>>> hashes instead of a specific one.
>> I like that idea. That way it's not necessary to bump the EAPI in
>> order to change the hash function. So, a typical DIGESTS value might
>> look like this:
>>
>> SHA1 02021be38b a28b191904 3992945426 6ec21b29a3
> 
> Sleeping over it again I don't think that truncating a hash is a good
> idea (truncating it from 40 to 10 digits makes the possibility of
> collisions much much higher).

The probability of collision is much higher, but it's still
relatively small. Given the "avalanche effect" that is typical of
cryptographic hash functions, it's extremely unlikely that collision
will occur in such a way that it will cause a problem for cache
validation.

> But if you want to go this way, I'd say you should use something like
> SHA1t (t for truncated) to make sure we can use full hashes once we feel
> it's appropriate.

We could, but I think SHA1 would also be fine since one can infer
from the length of the string that it's been truncated.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmOnvwACgkQ/ejvha5XGaPtSACeOS21UYlvkMQy5q86B+9aKHpH
DnUAoK1P83uKFEd2uzfc2t+QhArMHeEZ
=jPpV
-----END PGP SIGNATURE-----