[Cryptography] Other obvious issues being ignored?

Jerry Leichter leichter at lrw.com
Tue Oct 20 23:40:21 EDT 2015


> 1. Compilers that break security code in the name of optimization. The C community in particular insists that it is ok to delete potential overflows, even deleting assert checks,  and to ignore zeroization of data that will not be used again. Rather than demanding change, security programmers resort to subterfuge to fool the compiler, but there is no guarantee that the tricks employed will still work in the next release of the compiler or when ta newt build is done with a different optimization setting. 
You make this sound like a criticism of C.

The vast majority of C code is *not* security code, and is helped by such optimizations.  That's why compilers implement them.  C may have had a simple, direct mapping to hardware back in the days of the PDP-11, but today's machines are very different, and people use C not because they want to do low-level optimization of every aspect of the machine's operation, but because it's light weight and can get really good performance for appropriate code.  (Appropriate:  If you want your array operations to be optimized to the limit, you're probably still best off with FORTRAN in most situations.)

So ... I'd turn this around.  The issue isn't with C, or Java, or any other general purpose language.  It's that we really don't have a suitable way to express security-sensitive code.  General-purpose languages will always lean toward satisfying the vast majority of programming needs, which will likely provide a semantics that is not consistent with the needs of security-related code.

I doubt having a whole separate language for writing security-related code is the right approach either.  A better approach would probably be to define an appropriate set of semantic constraints and provide a way to constrain segments of code in an existing language to obey them.  It's easy to give a quick, informal list of requirements - assignments always write through to memory even if the variable appears dead; to duplication of sensitive values; etc.  But that's a *long* way from a good formalization of the necessary semantics that compiler writers can work with across very different kinds of architectures.

I wonder how the NSA writes its security-related code?

                                                        -- Jerry



More information about the cryptography mailing list