[Cryptography] defaults, black boxes, APIs, and other engineering thoughts

[Jerry Leichter]

On Jan 6, 2014, at 3:13 PM, John Gilmore wrote:
>> +1 on the competition approach...  Why not narrow it down?  PDF however is a huge project.  Pick the one thing that we all seem to revert to in any secure code discussion:
>> 
>>       buffer overflows in C.
>> 
>> Design the mod to current C language/libraries that best addresses the 
>> syndrome.
> 
> This has already been done.  No change to the C language or libraries
> is required; the ANSI C committee was diligent in defining the
> language to only work when your reach didn't exceed your grasp.
> 
> "Saber C" and "valgrind" already implement this.  Saber C is now known
> as CodeCenter, and its C++ variant is ObjectCenter.  It is a
> commercial product of Integrated Computer Solutions, which bought it
> from Centerline Software and now seems to have stuck it on a shelf:
The idea (and even commercial implementations) goes back way further than that.  Alan Feuer did this, but someone sold a product called Safe C back in the early 1980's.  (I was offered a part-time gig helping with the development, but it didn't make sense with my graduate studies at the time.)  As best I can recall, Safe C was a pre-processor that modified all arrays and pointers and C operations in them to enforce bounds checks.  As I recall, it was considered too inefficient to be practical for most operational code, but you could use it during testing.  With more aggressive work to minimize and optimize the actual inserted, runtime overhead should be minimal.  (The cost of using "fat pointers" in place of simple memory pointers is harder to deal with invisibly.)

I think the name "Safe C" was, many years later, repurposed for an entirely separate effort to define a subset of C that could be used in secure real time applications, or something like that.  If you run across this - it's unrelated.

A "secure C" wouldn't make for a good contest because, as John says, we already know it can be done, and in fact it *has* been done, repeatedly.  The issue now is how to get someone to actually use the tools.  Safe C died; the tools John mentioned are barely alive, if at all.  We regularly sacrifice security on the alter of efficiency - see the C++ STL and its approach to iterators.  (I wrote about this years ago:  http://catless.ncl.ac.uk/Risks/21.85.html#subj5.4)

A contest, to be worth holding, has to:

a)  Challenge the state of the art by doing something that while clearly useful is commonly believed to be impractical;
b)  Actually produce a practical, useful result.

"C without buffer overflows" meets neither criterion - the first because it's been done, the second because the market has clearly shown that it won't take up the result.
                                                        -- Jerry