Just one point about testable assembly: I like the Golang guidelines which require to write a Go version before implementing the same in assembly. That way there is a baseline to compare with in terms of correctness and performance. Also the Go project has recently introduced mutation testing and test coverage on assembly code which is very interesting.
Finally about detecting at runtime the presence of simd: I am confused why a third-party dependency or even the std is needed. At least on x64, it’s just one instruction (“cpuid”) and then checking if a bit is set, right?
ayende · 2h ago
One thing that is ignored here is that for crypto, there are additional concerns
For example, are the instructions cost depend on the data? If so, you have a timing leak and a hole in your system
One of the reasons to use assembly is specifically to avoid timing dependency and the compiler being "smart" about things and thus leading to timing attacks
Just one point about testable assembly: I like the Golang guidelines which require to write a Go version before implementing the same in assembly. That way there is a baseline to compare with in terms of correctness and performance. Also the Go project has recently introduced mutation testing and test coverage on assembly code which is very interesting.
Finally about detecting at runtime the presence of simd: I am confused why a third-party dependency or even the std is needed. At least on x64, it’s just one instruction (“cpuid”) and then checking if a bit is set, right?
For example, are the instructions cost depend on the data? If so, you have a timing leak and a hole in your system
One of the reasons to use assembly is specifically to avoid timing dependency and the compiler being "smart" about things and thus leading to timing attacks