From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH v2 2/3] glep-0074: Specify supported hash algorithms
Date: Wed, 14 Sep 2022 22:50:17 +0200 [thread overview]
Message-ID: <1714c010d43fa2cfc31b8a88cb56be414c753d19.camel@gentoo.org> (raw)
In-Reply-To: <20220912133850.1202010-3-mgorny@gentoo.org>
On Mon, 2022-09-12 at 15:38 +0200, Michał Górny wrote:
> + +-----------------+-----------------------+------+------+-------------+
> + | Name | Specification | Bits | Enc. | Notes |
> + +=================+=======================+======+======+=============+
> + | ``BLAKE2B`` | | 512 | Hex | Recommended |
> + +-----------------+ RFC 7693 [#RFC7693]_ +------+------+-------------+
> + | ``BLAKE2S`` | | 256 | Hex | |
> + +-----------------+-----------------------+------+------+-------------+
> + | ``MD5`` | RFC 1321 [#RFC1321]_ | 128 | Hex | Deprecated |
> + +-----------------+-----------------------+------+------+-------------+
> + | ``RMD160`` | RIPEMD-160 [#RMD160]_ | 160 | Hex | Deprecated |
Small change here after some internal and external consideration: I've
removed the "deprecated" tag from RIPEMD-160 since (unlike MD5/SHA1)
it's not officially considered weakened.
> + +-----------------+-----------------------+------+------+-------------+
> + | ``SHA1`` | | 160 | Hex | Deprecated |
> + +-----------------+ +------+------+-------------+
> + | ``SHA256`` | FIPS 180-4 [#SHS]_ | 256 | Hex | |
> + +-----------------+ +------+------+-------------+
> + | ``SHA512`` | | 512 | Hex | Recommended |
> + +-----------------+-----------------------+------+------+-------------+
> + | ``SHA3_256`` | | 256 | Hex | |
> + +-----------------+ FIPS 202 [#SHA3]_ +------+------+-------------+
> + | ``SHA3_512`` | | 512 | Hex | |
> + +-----------------+-----------------------+------+------+-------------+
> + | ``STREEBOG256`` | | 256 | Hex | |
> + +-----------------+ RFC 6986 [#RFC6986]_ +------+------+-------------+
> + | ``STREEBOG512`` | | 512 | Hex | |
> + +-----------------+-----------------------+------+------+-------------+
> + | ``WHIRLPOOL`` | Whirlpool [#BARRETO]_ | 512 | Hex | |
> + +-----------------+-----------------------+------+------+-------------+
> +
> +Any new hashes must be added to this specification prior to being used
> +in Manifest files. Adding a new hash is considered
> +a backwards-compatible change to the GLEP. It is recommended that new
> +hashes are named after the Python ``hashlib`` module algorithm names,
> +transformed into uppercase, with dashes replaced by underscores.
> +
> +An implementation can implement an arbitrary subset of the listed
> +hashes. For best interoperability, it should implement at least
> +recommended hashes. If deprecated hashes are implemented, it is
> +preferable to disallow their use by default.
> +
> +If an entry specifies multiple hashes using different algorithms,
> +an implementation may choose to verify an arbitrary subset of them.
> +However, should any tested hash yield a mismatch, the verification must
> +fail.
> +
> +If a particular hash is either unsupported or unknown,
> +the implementation can either ignore it or report a failure. However,
> +at least one algorithm specified for a particular entry must be
> +supported for the verification to succeed.
>
>
> Manifest compression
> @@ -913,23 +949,25 @@ tool working with this Manifest format.
> Hash algorithms
> ---------------
>
> -While maintaining a consistent supported hash set is important
> -for interoperability, it is not a good fit for the generic layout
> -of this GLEP. Furthermore, it would require updating the GLEP
> -in the future every time the used algorithms change.
> +Originally, this GLEP did not formally specify the complete set of hash
> +algorithms. Instead, it only listed (informationally) the names already
> +used at the time of writing. Since enforcing consistent use of algorithm
> +names is important for interoperability, this was changed in version
> +1.3.
>
> -Instead, the specification focuses on listing the currently used
> -algorithm names for interoperability, and sets a recommendation
> -for consistent naming of algorithms in the future. The Python
> -``hashlib`` module is used as a reference since it is used
> -as the provider of hash functions for most of the Python software,
> -including Portage and PkgCore.
> +Since the effort needed to update the GLEP is small compared to the time
> +needed for a new hash algorithm to be well-deployed, the GLEP needs
> +to be updated prior to adding a new hash method.
>
> -The basic rules for changing hash algorithms are defined in GLEP 59
> -[#GLEP59]_. The implementations can focus only on those algorithms
> -that are actually used or planned on being used. It may be feasible
> -to devise a new GLEP that specifies the currently used hashes (or update
> -GLEP 59 accordingly).
> +The recommended naming is based off Python ``hashlib`` module,
> +as most of the Gentoo tooling is written in Python. The names
> +are transformed to match the historical naming used for hash functions
> +in Manifests.
> +
> +Implementations are allowed to support and use only a subset of hashes
> +listed in Manifest files. This could be used both to avoid the overhead
> +of computing multiple hashes on non-performant systems, and to handle
> +transition to new hashes gracefully.
>
>
> Manifest compression
> @@ -1072,27 +1110,29 @@ References
> .. [#FILE-NAMING-RULES] Ebuild File Format -- Gentoo Development Guide
> (https://devmanual.gentoo.org/ebuild-writing/file-format/#file-naming-rules)
>
> -.. [#MD5] RFC1321: The MD5 Message-Digest Algorithm
> - (https://www.ietf.org/rfc/rfc1321.txt)
> +.. [#RFC7693] RFC 7693: The BLAKE2 Cryptographic Hash and Message Authentication
> + Code (MAC)
> + (https://www.rfc-editor.org/rfc/rfc7693)
> +
> +.. [#RFC1321] RFC 1321: The MD5 Message-Digest Algorithm
> + (https://www.rfc-editor.org/rfc/rfc1321)
>
> -.. [#RIPEMD160] The hash function RIPEMD-160
> +.. [#RMD160] The hash function RIPEMD-160
> (https://homes.esat.kuleuven.be/~bosselae/ripemd160.html)
>
> .. [#SHS] FIPS PUB 180-4: Secure Hash Standard (SHS)
> (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf)
>
> -.. [#WHIRLPOOL] The WHIRLPOOL Hash Function
> - (http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html)
> -
> -.. [#BLAKE2] BLAKE2 -- fast secure hashing
> - (https://blake2.net/)
> -
> .. [#SHA3] FIPS PUB 202: SHA-3 Standard: Permutation-Based Hash
> and Extendable-Output Functions
> (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf)
>
> -.. [#STREEBOG] GOST R 34.11-2012: Streebog Hash Function
> - (https://www.streebog.net/)
> +.. [#RFC6986] RFC 6986: GOST R 34.11-2012: Hash Function
> + (https://www.rfc-editor.org/rfc/rfc6986)
> +
> +.. [#BARRETO] Paulo S. L. M. Barreto, The WHIRLPOOL Hash Function
> + (archived at 2017-11-29)
> + (https://web.archive.org/web/20171129084214/http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html)
>
> .. [#C08] Cappos, J et al. (2008). "Attacks on Package Managers"
> (https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html)
--
Best regards,
Michał Górny
next prev parent reply other threads:[~2022-09-14 20:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-12 13:38 [gentoo-dev] [PATCH v2 0/3] glep-0074: Explicitly specify hashes and compressed Manifest formats Michał Górny
2022-09-12 13:38 ` [gentoo-dev] [PATCH v2 1/3] glep-0074: Add a changelog Michał Górny
2022-09-12 13:38 ` [gentoo-dev] [PATCH v2 2/3] glep-0074: Specify supported hash algorithms Michał Górny
2022-09-14 20:50 ` Michał Górny [this message]
2022-09-12 13:38 ` [gentoo-dev] [PATCH v2 3/3] glep-0074: Specify compressed file formats Michał Górny
2022-09-18 18:31 ` [gentoo-dev] [PATCH v3 0/3] glep-0074: Explicitly specify hashes and compressed Manifest formats Michał Górny
2022-09-18 18:31 ` [gentoo-dev] [PATCH v3 1/3] glep-0074: Add a changelog Michał Górny
2022-09-18 18:31 ` [gentoo-dev] [PATCH v3 2/3] glep-0074: Specify supported hash algorithms Michał Górny
2022-09-18 18:31 ` [gentoo-dev] [PATCH v3 3/3] glep-0074: Specify compressed file formats Michał Górny
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1714c010d43fa2cfc31b8a88cb56be414c753d19.camel@gentoo.org \
--to=mgorny@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox