Code for the papers, split into AES, HAWK, and LEA attacks, because one cryptanalysis demo apparently wasn't enough.
4 comments
The AES part makes me think of Bernstein 2005 more than anything else, since a lot of these code bundles are really just the papers appendix in executable form. HAWK and LEA in the same artifact repo is a bit of a grab bag, though.
What are the success rates and GPU baselines against the papers reference implementations?
gpu baselines don't tell you much if the reference code is unoptimized.
> gpu baselines don't tell you much if the reference code is unoptimized.
I had the same argument when we shipped a CUDA MSM path for an internal prover, because the first CPU reference was a pretty sad scalar loop and the GPU looked absurdly good until we fixed the obvious cache trashing on the host side. After that, the gap collapsed into something much more boring, and the real limiter turned out to be how many point coordinates we could keep fed from device memory, not the multiply-add rate. I still remember one run where occupancy looked fine on paper, then Nsight showed the SMs waiting on loads like it was a networking bug.
So yes, a bad reference can make the headline number useless, but a GPU number can also hide the opposite problem, where the paper code is already memory-bound and the accelerator just changes which pipe is clogged. For these demo repos I end up wanting three numbers on the same machine, the paper code as-is, a cleaned-up CPU build, and a GPU build with the same field arithmetic, otherwise the comparison gets weird fast.