Hi Ayoub, On 2026-09-18T17:21:23, Ayoub Zaki <[email protected]> wrote:
> ML-DSA requires SHAKE128 and SHAKE256. The series adds generic one-shot > and incremental SHAKE interfaces backed by Keccak-f[1600]. This code can > be used by consumers other than ML-DSA. The split needs some adjustment so that each patch builds and tests what it adds. See my comments on patches 1 and 3. > Feedback is welcome on the public API and Kconfig placement. For Kconfig, see my comment on patch 2. On the API, it is hard to judge without a caller. The cover letter already says FIT will need an incremental transcript over the signed regions, so the single-contiguous-message API will most likely change once FIT support lands. Since FIT is the main motivation, I suggest including at least a minimal FIT crypto_algo hook-up in the series, even as RFC. That would show the API works with the existing region-based verify() path and give us a real consumer to test in CI, not just unit tests. What do you think? On the mbedTLS discussion with Tom and Ilias: whichever backend we use, the public header should be independent of the implementation, so that a later move to mbedTLS / TF-PSA-Crypto does not affect callers. Please keep that in mind as you shape the API. You offered a MAINTAINERS entry in your reply to Tom. Please can you add one in v2 covering lib/crypto/sha3.c, lib/crypto/mldsa.c, the headers, the tests and the doc? That records who is responsible for tracking Linux upstream. Regards, Simon
