The state of crypto in Python

Rust compiles to assembly you can review, not bytecode. It may be higher-level, but it isn't not low-level. Writing things in Python or other interpreted languages (and probably any language with a GC and no support for custom allocators as well) to avoid side-channel or timings attacks does make less sense though.

> First you talk about side channel attacks and compiler optimizations which might disable coded defenses. Then you recommend writing in higher level languages? What sense does that make?

There are actually two concerns at play here. Let me revert the order of my ramblings.

First, it is a fact that the large majority of incidents are due to the extensive usage of C in the implementation of security protocols. Writing secure C code is hard. Reviewing C code is even harder. It therefore makes sense to use as much as possible high-level languages, because you can benefit from all strict controls enforced by the language itself. You are also relieved from low-level tasks like memory management. Finally, you have fewer and more readable LOCs.

Second, though a numerical minority, side-channel attacks are still an important class that should not be overlooked. My claim though is that simply saying “I use C and therefore I am protected from side-channel attacks” is wrong (as it happens at 33:30 in the video). C is not such a fairy. It gives you a little more control on some types of information that may leak secrets (e.g. memory alignment) but you have to deal with optimization strategies that existing C compilers are capable of. BTW, the average C compiler is much more aggressive that your average bytecode compiler.

For instance, one very common timing attack concerns the comparison of two MAC tag as explained here http://emerose.com/timing-attacks-explained .

A piece of C code that handles comparison in a somewhat time-independent way is:

#define TRUE 1
#define FALSE 0

int util_cmp_const(const void * a, const void *b, const size_t size)
{
const unsigned char *_a = (const unsigned char *) a;
const unsigned char *_b = (const unsigned char *) b;
unsigned char result = 0;
size_t i;

for (i = 0; i < size; i++) {
result |= _a[i] ^ _b[i];
}

return (result ? FALSE : TRUE);
}

Is that secure? Most probably, but you cannot exclude that some compiler will still outsmart you by leaving the loop as soon as the variable “result” becomes non-zero, because it sees you are only using it as condition in the ternary operator. On the other hand, the same logic can be implemented in Ruby or Java or Python too and it will be no more or less secure (see also moment 36:00 in the video, where the fact that C has short circuits too is totally neglected).

Will assembly be more secure for that? Mosty probably, but still you cannot be sure 100% without measuring for real because most CPU instructions are not executed in fixed time (it is not 1990 anymore). Even after measuring, you will not be sure that different CPU architectures will behave in the same way.

Bottom line, I just think that:
1) A security stack should be implemented in a high-level language to the greatest possible extent (e.g. X.509 parsing. It is insane to do it it C) unless performance really bites you, in which case you can fall back to C.
2) You should be very very very wary of claiming that your implementation is robust against side-channel attacks, no matter which language you use (Ruby, C, Rust, and even assembly).