Clinic signatures of HACL* hash functions are inconsistent with OpenSSL implementation #134696
Comments
|
I cannot reproduce the issue. On Python 3.15, it works well and I don't think I change anything between 3.14 and 3.15 (namely I can use a keyword argument). If you cannot use a keyword argument on 3.12, then I think it's ok? I mean, the recent behavior is an extension of the old one. |
|
On |
|
3.12 is security-only so we won't fix this IMO (it's not a security issue). In your comment, you're linking 3.12.10 twice so I don't really understand which one is 3.12 or not (only the timestamps change and I don't know which correspond to what) |
|
Could you share how you're installing dependencies & building CPython on |
|
Reproducer: > docker run -it alpine:edge
> apk add python3
> python3 -c "import hashlib; print(hashlib.shake_128(b'').hexdigest(length=1))"However, in the meantime I figured if I run |
|
I may have an idea. What's the output of |
|
And indeed there is some issue here:
This is in |
hashlib.shake_128().hexdigest() no support for keyword arguments anymoreshake_{128,256}.hexdigest() is not inconsistent between OpenSSL and HACL* implementation
|
Here's the plan: I'll make it possible a keyword argument for 3.13 and 3.14 (sorry but 3.12 won't be fixed as I don't consider this as a true security issue; it just allows to distinguish between HACL* and OpenSSL implementations but I don't think it's worth a security backport). |
shake_{128,256}.hexdigest() is not inconsistent between OpenSSL and HACL* implementationshake_{128,256}.hexdigest() is inconsistent between OpenSSL and HACL* implementation
|
Ha... actually it's not just SHAKE that is affected... |
shake_{128,256}.hexdigest() is inconsistent between OpenSSL and HACL* implementation_sha3 are inconsistent with OpenSSL implementation
_sha3 are inconsistent with OpenSSL implementation_sha3 and _blake2 are inconsistent with OpenSSL implementation
|
Urgh, great, there is not one but two inconsistencies. In Or, we have Ideally, I want them to be positional-only. |
_sha3 and _blake2 are inconsistent with OpenSSL implementation…AC signatures (#134713) OpenSSL and HACL*-based hash functions constructors now support both `data` and `string` parameters. Previously these constructor functions inconsistently supported sometimes `data` and sometimes `string`, while the documentation expected `data` to be given in all cases.
…constructors AC signatures (pythonGH-134713) OpenSSL and HACL*-based hash functions constructors now support both `data` and `string` parameters. Previously these constructor functions inconsistently supported sometimes `data` and sometimes `string`, while the documentation expected `data` to be given in all cases. (cherry picked from commit c6e63d9) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
…constructors AC signatures (pythonGH-134713) OpenSSL and HACL*-based hash functions constructors now support both `data` and `string` parameters. Previously these constructor functions inconsistently supported sometimes `data` and sometimes `string`, while the documentation expected `data` to be given in all cases. (cherry picked from commit c6e63d9) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
…constructors AC signatures (pythonGH-134713) OpenSSL and HACL*-based hash functions constructors now support both `data` and `string` parameters. Previously these constructor functions inconsistently supported sometimes `data` and sometimes `string`, while the documentation expected `data` to be given in all cases. (cherry picked from commit c6e63d9) (cherry picked from commit 379d0bc) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
…constructors AC signatures (pythonGH-134713) OpenSSL and HACL*-based hash functions constructors now support both `data` and `string` parameters. Previously these constructor functions inconsistently supported sometimes `data` and sometimes `string`, while the documentation expected `data` to be given in all cases. (cherry picked from commit c6e63d9) (cherry picked from commit 379d0bc) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
…uctors AC signatures (GH-134713) (#134961) OpenSSL and HACL*-based hash functions constructors now support both `data` and `string` parameters. Previously these constructor functions inconsistently supported sometimes `data` and sometimes `string`, while the documentation expected `data` to be given in all cases. (cherry picked from commit c6e63d9) (cherry picked from commit 379d0bc)
…uctors AC signatures (GH-134713) (#134962) OpenSSL and HACL*-based hash functions constructors now support both `data` and `string` parameters. Previously these constructor functions inconsistently supported sometimes `data` and sometimes `string`, while the documentation expected `data` to be given in all cases. (cherry picked from commit c6e63d9) (cherry picked from commit 379d0bc)
Uh oh!
There was an error while loading. Please reload this page.
Bug description:
According to its docstring, the function
hashlib.shake_128(...).hexdigest()should accept an argumentlength, either as positional or as keyword argument. However, since Python3.14, the function only accepts positional arguments and fails withTypeError: shake_128.hexdigest() takes no keyword argumentsotherwise.I narrowed the root cause for this behaviour down to the following two commits (I'm not 100% sure though as I don't have any C-background):
Reproducer:
For example, on Python
Python 3.13.3 (main, Apr 8 2025, 13:54:08) [Clang 17.0.0 (clang-1700.0.13.3)]on my mac I can still use the keyword argument, but onalpine:edgePython 3.12.10 (main, May 21 2025, 16:23:36) [GCC 14.2.0] on linuxit is expecting positional arguments only.CPython versions tested on:
CPython main branch, 3.14, 3.13, 3.12
Operating systems tested on:
Linux, macOS
Linked PRs
hashlibFIPS-only BLAKE-2 buildbot #134968The text was updated successfully, but these errors were encountered: