added HCTR #55
added HCTR #55
Conversation
|
Thank you! I am not familiar with this construct, so I will have to read about it first to review your PR.
We probably should add marker trait(s) to describe those properties to the
Because |
|
You're welcome and thank you for the quick response. I've been waiting for @tarcieri's polyval, which is complete and fills the needed AXU slot. HCTR as an SPRP is an MRAE when padded with zeros, otherwise length preserving. I'll be using it as my general MRAE, starting with a HORNET implementation. Is there anything blocking the ctr crate from doing the same? I'm using the ctr crate at least because it is easier to reuse the same aes128 post-keying state over both the flat PRP and the CTR components to HCTR. Aesni's Aes128Ctr takes a key and not an already instantiated Aes128. Adding that from_cipher fn would probably be sufficient, but then it'd be even more aes-specialized but I'd rather the HCTR impl be generic, not hardcoded. |
|
Regarding the CI failure. Just missing flags for this test. Should the crate use cfg-targets to automatically select the aes and polyval features? |
Using the same approach may degrade performance for ciphers which do not use XMM registers for blocks processing and keep data in general purpose registers. Although it may be that bad, since those ciphers are probably will not be performant enough to begin with for several additional cycles to be noticeable (especially if users will enable SSE4.1 which has
For now I think you can simply disable benchmarks if the required target features are not enabled. |
|
@newpavlov The blockcipher trait could have an associated boolean constant, defaulting to false. Disabling only the benchmark wouldn't be sufficient as the whole library needs to be built (or disabled). I have generalized it over BlockCipher, but until polyval implements the universal-hash trait; I can't have the library even build a generic implementation without adding polyval's insecure-soft feature, which could be a "default" but I really do not want to enable an insecure default. |
|
Polyval's software implementation should be constant time eventually. This PR can block on the const-time polyval. |
|
It’s already constant time. I just need to do another release. But first I wanted to add runtime feature detection. |
Not quite ready for publishing. * [ ] Should be generic over the block cipher and AXU universal hash function. * [ ] Documentation... Not all AXU universal hash functions are valid; there are at least two additional properties that must hold. * [ ] Is anything else missing? * [ ] Publish to crates.io under RustCrypto Why is Aes + ctr about half the performance of aesni w\ the ctr feature? Please confirm this crate belongs here. HCTR is an SPRP but it builds on a block cipher and an AXU universal hash function, it is a construction or cipher family; not a cipher itself.
|
@newpavlov The CI failure is in The second commit generalizes over BlockCipher and UniversalHash. The API is marked as unstable until we have a TweakableBlockCipher trait. Once @tarcieri 's polyval PR is accepted, I'll patch the |
|
@tarcieri published polyval 0.1.0 which uses the |
|
@newpavlov Re ctr performance. I've started a |
|
Interleaving the second AXU with CTR doesn't appear to improve performance. Interleaving two AXU passes (for sphinx) benefits both small and large messages. Interleaving all three yields worse performance than just interleaving the hashes. For the Sphinx client use case, the benefit is to interleave the AXUs across instances.
Disclaimer: Besides having >90% of my CPU available for the benchmarks the cpu frequency was unstable - I was re-running the benches until they were all consistently at 2500MHz. Future benchmarks may be more consistently measured at a much lower 790MHz. Do either of you have any benchmarking tips? Better ways to measure cpb? Edit: I've added cpb to criterion, though more stable it still shows noise. |
…to aid layered use cases.
|
|
|
@newpavlov Last commit makes this free of git dependencies. All depends are on crates.io. Just waiting on your review. |
|
@WildCryptoFox can you please rebase this? thank you! |
|
@tarcieri I can do this, yes. However I'm still not sure if HCTR belongs in "block ciphers" or "aeads". It is a construction a la SIV but not restricted to AES or POLYVAL. They're merely recommended choices. A block cipher and AXU* like POLYVAL in; wide SPRP out. Padding alone implies an MRAE. I can adjust the implementation to use the AEAD traits and keep the layering specialization separate. * The AXU must also meet two properties defined in the paper for the security proofs (Section 3.3.) Edit: |
|
Yes, I'd suggest reopening this PR in the AEADs repo. It sounds like you'd want to have several generic parameters including cipher and tag size. Several of the AEAD ciphers already do this, as it were. See AesGcm as an example (which supports a generic nonce size). |
Not quite ready for publishing.Ready for review!Generic over the block cipher and AXU universal hash function.
Documentation.
Review.
Publish to crates.io under RustCrypto
Because the latter benefits from XMM registers for the counter, while the former is more general and not currently checking if it can use XMM registers to boost aes in this case.