Poor performance. 8.58 - 9.45 cpb #1
Comments
|
|
and another thing! you must've written some small amount of code to perform those benchmarks. why do i have to ask for this code? why not just open source everything by default? academia and much of the industry still does not understand open source. @james-darkfox did you use the criterion crate to perform these benchmarks or what? where's the code? |
|
(1) and (2) I may send in a PR, though I'm working on other things first. I did realize they're just bindings but the C has the option to split out the key expansion and can probably do in-place enc/decryption, even if it can't, the Rust interface exposed can take a second buffer for the output without forcing the allocation. (3) I do recognize that onion routers do not compare with mixnets with respect to global adversaries; I'm "fine" with discarding them from the threat model for a general purpose anonymity system. I do remain interested in mixnet work, especially anything based on Loopix with its bandwidth-latency balancing. Loopix is great for instant messaging and Email but not general IP traffic. HORNET is great for forwarding IP. (4) Hm. I recall the name but do not see any evidence on my system that I've discussed or experimented with it. I'll have to take a look into this one. I prefer HCTR because its simple construction is general, thus its components may be swapped out with minimal analysis. AEZ and Farfalle are specific functions, not general constructions. The performance numbers are impressive and may add enough value to consider them, but they can always be added later. I am publishing the code, thought I included the link, whoops. Locally I've hacked together a criterion My sphinx code is very early and HORNET code basically nonexistent. All will be published on GitLab/sio4. :-) Besides the custom Measurement, the benchmark entry for aez's encrypt is trivial. I'll remove the aez benchmark from my code as it isn't a fair comparison at least yet. I may re-add it when either of us remove the forced allocation and split out the key expansion. It just makes the graph too tall! // CyclesPerByte => https://github.com/bheisler/criterion.rs/pull/336
group.bench_function(BenchmarkId::new("aez-encrypt", size), |b| {
b.iter(|| aez::aez::encrypt(&[0u8; 48], &[0u8; 16], &buf))
});
group.bench_function(BenchmarkId::new("aez-decrypt", size), |b| {
b.iter(|| aez::aez::encrypt(&[0u8; 48], &[0u8; 16], &buf))
});
|
|
@david415 I'm using a Edit: Just in case you clicked that mis-link. /sio4/ on GitLAB not GitHUB. |
|
@james-darkfox thank you for your contributions! |
|
@david415 7-9 -> 0.7 cpb |
|
does this finding produce a nicer line on that graph? |
|
@david415 Uh.. Very. I didn't graph it but it would look very much like AES-CTR, as expected. But now I'm rewriting your bindings. :) |
|
And getting invalid memory accesses... somehow. o.0 Edit: Bah. Turns out it doesn't like a zero sized nonce. |
Hey. I'm (gradually) implementing Sphinx and HORNET. I'll be using HCTR as my SPRP because it builds on normal primitives (
BC = AES-128, AXU = POLYVAL), is simple and is sufficiently fast enough. I'm avoiding AEZ on the premise that its complex and intrusive design is unhealthy for implementations, but I decided to benchmark it as it was supposed to be quick and is an SPRP.Recommendations:
Split out the AES key expansion, it is slow and can be reused. This may not matter for your use case as Loopix uses distinct paths per packet; but it makes AEZ look horrible to Rust consumers who find this crate.
Encrypt/decrypt in place. Allocating is slow, especially if you want to handle high loads and are interested in AEZ for its high performance.
The text was updated successfully, but these errors were encountered: