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

[Peter Todd]

On Fri, Oct 30, 2015 at 03:44:20AM +0000, Peter Gutmann wrote:
> 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.

<snip>

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

Counter-example: crypto-finance applications, e.g. Bitcoin.

Downtime just means you're not earning money, which is expensive, but
not as expensive as incorrect values leading to you _bleeding_ money.

In fact, the Bitcoin protocol had this very example happen! We had an
overflow bug(1) that caused invalid transactions to be accepted that
created money out of thin air. Crashing on overflow would have meant
that at worse the Bitcoin network went down - embarassing downtime, but
at least everyone's money would have been safe. Instead it kept running,
and when the problem was fixed a whole bunch of blocks were reversed.
That was in 2010, so at the time hardly anyone actually used Bitcoin and
nothing much happened, but these days you'd very likely see thousands of
dollars - if not more - lost due to doublespends.

Whether or not crashing in release is wrong depends on the relative
costs of downtime vs. data corruption. I strongly suspect that in most
applications you're better off crashing immediately. After all, if
downtime is really that expensive, you probably have 24/7 engineering
who can find and fix the overflow quickly and get everything up and
running again. I agree that the Ariane 5 software shouldn't have crashed
on numeric overflow, but most of us aren't in the business of rocketry.

1) https://en.bitcoin.it/wiki/Value_overflow_incident

-- 
'peter'[:-1]@petertodd.org
00000000000000000ad0cf6b083695a94d0de85dfab00ba5b2c7373e231c5868
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151030/522e5cb7/attachment.sig>