[hinkley]

In MD5, there are calculations that if they result in certain data ranges in certain bytes, results in a secondary calculation to spread that change into other bytes. Like a non Euclidean carry operation.

So I would think if you treat all of the bytes as one SIMD instruction, do a SIMD compare, and then fire another operation as a result… if you could guarantee that the third operation would have to fire for at least one of the vector values every time, then I think you’d have your solution.

[nayuki]

I am familiar with the low-level arithmetic in MD5 (e.g. https://www.nayuki.io/res/cryptographic-primitives-in-plain-... ). Exactly which calculations are you pointing to that result in a secondary calculation?

[hinkley]

Hmm. I could have sworn the rotation had a component of the calculation in it, but you're right it's just the loop counter. SHA-1 and AES also vary by the round, but none of SHA-2, DES, or MD-4 have either round nor state variance, so if I'm misremembering a different algorithm it's pretty obscure. False memory I guess.

[nayuki]

For the 5 algorithms you mentioned, I know them well.

> SHA-1 and AES also vary by the round

Vary what by the round? SHA-1 ( https://www.nayuki.io/res/cryptographic-primitives-in-plain-... ) is structured very similarly to MD5, with one big difference being that SHA-1 doesn't vary the rotation by the round number. AES has a public sequence of round constants that gets applied to the key expansion, but otherwise doesn't do anything special to the ciphertext per round.

The logic that can cause timing issues include using a memory lookup table for the S-box and finite field multiplication in AES, as well data-dependent rotations in rare ciphers like https://en.wikipedia.org/wiki/RC5 and RC6.

[hinkley]

The tables have always made people nervous anyway. And the compromised EC entry just sealed the deal. How do we know they aren’t chosen by the NSA for mischief, even now that they should know better that someone else will figure out their trick too?