[Cryptography] Other obvious issues being ignored?

[Ray Dillinger]

On 10/20/2015 05:05 PM, John-Mark Gurney wrote:
> Arnold Reinhold wrote this message on Tue, Oct 20, 2015 at 14:48 -0400:

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

C and C++ do have the "volatile" keyword which does exactly what
you are asking for (data located outside register, always written
when the code writes it even if the code never reads it again).

I know of no other language that has anything equivalent.  As far
as I'm concerned it is impossible to write secure code in Pascal,
(because any optimization that is guaranteed to produce the same
output result is permitted without let or hindrance), it is impossible
to write secure code in Java (because there is no way for a program to
control whether the JVM is modified), it is impossible to write secure
code in Lisp or Java (because garbage collection can leave sensitive
stuff lying around indefinitely until collected) .....

It's a problem.  But when I'm trying to write secure code I do in
fact usually wind up writing it in C.  In an excruciatingly tedious
process to make sure every last damned buffer write is checked for
overflows, and that every last damned malloc at a known line creates
something that is absolutely guaranteed to end at a free at a
different known line, that every last "constant time" algorithm
has timing loops and exit statements to force the program to
fail immediately if the compiler "optimizes" the routine breaking
that property, and etc....

And further excruciating process to ensure that mathematical
operators leading to 'undefined' behavior on overflow are not
used (eg, integer addition/subtraction is allowed only on
unsigned integers, or values cast to unsigned, etc).  I
frequently wind up reading the standard "adversarially" in terms
of specifically finding ways to prevent things it would ordinarily
allow, or accomplish things in ways the system isn't allowed to
redefine.   It is long, ugly, and sometimes the resulting code is
horrifying.  It is often clearer and simpler when subroutines are
coded in assembly language, but the kicking-dead-whales version
has to be done in C because portability.

Usually it will compile just fine with any optimization setting
but if compiled with -O3 it will print a message about what got
"optimized" in an unacceptable way and exit instantly if run.


				Bear



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151021/536f2d69/attachment.sig>