Daiki Ueno ueno@gnu.org writes:
Sorry for the delay, and thank you for merging it to master. I've come up with the attached 3 patches on top of it, which basically do:
Thanks for moving this forward. I haven't had time to share my recent patches either. I have a few concerns, though.
- Apply my changes in the previous post to count index from zero, not the end of the block
I'm not yet convinced this is a net win, it looks like you need a "% sizeof (ctx->block)" to make that work, and I'd like to avoid divisions, in particular, since when general generalizing this to also support shake128, the divisor will no longer be constant.
- Rename sha3_256_shake_output to sha3_shake256_output and add sha3_shake256_init/update as well, as you suggested in the previous conversation. That would help us implement SHAKE128 without exposing SHA3-128 digest functions and I find it easier to read when used in the ML-KEM implementation.
I'm fine with adding new sha3_shake256_* names, but I think we should keep old name (which you added for Nettle-3.6). And I think we can use the same context struct, possibly with convenience aliases like
#define sha3_shake256_ctx sha3_256_ctx #define sha3_shake256_init sha3_256_init
I agree we shouldn't define sha3_128_digest now (as far as I'm aware, there's no authoritative spec for that), but I think we should design the api so that it fits if added later.
I'm a bit confused by the choice of shake128 for ML-KEM, and I would expect that if there are applications where shake128 is a reasonable security tradeoff, then there likely are reasonable applications of sha3_128 too. I don't understand the fine details of sha3 security analysis, but I'd guess that for applications where second preimage (in contrast to arbitrary collisions) is the relevant attack, sha3_128 should be as secure as sha3_shake128 with a larger output size.
- Generalize _shake_output function independent of the underlying SHA-3 algorithm.
Certainly needed.
I don't think the all-in-one shake function should be deprecated, it seems like a nice utility. What I'm not sur about about is if it should be implemented as _output + _init (very cheap implementation) or its own function (with less runtime overhead than _output).
I'll try to clean up and post or commit some of my changes, I'm sorry that will cause some conflicts.
Regards, /Niels