[Cryptography] Other obvious issues being ignored?

[John-Mark Gurney]

Arnold Reinhold wrote this message on Tue, Oct 20, 2015 at 14:48 -0400:
> 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. 

The problem is the C standard and has nothing to do w/ the C
compilers.  The standard allows the compilers to do these
optimizations, so they are perfectly legal and correct.  As far as
I'm concerted, you cannot write secure code in C.  The C standard
needs to add some additional keywords to mark data that needs to be
treated specially.

Don't forget that even if you do manage to get a compiler that
doesn't omit your zeroing of data, it doesn't mean that you managed
to zero all the locations that the data was.  The compiler is free
to leave parts of that data in registers (which could end up in kernel
memory on task switch when saving registers), or even other parts of
the stack when it copied/moved data around.

The other issue is constant time operations.  The classic example is
bcmp.  One version is:
int
timingsafe_bcmp(const void *b1, const void *b2, size_t n)
{
        const unsigned char *p1 = b1, *p2 = b2;
        int ret = 0;

        for (; n > 0; n--)
                ret |= *p1++ ^ *p2++;
        return (ret != 0);
}

The problem is that even though current compilers compile this to a
constant loop, there is NOTHING in the C standard that prevents a
compiler from realizing that once ret is non-zero that there is no
need to continue through the loop, and can break out early, defeating
the point of the function.

Until the C standard adopts something to address these issues, it just
isn't possible to write secure code in C today.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."