| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Tiziano Müller wrote: |
| 5 |
> Am Samstag, den 07.02.2009, 15:23 -0800 schrieb Zac Medico: |
| 6 |
>> -----BEGIN PGP SIGNED MESSAGE----- |
| 7 |
>> Hash: SHA1 |
| 8 |
>> |
| 9 |
>> Tiziano Müller wrote: |
| 10 |
>>> Am Montag, den 02.02.2009, 12:34 -0800 schrieb Zac Medico: |
| 11 |
>>>> For the digest format, I suggest that we use the leftmost 10 |
| 12 |
>>>> hexadecimal digits of the SHA-1 digest. The rationale for limiting |
| 13 |
>>>> it to 10 digits (out of 40) is to save space. Due to the avalanche |
| 14 |
>>>> effect [2], 10 digits should be sufficient to ensure that problems |
| 15 |
>>>> resulting from hash collisions are extremely unlikely. |
| 16 |
>>> I'd recommend to prefix the digest with a "{TYPE}" (like for hashed |
| 17 |
>>> passwords) to be able to change the digest algorithm as needed |
| 18 |
>>> (especially in regards to the current SHA successor competition). |
| 19 |
>>> This allows a future package manager which might use SHA-3 for hashing |
| 20 |
>>> (once it's released) to still check old digests. Furthermore it would |
| 21 |
>>> allow for easier transition and only needs a definition of allowed |
| 22 |
>>> hashes instead of a specific one. |
| 23 |
>> I like that idea. That way it's not necessary to bump the EAPI in |
| 24 |
>> order to change the hash function. So, a typical DIGESTS value might |
| 25 |
>> look like this: |
| 26 |
>> |
| 27 |
>> SHA1 02021be38b a28b191904 3992945426 6ec21b29a3 |
| 28 |
> |
| 29 |
> Sleeping over it again I don't think that truncating a hash is a good |
| 30 |
> idea (truncating it from 40 to 10 digits makes the possibility of |
| 31 |
> collisions much much higher). |
| 32 |
|
| 33 |
The probability of collision is much higher, but it's still |
| 34 |
relatively small. Given the "avalanche effect" that is typical of |
| 35 |
cryptographic hash functions, it's extremely unlikely that collision |
| 36 |
will occur in such a way that it will cause a problem for cache |
| 37 |
validation. |
| 38 |
|
| 39 |
> But if you want to go this way, I'd say you should use something like |
| 40 |
> SHA1t (t for truncated) to make sure we can use full hashes once we feel |
| 41 |
> it's appropriate. |
| 42 |
|
| 43 |
We could, but I think SHA1 would also be fine since one can infer |
| 44 |
from the length of the string that it's been truncated. |
| 45 |
- -- |
| 46 |
Thanks, |
| 47 |
Zac |
| 48 |
-----BEGIN PGP SIGNATURE----- |
| 49 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 50 |
|
| 51 |
iEYEARECAAYFAkmOnvwACgkQ/ejvha5XGaPtSACeOS21UYlvkMQy5q86B+9aKHpH |
| 52 |
DnUAoK1P83uKFEd2uzfc2t+QhArMHeEZ |
| 53 |
=jPpV |
| 54 |
-----END PGP SIGNATURE----- |
Archives