[Cryptography] Construction of cryptographic software.

Wed Dec 3 16:25:38 EST 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/02/2014 02:44 PM, Ray Dillinger wrote:

> [some things] can mostly be trusted to do exactly what they
> say and nothing more.

That's a very useful way to frame the discussion.

Good construction practices are an excellent idea.  They 
reduce the attack surface by orders of magnitude.  OTOH
I would like to argue that they don't reduce it to zero.
They don't reduce it by the factors of 2^80 that we are
accustomed to seeing in good crypto primitives.

The problem is, I've almost(*) never seen a compiler, library, 
operating system, or hardware platform that could /really/ be 
trusted to have no side-effects.  Some are muuuch worse than
others, but even the top of the pile is underwater, AFAICT.

Compiler developers don't even think about side-effects
of the kind we are talking about.  They have a model that 
says the variables that are seen by the program have to
conform to the spec, but everything else belongs to the 
implementation.  The implementation details are "unspecified"
which means the implementation can do whatever it wants.

Ditto for libraries.  C++ classes have private member
variables and methods, for the express purpose of hiding
implementation details.  Hiding is considered a virtue.
The cryptographer's notion of "no side effects" is not 
even on the radar.

The issue of paging has already been mentioned.  You can try
to work around that by locking a crypto-sensitive workspace 
in memory, but that is not the end of the story.  Even if the
compiler is not trying to do any super-clever optimizations,
it still has to to compute stuff one sub-expression at a 
time and store stuff in registers.  If there is an interrupt,
the registers get saved who-knows-where, not in the locked 
workspace, and might very well get paged out or hibernated.
And then you have really lost control of the situation.

  Zeroizing a disk is no longer possible AFAICT, because
  the disk controller is constantly moving stuff around,
  for error-concealment and wear-leveling.  Main memory
  is not far behind.

  Heating discarded magnetic media above the Curie point
  still works, but is not what you want for routine day-
  to-day erasure.

(*) For super-sensitive tasks, you can use a Faraday cage
with a single-user machine on the inside and armed guards on
the outside.  However, alas, that leaves the other 99.9999%
of the problem unsolved, for instance if you want to write 
a reasonably decent browser or MUA for Grandma to use.

Bottom line:  I don't think we have the primitives to really
do what we want.  This is fixable, but it would require 
changes at every layer from the hardware on up.  This is
serious business.  Try to imagine a hardware instruction
that says
  onInterruptStoreMyRegistersHereAndNowhereElseEvenIfItHurtsPerformance
and imagine support for that all the way up to the language
and library level.

For today, we should do what we can.  It's a tricky two-part
argument:
 a) It helps to lock the front door and the back door, even
  though the side window is standing open.
 b) OTOH we should not overestimate how much good it will do.