IO-like interface for SHAKE-* and other XOFs.

[dannyniu]

BPO	38017
Nosy	@dannyniu

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2019-09-03.12:48:26.011>
labels = ['type-feature', 'library']
title = 'IO-like interface for SHAKE-* and other XOFs.'
updated_at = <Date 2019-09-03.12:48:26.011>
user = 'https://github.com/dannyniu'

bugs.python.org fields:

activity = <Date 2019-09-03.12:48:26.011>
actor = 'dannyniu'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2019-09-03.12:48:26.011>
creator = 'dannyniu'
dependencies = []
files = []
hgrepos = []
issue_num = 38017
keywords = []
message_count = 1.0
messages = ['351084']
nosy_count = 1.0
nosy_names = ['dannyniu']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue38017'
versions = []

[dannyniu]

The SHAKE family functions are the first formally defined XOFs (eXtensible Output Functions), previous implementations such as MGF from PKCS#1 relies on ad-hoc construction.

In the current library, SHAKE-* are given digest-like interface, where their output has to be always obtained from the start; where as in reality, there exists applications that consumes such output progressively, such as deterministic key generation from fixed seed, and more specifically, as the random oracle used in Crystals-Dilithium post-quantum digital signature scheme.

Therefore, I'd like developers consider adding ``shake.read(len)'' function to support IO-like consumption in hashlib.

[gpshead]

An API of this nature would make more sense to offer in a PyPI SHAKE specific package before we consider if such an API makes sense in the standard library. We want hashlib to focus on the most common very widely used standard things.

[tomato42]

@gpshead any chance of having this re-evaluated? XOFs will be used in ML-KEM, it's hard for more standard use than that...

and while yes, you shouldn't use ML-KEM (kyber) implementation written in Python for production workloads, Python is the perfect language to teach how algorithms like that work

[gpshead]

This kind of development and maintenance is still best done in third party packages on PyPI.
For others reference, ML-KEM appears to be Module Lattice based Key Encapsulation Mechanism laid out in the FIPS 203 draft https://csrc.nist.gov/pubs/fips/203/ipd

[tomato42]

the problem is the effect of that on other implementations, like pypy; if it's part of core hashlib, then it needs to be provided by other runtimes, if it's a pypi package, then it may work on some random platform or it may not

[gpshead]

https://pypi.org/project/cryptography/ works on PyPy and is a more natural fit for this kind of thing today.

[tomato42]

just because it runs on PyPy doesn't mean it runs on all alternative runtimes, and just because pyca/cryptography provides the API doesn't mean that

1. I can compile/run that binary package it in the first place
2. it actually compiles on some obscure architecture

you may not like it, but XOFs are part of the hash ecosystem now