LWN: Comments on "The state of crypto in Python"

The state of crypto in Python

raven667 — Thu, 17 Jul 2014 17:35:46 +0000

The synthesis of all this seems to be that are too many abstraction layers fighting against you to make any guarantees when it comes to side channels, you will never know enough about the system to reliably engineer around them all. You can do your best to make the attacker work hard, but no iron-clad guarantees.

The state of crypto in Python

zimmerfrei — Thu, 17 Jul 2014 17:23:57 +0000

> 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).

The state of crypto in Python

mathstuf — Tue, 15 Jul 2014 19:23:56 +0000

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.

The state of crypto in Python

zlynx — Tue, 15 Jul 2014 18:09:58 +0000

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?

What I gather from the information you provided is that we should be writing security critical code in assembly.

The state of crypto in Python

zimmerfrei — Tue, 15 Jul 2014 17:06:45 +0000

> One area where that makes a big difference is in avoiding timing attacks, which requires operations that take constant time (and, ideally, constant power). The code in those C libraries is generally good and has been well-reviewed

The idea that a C library is inherently more robust w.r.t timing attacks is flawed and probably gives a false self-sense of security. You still depend a lot on the behaviour of the compiler (e.g. the optimizations it does), the C library, the OS (e.g. thread interactions), and the underlying hardware architecture (e.g. cache, etc). Those are all factors beyond the reach of the library developer.

Besides that, I am not aware of any evidence that common FOSS C libraries (e.g. openssl, polarssl) have really been *fully* vetted as being robust against side-channel attacks. Openssl and gcrypt have passed the FIPS certifications, but that says nothing. Most libraries do have countermeasures, but typically only for the most elementary attacks (for instance, I see very little against fault attacks), and in most cases there is nothing stopping you from implementing them in higher-level languages too.

Finally, I think it is about time the FOSS community realizes that C is not anymore suitable for writing system security infrastructure: it is really hard to write good C code and it is even more difficult to manually review it. We should move as much as possible of the implementations to high-level languages that are easier to review and test *and* that incorporate mechanisms against the most common security bugs (e.g. buffer overflows). Python in this case, although Rust would be by far my preference right now.

The state of crypto in Python

mirabilos — Fri, 09 May 2014 13:28:04 +0000

The slides HTTP 503 at the moment, though.

The state of crypto in Python

jraim — Thu, 08 May 2014 19:58:07 +0000

Many of the C backends that cryptography uses are capable of using hardware acceleration, OpenSSL among them. Assuming the library is compiled correctly, those features should just be used.

As to HSMs, those can be used through PKCS interfaces (something we need anyway for NSS support), so those should be usable as well.

The state of crypto in Python

jraim — Thu, 08 May 2014 19:56:36 +0000

Thanks for the data! Sorry we missed that one. I updated our slides so we get it right in the future.

It is important to note that we aren't building another primitives library, the cryptography project uses the existing primitive libraries to fulfill requests, we are only developing a common, python front-end for those libraries.

The state of crypto in Python

Baylink — Mon, 05 May 2014 16:31:15 +0000

> The biggest problem may be that they do not offer a "non-foot-gun" interface, so there is no easy way for those not steeped in cryptography and the underlying library to use them without risking a serious security hole in their code.

Um... Is it not the case that you *cannot* safely implement crypto in an app without a fairly deep understanding of how that crypto works?

Cause that'd be my bet...

The state of crypto in Python

dlang — Sun, 04 May 2014 05:45:12 +0000

One factor I didn't see mentioned here is the ability to make use of hardware cryto modules if they are available.

some CPUs include AES in hardware (close to memory bandwith AES processing), and there are a bunch of different pubic key crypto accelerator cards and devices out there (some with FIPS certification for those that need it). I've seen SCSI attached, internal cards, and network devices

how do these different software options stack up in terms of being able to make use such capabilities?

The state of crypto in Python

nmav — Fri, 02 May 2014 17:28:39 +0000

This is pretty much true. We have quite many crypto primitives libraries (libgcrypt, botan, nettle, libcrypto/openssl), and their authors are pretty much overwhelmed by the amount of maintenance needed. Helping them to improve the documentation, or the weak spots of their libraries would benefit all. Creating yet another library most probably would result to the current situation, solely with the addition of a new library in the list above.

The state of crypto in Python

Wummel — Thu, 01 May 2014 18:34:17 +0000

I'm not sure a new library is needed as well. What I sorely miss is a complete real-world example showing how to use any of those libraries in a secure manner. Especially for libraries who claim to be easy to use this provokes unsecure usage.

If a library claims to be easy to use it attracts programmers without a strong security background who most likely copy-and-paste from the examples, perhaps with one or two peeks at the documentation.
Here are some things I encountered when looking at examples of the mentioned libraries:

The example ignores all errors and therefore does not show how errors should be handled. This is especially true for languages with exception handling (C++, Python).
The example does not show how to generate, store or transfer generated keys securely. Eg. the Botan example code reads the password from a command line parameter which is not a secure way to do it.
The example has a short "this is a secret" string to encrypt. Why not show how to encrypt a complete file and store the encrypted data? I am always wondering how potentially large files can/should be encrypted.

The state of crypto in Python

nmav — Thu, 01 May 2014 16:18:24 +0000

Despite what their slides show, libgcrypt is FIPS140-2 certified. The only certain thing is that we don't need yet another crypto primitives library.