[Cryptography] letter versus spirit of the law ... Eventus incertus delendus est

Peter Gutmann pgut001 at cs.auckland.ac.nz
Thu Oct 29 23:44:20 EDT 2015


John Denker <jsd at av8n.com> writes:

>On 10/25/2015 02:13 PM, D. Hugh Redelmeier wrote:
>
>> Crashing is generally a better policy than continuing with a wrong
>> answer.  This forces bugs to be noticed and to be fixed. 
>
>That's overstated.  We agree that /some/ types of strict checking are good.
>Bugs should be found and fixed. However, "crashing" is not the right word.
>Crashing is not "generally" good policy.

Exactly.  There have been cases where the compiler/language policy was to
crash on numeric overflow, resulting in a rocket that cost $7 billion to
produce (with the rocket itself costing around $100M) exploding on launch.
Saying that destroying a $100M rocket is "not good policy" is an
understatement.

Throwing an exception *during development* is perfectly OK, because you want
to detect problems like this.  However, this only works if you've got a test
suite that provides 100% coverage of every single obscure corner case and
condition, which is unlikely to be the case (the reason why they're "obscure
corner case and conditions" is because they almost never occur).

For a release build, you never want to deliberately crash.  If you continue,
things might be OK in the long run.  If you crash, things definitely won't be
OK 100% of the time.

There's a huge amount of code out there that works by coincidence.  For
example the code I posted earlier from pdtar worked purely by coincidence, an
appropriate value happened to be in the right register(s) and made the code
work.  It doesn't work by design, it works by coincidence, but the point is
that it works.

An example I ran into a while back, while auditing some code used in a
sensitive control application, was the use of a loop controlled by an exact FP
comparison.  Technically you can't do this because you can't guarantee an
exact match, you need to use something like 'abs( a - b ) < epsilon', but in
this case it worked fine because the FP hardware produced appropriate results.
Without wanting to spend hours poring through the C language spec, it's quite
possible that the gcc developers, taking their usual most-hostile
interpretation of no-exact-comparisons, would decide that since (technically)
you can never get an exact match, the result could be "optimised" to 'while( 0
)'.  The result would be an executable that, like one where you've replaced
all the mutexes with no-ops as an optimisation, worked fine most of the time,
except when it didn't.

So: Deliberately crashing in release code is pretty much always wrong.  OTOH
continuing anyway, even with slightly incorrect values, is often right, but in
any case still better than crashing.

Peter.


More information about the cryptography mailing list