[Cryptography] The GOTO Squirrel! [was GOTO Considered Harmful]

[Andrew Righter]

I asked this on Twitter but perhaps this is now relevant here:

Are there unit testing framworks for crypto libs? I suppose they would do as Peter suggested below in depth running along side assertions and check equalities. 

> On Feb 28, 2014, at 8:33 PM, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
> 
> "Dennis E. Hamilton" <dennis.hamilton at acm.org> writes:
> 
>> It is not about the code.  It is not about the code.  It is not about goto.
>> It is not about coming up with ways to avoid introducing this particular
>> defect by writing the code differently.
>> 
>> I say this is all about the engineering and delivery process that allowed
>> this gaff to be introduced into production code for a security-important
>> procedure and allowed to remain there until someone noticed externally.  The
>> coding style could have been perfect, with the code still not establishing
>> security correctly and it would have been put into the live release, all else
>> being equal.
> 
> I was just about to say the same thing.  Even if you rewrote the entire think
> in Haskell (the newspeak of programming languages in which it's impossible to
> write incorrect code[0]), you can still produce something where some crypto
> check is missed.  This isn't an issue of coding style, it's one of software
> engineering practice (or lack thereof).
> 
>> There are innumerable ways the particular defect could have been detected and
>> remedied well before the code was committed to the code base.  A walkthrough
>> would likely catch it, assuming a skilled human other than the original
>> programmer simply read through it.  I bet explaining it on a walkthrough
>> would have led the originator to notice it.
> 
> This could be, and should have been, caught with automated testing.  The
> problem is that most (all?) testing of this type of code is along the lines of
> "do the things that should happen, happen?", with very little testing of "do
> the things that shouldn't happen, not happen?".  What happens if a bit in the
> SSL handshake is flipped?  What if a bit in the payload data is flipped?  What
> if the server presents cert A and signs with cert B?  What if a bit in the
> signed DH parameters is flipped?  What if the hash has a valid signature but
> it's the wrong hash for the data?  (Those are all self-checks that my code
> performs, if there's anything else obvious that I've missed I'd love to hear
> about it so I can add checks for that too).  These are trivial, automated
> checks that you can run before you ship, and several of them would have caught
> Apple's bug (the signature wasn't checked at all, so wrong-key, DH-parameter-
> manipulation, and valid-sig-on-wrong hash would all have caught the problem).
> 
> Peter.
> 
> [0] Some advocates of Haskell actually seem to believe this, which always
>    provides for much entertainment during discussions.
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography