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:
* Take out the nonce from struct poly1305_ctx, and let poly1305_aes do all nonce handling. poly1305_digest gets the encrypted nonce as argument.
* For poly1305_aes, use aes128_ctx (it's hard coded for 128-bit AES anyway), and perhaps rename it to poly1305_aes128.
* Introduce a poly1305_update function, and use preprocessor casting tricks to define poly1305_aes128_update (and any other poly1305_*_update) as an alias.
* 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.
or when might that happen?
Not sure, I'd need a day or so of hacking time to finish the above.
I have to admit that I haven't studied how UMAC and Poly1305 uses (in what phase) the block cipher. Would they gain any substantial performance if they could use AES-NI when available?
Improving aes performance would sure be generally good, but it doesn't matter much for umac and poly1305. umac uses aes to generate its subkeys (which can be a fair amount of data), and both use aes to encrypt the nonce. But the heavy mangling of the message bytes doesn't depend on aes.
Regards, /Niels