[Cryptography] Other obvious issues being ignored?

[John Gilmore]

[Re the non obvious issue of compilers versus crypto code]

The attitude expressed so far is incredulity that a compiler would
assume that the programs it is compiling do not violate the standard
for the language.  I have worked on many programs, and whenever I
found such a problem (typically called a "portability problem"), where
the code was assuming something that the language did not guarantee, I
fixed the program rather than bitching about the compiler.  (Back in
the 1980s I went through the entire Vax 4.3+ BSD Unix source code,
built it all with GCC, and revised all the nonportable code from
Version 7 Unix, e.g. that assumed it was being built on a 16-bit
PDP-11 by an early generation C compiler.  I wrote an academic paper
about what I found, including a lot of amusing nonportable C
constructs, but it was rejected by the reviewers and never published.
The code improvements were adopted by Berkeley, which also let them
adopt GCC as their standard compiler.)

In the case of signed integer overflows, there's a really simple way
to make the code portable: Declare those variables "unsigned" rather
than "int".  I know this is too much trouble for some people.  I don't
recommend buying crypto code from such people.

GCC in particular has a -Wstrict-overflow option that will diagnose
code that is being optimized with the compiler's assumption that it
does not cause overflows.  Consciencious programmers can use this
option to identify code that was nonportable, so they can rewrite it.
See GCC maintainer Ian Lance Taylor's blog post:

  http://www.airs.com/blog/archives/120

The main further bitch seems to be that "side effects get optimized
away", such as assigning zero to a variable that is subsequently never
referenced.  (The "side effect" in that case is that a chunk of raw
memory or registers no longer contains a cryptographically sensitive
value after the assignment.)  The standard C language has a cure for
this, too, the "volatile" declaration.  I have the same advice about
getting crypto code from people who are unwilling to type that extra
word.

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

Subterfuge rather than portable code seems like a novice response.  If
the code is rewritten to be portable, it will work in every release of
every compiler (modulo the occasional compiler bug).

	John