[Cryptography] It's all K&R's fault

[Jerry Leichter]

On Apr 18, 2014, at 4:54 PM, Peter Fairbrother <zenadsl6186 at zen.co.uk> wrote:
> No, I'd argue that you *can't* use it [C] reasonably.
> 
> You write code, you are a genius, and your code is perfect. Then some non-genius comes along to maintain your code, and because you haven't used safe code constructs he makes a mistake....
And yet the fact of the matter is that some of the most reliable code out there is written in C.

What's important isn't the language as such, and it's been proven over and over again that it's possible to write unsafe code in any language.  Ada was supposed to make coding safe, and yet the Ariane failure was due exactly to a required safety check that, in the situation at hand, actually *caused* a failure.

Java makes large classes of memory errors that have troubled C and C++ for years impossible - but Java programs regularly die with null pointer exceptions and class cast errors.

For almost 60 years, we've been promising that, really, this new language will *finally* eliminate bugs and security problems - only to be disappointed.

There's nothing in the code
Looks any different to me
And the types are replaced, by-the-bye
And the parsing on the left
Is now the parsing on the right
And the preludes have all grown longer overnight

I'll tip my hat to the new specification
Take a bow for the new revolution
Smile and grin at the change all around me
Boot my Emacs and play
Just like yesterday
Then I'll get on my knees and pray
We don't get fooled again
Don't get fooled again
No, no!

Meet the new language
Same as the old language.

Safe, secure code is produced by careful, deliberate processes.  The processes include discipline on the use of features, the avoidance of reliance on known-dangerous libraries, careful documentation, careful testing, standards for validation of parameters, enforcement of pre- and post-conditions, code scanning by static analyzers, detailed code reviews, and many other techniques.  They are both social and technical.  Doing it this way is very difficult, and very expensive; but it's sometimes necessary and justifiable because of the costs of getting it wrong:  Planes falling out of the sky, reactors going critical, medical equipment killing patients.  Such code isn't perfect, but then nothing in the real world is perfect.  Planes still crash due to mechanical failures or pilot error, tsunamis render nuclear plants highly dangerous, patients die due to all kinds of errors.  But code written for such applications is good enough to not be a driving factor in the failures.

Crypto code, collectively, is now becoming as critical as much of that other code.  And yet no one is willing to put up the funds necessary to build it to the necessary standards.  Never mind open source.  The kind of closely supervised and controlled programming needed - much of it profoundly boring - would have no hope of making it as an OSS project.

Compared to all of these factors, C vs. L, for any reasonable value of L, is lost in the noise.  (And keep in mind that if L is some new toy ... why should you believe that its compiler and library faithfully implement the language spec?  Without that, you have no reason to believe much of anything about programs written in L.  At least C compilers have been around for a really long time and we can have reasonable faith that they do what they claim to do.)
                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140418/be918a05/attachment.bin>