[dmm]

Another good reason to write crypto in assembly is to ensure that the implementation is not susceptible to timing attacks. If your code has different code paths that take different amounts of clock time attackers can use that. This can be difficult to achieve in a high level language.

[xxs]

Using assembly won't preclude timing attacks vulnerability, esp on x64. Nowadays beating even the C compiler performance wise is exceeding difficult with hand written assembly.

[pix64]

The point isn't to be faster, it is to be consistent.

[xxs]

That's what I mean actually getting it consistent is hard as the performance is really hard to predict and may change even with CPU stepping. Even then it requires very solid planning as well.

[lawl]

I think you misunderstand timing sidechannels. The idea is that (for example) if you compare two strings with length 15 you compare all 15 chars regardless if you find that the 3th char is already different.

You only need to be consistent with yourself. Stepping is completely irrelevant here.

[nitrogen]

An instruction that is constant time in one CPU may vary its time based on input in the next version of the CPU. That could still provide a timing channel in your example of a comparison if the comparison instruction finishes faster if, say, the left most bit is a mismatch.

[xxs]

>I think you misunderstand timing sidechannels.

I don't :) Basically you want all the code branches to result in similar (same) timings. Basic on the CPU and the data inputs those timing would vary, hence assembly alone won't do.