1 |
On Mon, 2022-09-12 at 15:38 +0200, Michał Górny wrote: |
2 |
> + +-----------------+-----------------------+------+------+-------------+ |
3 |
> + | Name | Specification | Bits | Enc. | Notes | |
4 |
> + +=================+=======================+======+======+=============+ |
5 |
> + | ``BLAKE2B`` | | 512 | Hex | Recommended | |
6 |
> + +-----------------+ RFC 7693 [#RFC7693]_ +------+------+-------------+ |
7 |
> + | ``BLAKE2S`` | | 256 | Hex | | |
8 |
> + +-----------------+-----------------------+------+------+-------------+ |
9 |
> + | ``MD5`` | RFC 1321 [#RFC1321]_ | 128 | Hex | Deprecated | |
10 |
> + +-----------------+-----------------------+------+------+-------------+ |
11 |
> + | ``RMD160`` | RIPEMD-160 [#RMD160]_ | 160 | Hex | Deprecated | |
12 |
|
13 |
Small change here after some internal and external consideration: I've |
14 |
removed the "deprecated" tag from RIPEMD-160 since (unlike MD5/SHA1) |
15 |
it's not officially considered weakened. |
16 |
|
17 |
> + +-----------------+-----------------------+------+------+-------------+ |
18 |
> + | ``SHA1`` | | 160 | Hex | Deprecated | |
19 |
> + +-----------------+ +------+------+-------------+ |
20 |
> + | ``SHA256`` | FIPS 180-4 [#SHS]_ | 256 | Hex | | |
21 |
> + +-----------------+ +------+------+-------------+ |
22 |
> + | ``SHA512`` | | 512 | Hex | Recommended | |
23 |
> + +-----------------+-----------------------+------+------+-------------+ |
24 |
> + | ``SHA3_256`` | | 256 | Hex | | |
25 |
> + +-----------------+ FIPS 202 [#SHA3]_ +------+------+-------------+ |
26 |
> + | ``SHA3_512`` | | 512 | Hex | | |
27 |
> + +-----------------+-----------------------+------+------+-------------+ |
28 |
> + | ``STREEBOG256`` | | 256 | Hex | | |
29 |
> + +-----------------+ RFC 6986 [#RFC6986]_ +------+------+-------------+ |
30 |
> + | ``STREEBOG512`` | | 512 | Hex | | |
31 |
> + +-----------------+-----------------------+------+------+-------------+ |
32 |
> + | ``WHIRLPOOL`` | Whirlpool [#BARRETO]_ | 512 | Hex | | |
33 |
> + +-----------------+-----------------------+------+------+-------------+ |
34 |
> + |
35 |
> +Any new hashes must be added to this specification prior to being used |
36 |
> +in Manifest files. Adding a new hash is considered |
37 |
> +a backwards-compatible change to the GLEP. It is recommended that new |
38 |
> +hashes are named after the Python ``hashlib`` module algorithm names, |
39 |
> +transformed into uppercase, with dashes replaced by underscores. |
40 |
> + |
41 |
> +An implementation can implement an arbitrary subset of the listed |
42 |
> +hashes. For best interoperability, it should implement at least |
43 |
> +recommended hashes. If deprecated hashes are implemented, it is |
44 |
> +preferable to disallow their use by default. |
45 |
> + |
46 |
> +If an entry specifies multiple hashes using different algorithms, |
47 |
> +an implementation may choose to verify an arbitrary subset of them. |
48 |
> +However, should any tested hash yield a mismatch, the verification must |
49 |
> +fail. |
50 |
> + |
51 |
> +If a particular hash is either unsupported or unknown, |
52 |
> +the implementation can either ignore it or report a failure. However, |
53 |
> +at least one algorithm specified for a particular entry must be |
54 |
> +supported for the verification to succeed. |
55 |
> |
56 |
> |
57 |
> Manifest compression |
58 |
> @@ -913,23 +949,25 @@ tool working with this Manifest format. |
59 |
> Hash algorithms |
60 |
> --------------- |
61 |
> |
62 |
> -While maintaining a consistent supported hash set is important |
63 |
> -for interoperability, it is not a good fit for the generic layout |
64 |
> -of this GLEP. Furthermore, it would require updating the GLEP |
65 |
> -in the future every time the used algorithms change. |
66 |
> +Originally, this GLEP did not formally specify the complete set of hash |
67 |
> +algorithms. Instead, it only listed (informationally) the names already |
68 |
> +used at the time of writing. Since enforcing consistent use of algorithm |
69 |
> +names is important for interoperability, this was changed in version |
70 |
> +1.3. |
71 |
> |
72 |
> -Instead, the specification focuses on listing the currently used |
73 |
> -algorithm names for interoperability, and sets a recommendation |
74 |
> -for consistent naming of algorithms in the future. The Python |
75 |
> -``hashlib`` module is used as a reference since it is used |
76 |
> -as the provider of hash functions for most of the Python software, |
77 |
> -including Portage and PkgCore. |
78 |
> +Since the effort needed to update the GLEP is small compared to the time |
79 |
> +needed for a new hash algorithm to be well-deployed, the GLEP needs |
80 |
> +to be updated prior to adding a new hash method. |
81 |
> |
82 |
> -The basic rules for changing hash algorithms are defined in GLEP 59 |
83 |
> -[#GLEP59]_. The implementations can focus only on those algorithms |
84 |
> -that are actually used or planned on being used. It may be feasible |
85 |
> -to devise a new GLEP that specifies the currently used hashes (or update |
86 |
> -GLEP 59 accordingly). |
87 |
> +The recommended naming is based off Python ``hashlib`` module, |
88 |
> +as most of the Gentoo tooling is written in Python. The names |
89 |
> +are transformed to match the historical naming used for hash functions |
90 |
> +in Manifests. |
91 |
> + |
92 |
> +Implementations are allowed to support and use only a subset of hashes |
93 |
> +listed in Manifest files. This could be used both to avoid the overhead |
94 |
> +of computing multiple hashes on non-performant systems, and to handle |
95 |
> +transition to new hashes gracefully. |
96 |
> |
97 |
> |
98 |
> Manifest compression |
99 |
> @@ -1072,27 +1110,29 @@ References |
100 |
> .. [#FILE-NAMING-RULES] Ebuild File Format -- Gentoo Development Guide |
101 |
> (https://devmanual.gentoo.org/ebuild-writing/file-format/#file-naming-rules) |
102 |
> |
103 |
> -.. [#MD5] RFC1321: The MD5 Message-Digest Algorithm |
104 |
> - (https://www.ietf.org/rfc/rfc1321.txt) |
105 |
> +.. [#RFC7693] RFC 7693: The BLAKE2 Cryptographic Hash and Message Authentication |
106 |
> + Code (MAC) |
107 |
> + (https://www.rfc-editor.org/rfc/rfc7693) |
108 |
> + |
109 |
> +.. [#RFC1321] RFC 1321: The MD5 Message-Digest Algorithm |
110 |
> + (https://www.rfc-editor.org/rfc/rfc1321) |
111 |
> |
112 |
> -.. [#RIPEMD160] The hash function RIPEMD-160 |
113 |
> +.. [#RMD160] The hash function RIPEMD-160 |
114 |
> (https://homes.esat.kuleuven.be/~bosselae/ripemd160.html) |
115 |
> |
116 |
> .. [#SHS] FIPS PUB 180-4: Secure Hash Standard (SHS) |
117 |
> (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf) |
118 |
> |
119 |
> -.. [#WHIRLPOOL] The WHIRLPOOL Hash Function |
120 |
> - (http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html) |
121 |
> - |
122 |
> -.. [#BLAKE2] BLAKE2 -- fast secure hashing |
123 |
> - (https://blake2.net/) |
124 |
> - |
125 |
> .. [#SHA3] FIPS PUB 202: SHA-3 Standard: Permutation-Based Hash |
126 |
> and Extendable-Output Functions |
127 |
> (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf) |
128 |
> |
129 |
> -.. [#STREEBOG] GOST R 34.11-2012: Streebog Hash Function |
130 |
> - (https://www.streebog.net/) |
131 |
> +.. [#RFC6986] RFC 6986: GOST R 34.11-2012: Hash Function |
132 |
> + (https://www.rfc-editor.org/rfc/rfc6986) |
133 |
> + |
134 |
> +.. [#BARRETO] Paulo S. L. M. Barreto, The WHIRLPOOL Hash Function |
135 |
> + (archived at 2017-11-29) |
136 |
> + (https://web.archive.org/web/20171129084214/http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html) |
137 |
> |
138 |
> .. [#C08] Cappos, J et al. (2008). "Attacks on Package Managers" |
139 |
> (https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html) |
140 |
|
141 |
-- |
142 |
Best regards, |
143 |
Michał Górny |