Originally posted by Vistaus
View Post
Way before we got Meltdown etc, the security specialists knew they needed to write constant-time code. You can't fail a user on first incorrect character in a password, but must evaluate every single character and then at the end decide if the user failed or not - else it's possible to figure out that the first three characters was ok - so just loop on fourth character...
Think about a situation where one path has the data available and can run in one clock cycle concurrently with one or more other instructions. While another path needs 10 or 100 clock cycles for the data to arrive. The speed difference is huge, which is a reason why it's possible to measure the difference. So how are you going to hide this difference, unless you make the processor pretend it always needs to wait?
In the end, we need a solution where you can slow-load all cryptographic material into a fixed RAM before you start processing so all of the data can be accessed at a fixed latency. And where you can turn on/off slow/secure mode for specific code blocks. And for some specific instructions, we need a dual-evaluation feature where the instruction always computes the true/false alternative. Then it's up to developers to write protected black boxes that performs the magic at constant time before handing back a result to the normal code.
That's basically the only way you can get your normal work to run at full speed with the best pipelines the chip manufacturers can design, while the threads basically takes a "stop-and-go penalty" whenever a secure operation needs to be handed over to a fixed-speed subprocessor.
Leave a comment: