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

[ianG]

Thanks to all those replies, I think it is clear that we do know how 
this can be done.  Onwards...



On 7/01/14 14:52 PM, Jerry Leichter wrote:
> 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.


Au contraire!  That is precisely what makes it a good contest.

Consider AES.  When that contest was launched, did we already know how 
to do a good block cipher algorithm?  Apparently, yes.  We had Blowfish, 
IDEA, 3DES, and others whose names escape me.

> The issue now is how to get someone to actually use the tools....


What was at issue was replacing these with a single choice we could all 
centralise on and get away from the algorithm spaghetti soup syndrome.


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


Yes.  Not impractical because we don't know how to do it individually, 
but impractical because we don't know how to do *consensually*.  E.g., 
it is proven that the committees and their 'rough consensus and 2 
working implementations' has not worked.


> b)  Actually produce a practical, useful result.


Right.  For that to happen, we have to make it big.  Then, push groups 
to sign up to it.


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


It meets both criteria, as long as they are framed appropriately ;-)



iang



ps; of course, we're playing devil's advocate here.  I'm not actually 
wedded to the notion of a "C sans overflow" competition.  I would 
actually rather do a TLS2 competition ... that would be much more fun, 
and much more inventive.

But hey.  What's the biggest problem we face?