core/crypto: More improvements #4124
Conversation
Yawning
force-pushed
the
feature/crypto
branch
9 times, most recently
from
8450ddd to
26fb0a1
Compare
Yawning
force-pushed
the
feature/crypto
branch
6 times, most recently
from
b6f512d to
363df33
Compare
Yawning
force-pushed
the
feature/crypto
branch
3 times, most recently
from
4198575 to
f69bb60
Compare
Yawning
force-pushed
the
feature/crypto
branch
7 times, most recently
from
7d37012 to
00e013b
Compare
Yawning
force-pushed
the
feature/crypto
branch
4 times, most recently
from
6f62ca6 to
e8dc9bc
Compare
Yawning
force-pushed
the
feature/crypto
branch
from
e8dc9bc to
0dedf4a
Compare
| st.rate = _RATE_128L | ||
|
|
||
| for _ in 0 ..< 10 { | ||
| update_hw_128l(st, iv, key) |
There was a problem hiding this comment.
For a bit of performance improvement: since the input is constant, and we don't need to compute a key stream here, the state can be kept in bitsliced form during the initialization rounds. Same for finalization.
In bitsliced form, the rotation of the AES blocks is just a one-bit shift of the bytes.
During AD absorption, you can also keep the state in bitsliced form, and only bitslice the input blocks.
Also for the sbox, there are faster circuits than the Boyar-Peralta: https://eprint.iacr.org/2019/802.pdf
There was a problem hiding this comment.
Sorry for the delay in replying to this. I will leave adding those optimizations for a future pass, since my time has been somewhat limited as of late, and what is there is easy to review and gets adequate performance.
Yawning
force-pushed
the
feature/crypto
branch
from
384c6c2 to
3a90ce7
Compare
Yawning
force-pushed
the
feature/crypto
branch
from
585dd35 to
5d30bd5
Compare
Yawning
force-pushed
the
feature/crypto
branch
2 times, most recently
from
567e5f8 to
8da0ae1
Compare
| @@ -235,7 +235,7 @@ gctr_hw :: proc( | |||
| // BUG: Sticking this in gctr_hw (like the other implementations) crashes | |||
| // the compiler. | |||
| // | |||
| // src/check_expr.cpp(7892): Assertion Failure: `c->curr_proc_decl->entity` | |||
| // src/check_expr.cpp(8104): Assertion Failure: `c->curr_proc_decl->entity` | |||
There was a problem hiding this comment.
prob good idea to make an issue with steps to reproduce so this can get fixed
To be honest it probably doesn't matter either way. A lot of the crypto code was contextless when I started working on it, and it is exceedingly rare that anything except panic/ensure needs the context. Going from "with context" to "without context" is easier than the reverse in terms of not breaking code that calls the routines, so my inclination is to continue the trend. |
Definitely, but then the panics and ensures can't be overwritten, so it's a bit of a balance act. I'm fine with it though, just wanted to know the reasoning, I am glad it isn't performance. |
- Detect the RISC-V `v` profile - Don't bother trying to process 4 blocks at a time if emulated
- Use text/table for results - Add more benchmarks
Refactor the blake2 code to use SIMD?(Kind of not worth it with just SSE2)ensureto enforce API contractsArgon2(Delayed to next patch series)ChaCha8Rng(Delayed to next patch series)