[Someone1234]

You say it's "false" but then fail to explain why. None of your examples offer that, and your whole explanation boils down to "managed languages are more complex, therefore worse."

Please point me to the specific native features which mitigate timing attacks. Because the majority of fixes I have seen are purely in altering the libraries themselves using high level constructs to remove hot paths and make it so both failure and success state take a constant time to execute (which has nothing to do with managed/unmanaged code).

[tptacek]

The issue isn't that native code has special features that mitigate timing attacks. It's that you can look at native code and predict its side effects more easily than you can with high-level code.

Another important difference between native code and high-level code is that timing leaks in high-level code tend to be larger. For instance, it's very difficult to exploit a memcmp timing leak in practice. But Java's string comparison, depending on your JVM, is exploitable over the Internet.

For what it's worth: I wouldn't select C over Java simply to avoid timing attacks. Side channels in JVM code are a legit concern, but not a dispositive one.

[xnull]

> whole explanation boils down to "managed languages are more complex, therefore worse."

I hope that's not what I said...

> Please point me to the specific native features which mitigate timing attacks.

How am I supposed to implement bitslicing to vectorize operations in Java? I can't. Fine grained control of code is important for implementations of ciphers that are both fast and side-channel free. Fine grained control isn't something Java can give you, by definition.

Take the 'countermeasures' section of 'Efficient Cache Attacks on AES, and Countermeasures' (http://www.cs.tau.ac.il/~tromer/papers/cache-joc-20090619.pd...).

I count exactly two countermeasures that apply to high level languages. Of the first they say "We conclude that overall, this approach (by itself) is of very limited value" and of the second "beside the practical difficulties in implementing this, it means that all encryptions have to be as slow as the worst case... neither of these provide protection against prime+probe/etc".

The rest of the countermeasures suggest bitslicing, use of direct calls to hardware instructions, memory alignment tricks, invocation of hardware modes (i.e. to disable caching), forcing cache ejections, normalizing cache states on interrupt processing, etc.

It is purely the case that high level languages do not offer you the flexibility and control to implement side-channel free crypto.

Crypto is brittle. High level languages are awesome for so many things. But bitslicing isn't one of them. The entire premise of high level languages is that you are freed from working directly on the innards pertinent to the specific target architecture. The entire premise of side-channel free crypto is that you need visibility and control of exactly these things.

[pjmlp]

> How am I supposed to implement bitslicing to vectorize operations in Java?

By using unsafe (not ideal), the GPGPU bindings like Aparavi/JCuda or the future GPGPU API?

Honest question. Wondering about the possibilities.

> It is purely the case that high level languages do not offer you the flexibility and control to implement side-channel free crypto.

I would say Ada is an high level language that offers C and C++ flexibility, while being safe.

[xnull]

The overall question is whether bindings or language features that expose direct control of the underlying architecture (such as D) can still be used to implement crypto. The answer is likely yes, though it is uncharted territory that only someone who knows what they are doing should attempt.

[pjmlp]

Sure I don't have any experience with crypto algorithms to have a proper opinion.