[Cryptography] Other obvious issues being ignored?

[John-Mark Gurney]

Arnold Reinhold wrote this message on Wed, Oct 21, 2015 at 08:55 -0400:
> 
> > 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. 

I want the compiler writers to produce faster code...  That's good
for everyone...  We've just his a bad point where the compiler writers
have gotten ahead of the standards in this regard...

Well, when the overflow test is written incorrectly, the compiler has
every right to remove the test...  The problem is there are corners
of the C standard that even the most experienced C coder does not know...

The fact that signed overflow in C is undefined behavior is now well
known, but has been undefined for over 15 years, if not longer...

The same thing happened w/ aliasing...  Now that compilers are getting
smarter, they are looking at the standard to see how they can exploit
it to improve code performance...

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

Hope they got that right in their C code, or what ever language they
used got it right in their C code.. :)

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

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