nisse@lysator.liu.se (Niels Möller) writes:
Joachim Strömbergson joachim@secworks.se writes:
What is the status of Poly1305 in Nettle, i.e. is the branch ready to be merged into master
There are a couple of things I'd like to do. Quoting a mail from 21/11:
I've done most of this now, and merged into the master branch.
- Take out the nonce from struct poly1305_ctx, and let poly1305_aes do all nonce handling. poly1305_digest gets the encrypted nonce as argument.
Done.
- For poly1305_aes, use aes128_ctx (it's hard coded for 128-bit AES anyway), and perhaps rename it to poly1305_aes128.
Done.
- Introduce a poly1305_update function, and use preprocessor casting tricks to define poly1305_aes128_update (and any other poly1305_*_update) as an alias.
Done, then undone; I don't think we need this generality now. The code is now organized so that struct poly1305_ctx and related functions only hold the state related to polynomial arithmetic (and where implementation details for an optimized implementation are machine-specific).
While struct poly1305_aes_ctx holds the block buffer, the nonce, and the corresponding functions take care of buffering, final padding, and handling of the nonce.
- Promote union gcm_block to a more general abstraction, renaming it to nettle_block16 or so, and use it to guarantee nicer alignment for block buffer and nonce in poly1305.
Done, but in poly1305 only used for the encrypted nonce argument for poly1305_digest. For nonce and block, they'll be aligned anyway, and I see no C code which can take any advantage of word access (except possibly incrementing the nonce, but that's very marginal).
If you or anyone else can test this on macosx and windows, that would be nice. The x86_64 assembly is intended to work there too, but not tested.
Some numbers:
On my lowend home machine (AMD E-350), benchmarking gives 11 cycles/byte for the C implementation. And 3 cycles/byte with the x86_64 assembly, slightly faster than umac64.
The current source code is 220 lines of C code and 99 lines assembly (excluding comments and empty lines).
Regards, /Niels