/[gentoo]/xml/htdocs/proj/en/glep/glep-0059.txt
Gentoo

Diff of /xml/htdocs/proj/en/glep/glep-0059.txt

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

Revision 1.5 Revision 1.8
1GLEP: 59 1GLEP: 59
2Title: Manifest2 hash policies and security implications 2Title: Manifest2 hash policies and security implications
3Version: $Revision: 1.5 $ 3Version: $Revision: 1.8 $
4Last-Modified: $Date: 2010/01/31 07:55:45 $ 4Last-Modified: $Date: 2010/02/07 10:39:52 $
5Author: Robin Hugh Johnson <robbat2@gentoo.org>, 5Author: Robin Hugh Johnson <robbat2@gentoo.org>,
6Status: Draft 6Status: Draft
7Type: Standards Track 7Type: Standards Track
8Content-Type: text/x-rst 8Content-Type: text/x-rst
9Requires: 44 9Requires: 44
24========== 24==========
25This GLEP is being written as part of the work on signing the Portage 25This GLEP is being written as part of the work on signing the Portage
26tree, but is only tangentially related to the actual signing of 26tree, but is only tangentially related to the actual signing of
27Manifests. Checksums present one possible weak point in the overall 27Manifests. Checksums present one possible weak point in the overall
28security of the tree - and a comprehensive security plan is needed. 28security of the tree - and a comprehensive security plan is needed.
29
30This GLEP is not mandatory for the tree-signing specification, but
31instead aims to improve the security of the hashes used in Manifest2.
32As such, it is also able to stand on it's own.
29 33
30Specification 34Specification
31============= 35=============
32The bad news 36The bad news
33------------ 37------------
52by Wang et al [W04], the time required to break MD5 has been massively 56by Wang et al [W04], the time required to break MD5 has been massively
53reduced. Originally at 1 hour on a near-supercomputer (IBM P690) and 57reduced. Originally at 1 hour on a near-supercomputer (IBM P690) and
54estimated at 64 hours with a Pentium-3 1.7Ghz. This has gone down to 58estimated at 64 hours with a Pentium-3 1.7Ghz. This has gone down to
55less than in two years, to 17 seconds [K06a]. 59less than in two years, to 17 seconds [K06a].
56 60
5708/2004 - 1 hour, IBM pSeries 690 (32x 1.7Ghz POWER4+) = 54.4 GHz-Hours 61- 08/2004 - 1 hour, IBM pSeries 690 (32x 1.7Ghz POWER4+) = 54.4 GHz-Hours
62
5803/2005 - 8 hours, Pentium-M 1.6Ghz = 12.8 Ghz-Hours 63- 03/2005 - 8 hours, Pentium-M 1.6Ghz = 12.8 Ghz-Hours
64
5911/2005 - 5 hours, Pentium-4 1.7Ghz = 8.5 Ghz-Hours 65- 11/2005 - 5 hours, Pentium-4 1.7Ghz = 8.5 Ghz-Hours
66
6003/2006 - 1 minute, Pentium-4 3.2Ghz = .05 Ghz-Hours 67- 03/2006 - 1 minute, Pentium-4 3.2Ghz = .05 Ghz-Hours
68
6104/2006 - 17 seconds, Pentium-4 3.2Ghz = .01 Ghz-Hours 69- 04/2006 - 17 seconds, Pentium-4 3.2Ghz = .01 Ghz-Hours
62 70
63If we accept a factor of 800x as a sample of how much faster a checksum 71If we accept a factor of 800x as a sample of how much faster a checksum
64may be broken over the course of 2 years (MD5 using the above data is 72may be broken over the course of 2 years (MD5 using the above data is
65>2000x), then existing checksums do not stand a significant chance of 73>2000x), then existing checksums do not stand a significant chance of
66survival in the future. We should thus accept that whatever checksums we 74survival in the future. We should thus accept that whatever checksums we
90------------------- 98-------------------
91Portage should always try to verify all supported hashes that are 99Portage should always try to verify all supported hashes that are
92available in a Manifest2, starting with the strongest ones as maintained 100available in a Manifest2, starting with the strongest ones as maintained
93by a preference list. Over time, the weaker checksums should be removed 101by a preference list. Over time, the weaker checksums should be removed
94from Manifest2 files, once all old Portage installations have had 102from Manifest2 files, once all old Portage installations have had
95sufficient time to upgrade. We should be prepared to add stronger 103sufficient time to upgrade. Stronger checksums shall be added as soon as
96checksums wherever possible, and to remove those that have been 104an implementation is available in Portage. Weak checksums may be removed
97defeated. 105as long as the depreciation process is followed (see below).
98 106
99As soon as feasible, we should add the SHA512 and WHIRLPOOL algorithms. 107As soon as feasible, we should add the SHA512 and WHIRLPOOL algorithms.
100In future, as stream-based checksums are developed (in response to the 108In future, as stream-based checksums are developed (in response to the
101development by NIST [AHS]), they should be considered and used. 109development by NIST [AHS]), they should be considered and used.
102 110
103The SHA512 algorithm is available in Python 2.5, which has been a 111The SHA512 algorithm is available in Python 2.5, which has been a
104dependency of Portage since approximately Python 2.1.6.13. 112dependency of Portage since approximately Portage 2.1.6.13.
105 113
106The WHIRLPOOL checksum is not available within the PyCrypto library or 114The WHIRLPOOL checksum is not available within the PyCrypto library or
107hashlib that is part of Python 2.5, but there are multiple alternative 115hashlib that is part of Python 2.5, but there are multiple alternative
108Python implementations available, ranging from pure Python to C-based 116Python implementations available, ranging from pure Python to C-based
109(python-mhash). 117(python-mhash).
111The existence unsupported hash is not considered to be a failure unless 119The existence unsupported hash is not considered to be a failure unless
112no supported hashes are available for a given Manifest entry. 120no supported hashes are available for a given Manifest entry.
113 121
114Checksum depreciation timing 122Checksum depreciation timing
115---------------------------- 123----------------------------
124General principles:
125~~~~~~~~~~~~~~~~~~~
126A minimum set of depreciated checksums shall be maintained only to
127support old package manager versions where needed by historically used
128trees:
129
130- New package manager versions should NOT use depreciated checksums in
131
132- New trees with that have never used the depreciated checksums may omit
133 them for reasons of size, but are still strongly suggested to include
134 them.
135
136- Removal of depreciated checksums shall happen after no less than 18
137 months or one major Portage version cycle, whichever is greater.
138
139Immediate plans:
140~~~~~~~~~~~~~~~~
116For the current Portage, both SHA1 and RIPEMD160 should be immediately 141For the current Portage, both SHA1 and RIPEMD160 should be immediately
117removed, as they present no advantages over the already present SHA256. 142removed, as they present no advantages over the already present SHA256.
118SHA256 cannot be replaced immediately with SHA512, as existing Portage 143SHA256 cannot be replaced immediately with SHA512, as existing Portage
119versions need at least one supported algorithm present (SHA256 support 144versions need at least one supported algorithm present (SHA256 support
120was added in June 2006), so it must be retained for some while. 145was added in June 2006), so it must be retained for some while.
121 146
122Immediately: 147Immediately:
148
123- Add WHIRLPOOL and SHA512. 149- Add WHIRLPOOL and SHA512.
150
124- Remove SHA1 and RIPEMD160. 151- Remove SHA1 and RIPEMD160.
125 152
126After the majority of Portage installations include SHA512 support: 153After the majority of Portage installations include SHA512 support:
154
127- Remove SHA256. 155- Remove SHA256.
128 156
129Backwards Compatibility 157Backwards Compatibility
130======================= 158=======================
131Old versions of Portage may support and expect only specific checksums. 159Old versions of Portage may support and expect only specific checksums.
132This is accounted for in the checksum depreciation discussion. 160This is accounted for in the checksum depreciation discussion.
161
162For maximum compatiability, we should only have to include each of the
163old algorithms that we are officially still supporting, as well as the
164new ones that we prefer.
133 165
134References 166References
135========== 167==========
136 168
137[AHS] NIST (2007). "NIST's Plan for New Cryptographic Hash Functions", 169[AHS] NIST (2007). "NIST's Plan for New Cryptographic Hash Functions",

Legend:
Removed from v.1.5  
changed lines
  Added in v.1.8

  ViewVC Help
Powered by ViewVC 1.1.20