benwr / bromberg_sl2 Goto Github PK

Right now there's a whole tree of const and non-const fns, because at one point I was trying to use some non-const stuff inside add() or something. But it turns out that was slower than just using the const version. So now there's a bunch of duplicated stuff where it's not necessary. I think the only things that do need to be split are mod_p and matmul.

I think the current API is kind of gross; probably a lot simpler to just have a fn hash(&[u8]) -> HashMatrix

Not sure how difficult this is to do as an afterthought, though my guess is that it isn't too hard.

I've always wanted to use AFL to find bugs; maybe it will be helpful for this

Right now we have a lookup table where we store the hash matrix for each byte. We could also store a hash matrix for each byte pair, which might ~double throughput (at best; in practice you'll have a lot more cache misses). The downside is that you'd need to store 2^16 * 2^6 bytes = 2^20 * 2^2 bytes = 4 MiB. This is just small enough to fit in L3, so the cache miss rate might not be so so bad. My guess is that it's worth attempting and benchmarking.

Another downside is that we want to use this library in a web context, and 4MiB is a lot of weight to add to your binary. You could have two different compilation modes, one with the table calculated on startup (or using a smaller table) and one with the table built in, for cases like this.

e.g. ensure we're following all possible security best practices and rust ecosystem best practices.

I don't think we use anything that should preclude no_std support, though I could be wrong. My impression is that it's good practice to provide no_std whenever possible.

My U256 code is the first thing I thought of doing. i.e. It uses the elementary school multiplication algorithm. Which probably means that it's nowhere near as fast as it could be. Maybe I should look for someone else's implementation.

It would be useful to know how fast this is compared to other hash implementations.

Right now there are some branches in the modular arithmetic; these give us ~2x speedup I think, but IIUC in general it's bad to have variable running times in crypto libraries. Probably should just kill that stuff.

If I wanted to be super careful about this I would probably also kill the 2-byte storage table? I don't really know. There are two potential problems with it:

1. Two different tables (2-byte and 1-byte) might make the running time more dependent on parity than it should be. I think this is basically a non-problem, though, because the running time is unavoidably going to vary with the input length.
2. Bigger tables have more cache misses, and that means more inferable state. I don't know how much this matters in practice but I'd guess it's not totally trivial for legit crypto libraries.

Sadly if I do both of these things I'll wipe out lots and lots of performance gains, which I actually do care about pretty significantly. My current state is something like "just, like, don't use this to hash data that's supposed to be secret, I guess?"

I'm not really sure how this should work, but I want some kind of guarantee that the implementation here is actually producing hashes that are random-looking for large-enough inputs. I think maybe some simple statistical checks would help?

https://docs.rs/digest/0.9.0/digest/trait.Digest.html

I really need such a hashing function in my project.
Is this safe to use? Can I help somehow in order to make it safe?

Compare my results here with results acquired via bignum libraries.