Simon Josefsson <[email protected]> writes: > No objection, but I find it challenging to come up with a revised patch > that I feel comfortable with in the near future. I'm not sure I even > understood what unused functions you noticed (and how?); that fix would > be easy to do. Gaining confidence in rewritten parts feels a bit more > complicated. Would you like to revise the code?
I may be able to try it out in the next few weeks. If I just check out your branch, do tests work out of the box or do I need to somehow patch in the DRBG-CTR-AES256 too? There are some style details in the current patch that bothers me a bit, e.g., "q" used as a regular parameter/variable in most of the code, and then defined as a macro further down. #define q 4591 should be changed to something like #define SNTRUP761_Q 4591 (or maybe just SNTRUP_Q if it is intended to parametrize the code). > Aligned API/ABI's are nice, and good to get right early. Is > 'nettle_block16' still the right way to do this, or is this possible to > (with arguably more readable) aligned() or alignof() attributes? I think nettle_block16 is the way to go, for representing 16 byte blocks where we're in control of the alignment (in contrast, e.g, to user's plaintext/cryptotext for which we don't require any alignment). I'd like to use alignas, and make nettle_block16 16-byte aligned at least on x86_64 (and on other archs where assembly code can benefit from alignment larger than that of an uint64). But aligned is C11, and I hesitate to require that (while I'm considering requiring C99). And since this is in public header files and part of the abi, it doesn't make sense with compiler specific ifdefs. 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]
