[Cryptography] Other obvious issues being ignored?

[Arnold Reinhold]

The opinions on this thread range from ‘the C can never be safely used for cryptographic programs’ to ‘C can be safely used if you really know what you are doing and are really, really careful.’ But C and C++ are very popular languages with a huge corpus of code written in them and not going away any time soon. It’s as if we are in some fraternity that throws members into the lake if they mess up the secret handshake sequence and we all think this can never change or that this is ok because those are the rules or even that getting the secret handshake right builds good character.

Perhaps we should shift the focus of this discussion from the problems we perceive (or don’t perceive) with C-family compilers  and language specifications, to what steps the cryptographic community might take to get better cooperation from the developers of GCC and LLVM. Others have pointed out that commercial C compilers tend to behave better, possibly because the companies that supply them motivate their (paid) developers to feel more responsible to their customers. 

So what motivates the developers of free compilers like GCC? I speculate it is some combination of the following factors:

1. The intellectual challenge of developing compilers that produce highly efficient code.

2. The prestige of working on a project that is so widely used and influential.

3. A spirit of competition between compiler teams to produce the fastest object code.

4. Normal human defensiveness in the face of criticism.

5. Maybe some impish pleasure in creating a puzzle world that others have to navigate. (Peter Gutman’s recollection that gcc 1.17 tried to load the games Rogue and NetHack as an form of undefined behavior is suggestive in this regard.)

Developing compiler features that support safe cryptography could be as intellectually challenging and interesting as squeeing the last fraction of a percent of code efficiency. I know many people have tried to get cooperation from compiler developers and been stonewalled. A more organized approach might stand a better chance. Here are some possibilities that occur to me:

1. Drafting an open letter/petition that hopefully many members of the cryptographic community would sign. It might calmly state the problems many of us are seeing and seek the developers’ cooperation. At the least, it might be sent to the Free Software Foundation, which nominally is the home for GCC, and Richard Stallman, FSF’s founder. I think both care about their reputations, I’m less familiar with the LLVM community and whom to approach. Maybe Chris Lattner at Apple, a key player in LLVM and Swift. Without being too heavy handed we might point out the Snowden revelation that NSA has a program to influence standards in order to create vulnerabilities for NSA cryptanalysts, and that intentionally or not, their compilers are de facto aiding this effort. I would think FSF and the individuals mentioned would be horrified at that possibility.

2. Organizing a professional meeting where cryptographers and compiler developers can discuss the impact of language tool chains on security. It might be under FSF or neutral auspices, such as the ACM, perhaps with a professional facilitator or mediator. 

3.Developing a cryptographic community standard for crypto-safe compiler behavior. Ray Dillinger proposed a Crypto C, but a crypto-safe standard might even be language neutral, e.g. requiring a way to guarantee data is erased after it is no longer needed, a way to prevent code optimizations that introduce side channels, not changing code execution sequence without warning, pragmas to control or test for optimization level (so compiler behavior is under version control), etc. Sample test programs might be provided in pseudo code and/or in the major languages.

While there are people who have strong feelings of frustration, it seems to me that improving tool chains is a heck of a lot easier from an organizational perspective than getting fixes to bad Internet protocols adopted. Maybe treating this as a human relations problem rather than a technical one is the best way to make progress.

Arnold Reinhold