| 1 | GLEP: 59 |
1 | GLEP: 59 |
| 2 | Title: Manifest2 hash policies and security implications |
2 | Title: Manifest2 hash policies and security implications |
| 3 | Version: $Revision: 1.7 $ |
3 | Version: $Revision: 1.8 $ |
| 4 | Last-Modified: $Date: 2010/02/02 05:49:27 $ |
4 | Last-Modified: $Date: 2010/02/07 10:39:52 $ |
| 5 | Author: Robin Hugh Johnson <robbat2@gentoo.org>, |
5 | Author: Robin Hugh Johnson <robbat2@gentoo.org>, |
| 6 | Status: Draft |
6 | Status: Draft |
| 7 | Type: Standards Track |
7 | Type: Standards Track |
| 8 | Content-Type: text/x-rst |
8 | Content-Type: text/x-rst |
| 9 | Requires: 44 |
9 | Requires: 44 |
| … | |
… | |
| 56 | by Wang et al [W04], the time required to break MD5 has been massively |
56 | by Wang et al [W04], the time required to break MD5 has been massively |
| 57 | reduced. Originally at 1 hour on a near-supercomputer (IBM P690) and |
57 | reduced. Originally at 1 hour on a near-supercomputer (IBM P690) and |
| 58 | estimated at 64 hours with a Pentium-3 1.7Ghz. This has gone down to |
58 | estimated at 64 hours with a Pentium-3 1.7Ghz. This has gone down to |
| 59 | less than in two years, to 17 seconds [K06a]. |
59 | less than in two years, to 17 seconds [K06a]. |
| 60 | |
60 | |
| 61 | 08/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 | |
| 62 | 03/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 | |
| 63 | 11/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 | |
| 64 | 03/2006 - 1 minute, Pentium-4 3.2Ghz = .05 Ghz-Hours |
67 | - 03/2006 - 1 minute, Pentium-4 3.2Ghz = .05 Ghz-Hours |
|
|
68 | |
| 65 | 04/2006 - 17 seconds, Pentium-4 3.2Ghz = .01 Ghz-Hours |
69 | - 04/2006 - 17 seconds, Pentium-4 3.2Ghz = .01 Ghz-Hours |
| 66 | |
70 | |
| 67 | If we accept a factor of 800x as a sample of how much faster a checksum |
71 | If we accept a factor of 800x as a sample of how much faster a checksum |
| 68 | may be broken over the course of 2 years (MD5 using the above data is |
72 | may be broken over the course of 2 years (MD5 using the above data is |
| 69 | >2000x), then existing checksums do not stand a significant chance of |
73 | >2000x), then existing checksums do not stand a significant chance of |
| 70 | survival in the future. We should thus accept that whatever checksums we |
74 | survival in the future. We should thus accept that whatever checksums we |
| … | |
… | |
| 94 | ------------------- |
98 | ------------------- |
| 95 | Portage should always try to verify all supported hashes that are |
99 | Portage should always try to verify all supported hashes that are |
| 96 | available in a Manifest2, starting with the strongest ones as maintained |
100 | available in a Manifest2, starting with the strongest ones as maintained |
| 97 | by a preference list. Over time, the weaker checksums should be removed |
101 | by a preference list. Over time, the weaker checksums should be removed |
| 98 | from Manifest2 files, once all old Portage installations have had |
102 | from Manifest2 files, once all old Portage installations have had |
| 99 | sufficient time to upgrade. We should be prepared to add stronger |
103 | sufficient time to upgrade. Stronger checksums shall be added as soon as |
| 100 | checksums wherever possible, and to remove those that have been |
104 | an implementation is available in Portage. Weak checksums may be removed |
| 101 | defeated. |
105 | as long as the depreciation process is followed (see below). |
| 102 | |
106 | |
| 103 | As soon as feasible, we should add the SHA512 and WHIRLPOOL algorithms. |
107 | As soon as feasible, we should add the SHA512 and WHIRLPOOL algorithms. |
| 104 | In future, as stream-based checksums are developed (in response to the |
108 | In future, as stream-based checksums are developed (in response to the |
| 105 | development by NIST [AHS]), they should be considered and used. |
109 | development by NIST [AHS]), they should be considered and used. |
| 106 | |
110 | |
| … | |
… | |
| 115 | The existence unsupported hash is not considered to be a failure unless |
119 | The existence unsupported hash is not considered to be a failure unless |
| 116 | no supported hashes are available for a given Manifest entry. |
120 | no supported hashes are available for a given Manifest entry. |
| 117 | |
121 | |
| 118 | Checksum depreciation timing |
122 | Checksum depreciation timing |
| 119 | ---------------------------- |
123 | ---------------------------- |
|
|
124 | General principles: |
|
|
125 | ~~~~~~~~~~~~~~~~~~~ |
|
|
126 | A minimum set of depreciated checksums shall be maintained only to |
|
|
127 | support old package manager versions where needed by historically used |
|
|
128 | trees: |
|
|
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 | |
|
|
139 | Immediate plans: |
|
|
140 | ~~~~~~~~~~~~~~~~ |
| 120 | For the current Portage, both SHA1 and RIPEMD160 should be immediately |
141 | For the current Portage, both SHA1 and RIPEMD160 should be immediately |
| 121 | removed, as they present no advantages over the already present SHA256. |
142 | removed, as they present no advantages over the already present SHA256. |
| 122 | SHA256 cannot be replaced immediately with SHA512, as existing Portage |
143 | SHA256 cannot be replaced immediately with SHA512, as existing Portage |
| 123 | versions need at least one supported algorithm present (SHA256 support |
144 | versions need at least one supported algorithm present (SHA256 support |
| 124 | was added in June 2006), so it must be retained for some while. |
145 | was added in June 2006), so it must be retained for some while. |
| 125 | |
146 | |
| 126 | Immediately: |
147 | Immediately: |
|
|
148 | |
| 127 | - Add WHIRLPOOL and SHA512. |
149 | - Add WHIRLPOOL and SHA512. |
|
|
150 | |
| 128 | - Remove SHA1 and RIPEMD160. |
151 | - Remove SHA1 and RIPEMD160. |
| 129 | |
152 | |
| 130 | After the majority of Portage installations include SHA512 support: |
153 | After the majority of Portage installations include SHA512 support: |
|
|
154 | |
| 131 | - Remove SHA256. |
155 | - Remove SHA256. |
| 132 | |
156 | |
| 133 | Backwards Compatibility |
157 | Backwards Compatibility |
| 134 | ======================= |
158 | ======================= |
| 135 | Old versions of Portage may support and expect only specific checksums. |
159 | Old versions of Portage may support and expect only specific checksums. |
Parent Directory
| 
Revision Log
| 
Patch