--- xml/htdocs/proj/en/glep/glep-0059.html 2010/02/07 10:39:52 1.10 +++ xml/htdocs/proj/en/glep/glep-0059.html 2010/04/07 21:56:59 1.11 @@ -27,9 +27,9 @@ Title:Manifest2 hash policies and security implications -Version:1.7 +Version:1.9 -Last-Modified:2010/02/02 05:49:27 +Last-Modified:2010/04/07 21:34:24 Author:Robin Hugh Johnson <robbat2 at gentoo.org>, @@ -55,28 +55,29 @@

Contents

-

Abstract

+

Abstract

While Manifest2 format allows multiple hashes, the question of which checksums should be present, why, and the security implications of such have never been resolved. This GLEP covers all of these issues, and @@ -84,19 +85,19 @@ future.

-

Motivation

+

Motivation

This GLEP is being written as part of the work on signing the Portage tree, but is only tangentially related to the actual signing of Manifests. Checksums present one possible weak point in the overall security of the tree - and a comprehensive security plan is needed.

This GLEP is not mandatory for the tree-signing specification, but -instead aims to improve the security of the hashes used in Manifest2. -As such, it is also able to stand on it's own.

+instead aims to improve the security of the hashes used in Manifest2 +[GLEP44]. As such, it is also able to stand on it's own.

-

Specification

+

Specification

-

The bad news

+

The bad news

First of all, I'd like to cover the bad news in checksum security. A much discussed point, as been the simple question: What is the security of multiple independent checksums on the same data? @@ -112,7 +113,7 @@ HAVAL-128 and RIPEMD families of hashes.

-

How fast can MD5 be broken?

+

How fast can MD5 be broken?

For a general collision, not a pre-image attack, since the announcement by Wang et al [W04], the time required to break MD5 has been massively reduced. Originally at 1 hour on a near-supercomputer (IBM P690) and @@ -138,7 +139,7 @@ want.

-

The good news

+

The good news

Of the checksums presently used by Manifest2 (SHA1, SHA256, RIPEMD160), one stands close to being completely broken: SHA1; and another is significantly weakened: RIPEMD160. The SHA2 series has suffered some @@ -150,7 +151,7 @@ keep a specific checksum, such as part of a migration plan.

-

What should be done

+

What should be done

Portage should always try to verify all supported hashes that are available in a Manifest2, starting with the strongest ones as maintained by a preference list. Over time, the weaker checksums should be removed @@ -171,9 +172,9 @@ no supported hashes are available for a given Manifest entry.

-

Checksum depreciation timing

+

Checksum depreciation timing

-

General principles:

+

General principles:

A minimum set of depreciated checksums shall be maintained only to support old package manager versions where needed by historically used trees:

@@ -187,7 +188,7 @@
-

Immediate plans:

+

Immediate plans:

For the current Portage, both SHA1 and RIPEMD160 should be immediately removed, as they present no advantages over the already present SHA256. SHA256 cannot be replaced immediately with SHA512, as existing Portage @@ -206,7 +207,7 @@

-

Backwards Compatibility

+

Backwards Compatibility

Old versions of Portage may support and expect only specific checksums. This is accounted for in the checksum depreciation discussion.

For maximum compatiability, we should only have to include each of the @@ -214,7 +215,7 @@ new ones that we prefer.

-

References

+

References

[AHS] NIST (2007). "NIST's Plan for New Cryptographic Hash Functions",
(Advanced Hash Standard). http://csrc.nist.gov/pki/HashWorkshop/
@@ -252,7 +253,7 @@
-

Thanks to

+

Thanks to

I'd like to thank the following folks, in no specific order:
    @@ -265,19 +266,29 @@
+
+

References

+ + + + + +
[GLEP44]Mauch, M. (2005) GLEP44 - Manifest2 format. +http://www.gentoo.org/proj/en/glep/glep-0044.html
+