From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LW5Vc-0002mz-1K for garchives@archives.gentoo.org; Sun, 08 Feb 2009 08:59:24 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9B331E03A5; Sun, 8 Feb 2009 08:59:21 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 5F728E03A5 for ; Sun, 8 Feb 2009 08:59:21 +0000 (UTC) Received: from [192.168.22.10] (ip68-4-152-120.oc.oc.cox.net [68.4.152.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id DD15864F1B for ; Sun, 8 Feb 2009 08:59:20 +0000 (UTC) Message-ID: <498E9EFE.2030807@gentoo.org> Date: Sun, 08 Feb 2009 00:59:42 -0800 From: Zac Medico User-Agent: Thunderbird 2.0.0.19 (X11/20081209) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation References: <498758E6.5080609@gentoo.org> <1234045916.24784.1373.camel@localhost> <498E17E6.8060407@gentoo.org> <1234080464.24784.2517.camel@localhost> In-Reply-To: <1234080464.24784.2517.camel@localhost> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: ce899d12-b644-444e-aa6f-f4aff6f6e65a X-Archives-Hash: 040afd4e625896d087aa71bfb5fb53bc -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tiziano M=C3=BCller wrote: > Am Samstag, den 07.02.2009, 15:23 -0800 schrieb Zac Medico: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Tiziano M=C3=BCller 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 hashin= g >>> (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 >=20 > 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 fee= l > 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 =3DjPpV -----END PGP SIGNATURE-----