[Cryptography] Fwd: Underhanded Crypto

[Alexander Kjeldaas]

On Wed, Dec 3, 2014 at 9:31 PM, Ben Laurie <ben at links.org> wrote:

> There is the orthogonal question of what to make of this in the face of
> Purify, valgrind et al. which (almost always rightly) view this entirely
> harmless practice as evil.
>
>

To me this is pretty simple if you think in terms of types.  Yes, sometimes
you want to invoke undefined behavior, unusual behavior or poke beneath the
common abstractions.  That in itself is not the problem. When you do so,
you use an interface so you can inform the compiler, the programmer, the
reader, tools like Purify, valgrind etc. about what you are doing.

Thus Purify, valgrind etc are correct in flagging this as evil.  They have
a more advanced type system in certain cases than what C has.

A programmer or a reader can be informed using a comment, but the other
tools typically use functions and types as the way to build interfaces.

Thus reading from uninitialized memory is a two step process.  First you
invoke a function that coerces the uninitialized memory into initialized
memory.  It could be something like, say  "void *treat_as_initialized(void
*)".

In the Purify or valgrind type system, this will read as   "void
initialized *treat_as_initialized(void *)".  I'm making up the syntax, but
this is fundamentally about types and types are what gives assurance,
security, and what makes it possible to analyze software.

Thinking about it this way makes it obvious that just invoking undefined
behavior inside of a function is really bad systems design, both from a
theoretical perspective and for maintainance.  Likewise if the software
fiddles behind the GC curtain, fiddles with the bytecode interpreter,
updates the CPU microcode in the middle of a function etc.  Properties
should be expressed as types, and if the language does not support
expressing those properties as types, express them as functions /
interfaces.

Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20141206/2e549f47/attachment.html>