[Cryptography] Other obvious issues being ignored?

[Michael Kjörling]

On 20 Oct 2015 23:40 -0400, from leichter at lrw.com (Jerry Leichter):
> 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.

This is drifting a little away from strictly being about cryptography,
but something like a standardized "#pragma nooptimize" attached to a
function to tell the compiler to not optimize the code in that
function at all but rather do as close to a one-to-one mapping from
the source code to machine language constructs, would probably go a
long way. (It wouldn't have to be a pragma; it could be a keyword, or
some other type of marker. The key part is what it would express, not
the mechanics of how to express it.)

It would not be perfect, for some of the reasons already outlined
(things like the possibility of data remnants in kernel memory after
context switching), but much of this is already outside the scope of
the language in the first place. It's easy to imagine a scenario in
which some piece of software works with security-critical data but
doesn't lock that page in RAM first; in which case the data may very
well get swapped out to disk by the OS, completely unprotected. The
language can't protect against that either. What the language _can_ be
used for is to express the programmer's intentions.

A function marked as such would be translated to the closest possible
machine language representation that does what the code says, even if
the compiler would normally optimize parts of the code away. This
would include things like treating every variable access as if the
variable was marked "volatile", no rearrangement of trivial operations
even if the observable end result would be the same, overwrite all
scratch registers on function exit, and so on.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)