Add poly1305 crate (derived from rust-crypto) #12
Conversation
This is a verbatim import of rust-crypto's poly1305.rs: https://github.com/DaGenix/rust-crypto/blob/9a4d8f279b643b8ae006e442141571fc7a85a3cf/src/poly1305.rs Last commit by Palmer Cox on October 17th, 2015. Commit message: > Resolve warnings from Rust nightly about unecessary parens in for statements
Runs rustfmt on the original rust-crypto sources
This adds basic crate boilerplate similar to the other RustCrypto/MAC crates, and also adapts the source code to use the `crypto_mac::Mac` trait rather than the `rust-crypto` one. Additionally, it moves the existing Poly1305 tests into the `tests/` directory, and uses the standard RustCrypto/MACs `bench!` mcaro. Tests now pass and performance looks reasonable.
Nothing too interesting here, however it seems the original `rust-crypto` code had a lot of (apparently) unnecessary masking which I assume it inherited from the original C code.
|
That's mostly to make it a straightforward translation of the original Perhaps for now it'd be better if the crate had a feature to do Poly1305-AES with the My main interest here is ChaCha20Poly1305 AEAD, so I don't necessarily need Poly1305-AES, but depending on how we handle generic composition it feels like we need some traits to assemble AEADs which use universal hash functions as MACs. This is something we'll have to solve for AES-GCM(-SIV) as well. |
|
Here's the code in godbolt. I didn't see anything obviously non-constant time in a quick pass through the generated assembly with |
|
@newpavlov well, I've fixed all of my own nits with this and would say it's ready for review. I ended up removing the |
As a universal hash function and one-time authenticator, Poly1305 doesn't meet normal expectations of a MAC. This change removes the `Mac` impl, but otherwise leaves the API looking very much like a `Mac`. Additionally, this commit includes a lot of refactoring in an attempt to clean up the code somewhat.
|
Updated godbolt here: https://godbolt.org/z/V9zoPr |
In either case it won't be necessary on Rust 1.32+ as we can use `u32::from_le_bytes`/`to_le_bytes`, but for now `byteorder` is the more common solution.
|
@newpavlov can you give me access to the |
|
@tarcieri |
|
@newpavlov thanks! I'd like to circle back at some point and add SIMD support, but this seems like a start |
This PR adds an initial
poly1305crate based on therust-cryptoimplementation of Poly1305 (which in turn is a translation of poly1305-donna):https://github.com/DaGenix/rust-crypto/blob/9a4d8f279b643b8ae006e442141571fc7a85a3cf/src/poly1305.rs
I've done the minimal work to adapt it to
crypto_mac::Macand generally fact it more like the rest ofRustCrypto/MACs.Performance is good enough for my purposes, but could be better w\ SIMD acceleration. Benchmark using the
crypto-maccrate'sbench!macro on a 3.1 GHz Intel Core i7:I will throw the code into Godbolt so we can do some inspection of whether or not the implementation appears to be constant-time on select platforms.