Daiki Ueno <[email protected]> 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 -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
