[Cryptography] Other obvious issues being ignored?

[Arnold Reinhold]

> On Oct 20, 2015, at 8:05 PM, John-Mark Gurney <jmg at funkthat.com> wrote:
> 
> 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.

The fact that the C standards ALLOW certain “optimizations” does not mean that compiler writers are REQUIRED to do the most evil things imaginable in certain situations, e.g. removing assert tests that could involve an overflow without even generating a warning (we had a long thread on this a while back). So I think compiler writers share the blame with the standards committees. 

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

Exactly, but the C-family languages still dominate the software industry. At least Apple’s new Swift language includes arithmetic operators that explicitly allow overflows, but I have found no info about zeroization in Swift. 

Jerry Leichter writes:
> 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.
> 

Ideally I would like a language whose output object code is canonical for any given platform, so we could predict exactly what our code will do. It should be possible to expect two separately written compilers to produce identical object code for a given platform. This might be done with an intermediate language that specified the resulting object code for each major platform. We don’t need a lot of fancy language features, a subset of C might do.

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

Indeed. NSA could help rebuild is damaged reputation by sharing its approach.

The original question was what problems are we ignoring and lack of crypto-safe programming languages is a biggie. 

Arnold Reinhold