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

[ianG]

On 6/01/14 01:59 AM, Jerry Leichter wrote:
> On Jan 5, 2014, at 3:25 PM, Jonathan Thornburg wrote:
>> But this raises some genuine questions:
>> * Is there a secure web browser?  My trust level in any of the biggies
>>   (Microsoft, Apple, Google, Mozilla) is low...
> I'm with you.  For what it's worth, I think Chrome is probably, across time, the most secure, because Google puts a huge amount of effort involving a really experienced team into making it so.  I place some amount of trust in Safari, but that's a matter of statistics, not anything special about the code:  People aren't attacking it as much.  (Apple seems to have been getting ever more serious, but how far they've come is hard to judge.)
>
> But a modern browser is the ultimate example of immense complexity in commonly used software today....
>
> I do find fascinating the reaction to the never-ending series of security issues in Flash and Java.


It's very annoying.  All of those bugs labelled as Java are really 
applets in browsers.  So every time a scare story comes along, we have 
to read all about it only to discover it is really nothing to do with 
the language.


> What people have learned from this is:  Plugins are bad; Flash itself is bad.  They looked to the promised land of HTML5 ...


Browsers are kitchen sink.  Like OSs.  Do you recall the mid 1990s when 
the browser delivered by Netscape also had email and web design in it?

That takes security questions to a whole new level...  Considering 
browsers as secure cannot be done in the normal single app sense, they 
are really OS or platforms.  And for this reason, they can't ever be any 
more secure than the stuff loaded up into them.

I generally model this by saying that browsers are good for medium 
security stuff, not high security stuff.  With that thought in mind one 
can have a discussion as to whether favourite app (say, online banking) 
fits in which category.


...
>> * Same question, but for pdf files?
> I think we have the makings of an excellent context here:  Pick one of these - PDF ...
>
> Code to be judged in a way that's similar to the contest that chose AES:  Public review by experts in the field, by other contestants, and by anyone else who chooses to comment.
>
> The AES contest drew people in because there was a chance for an academic or other expert to have his work become a national standard.  I don't think that would work here - you'd need someone to kick in serious money to offer, both to the chosen developer, and to anyone who came up with worthwhile attacks.
>
> The real purpose of the contest would be to examine, and push, the state of the art in secure code development.  If done correctly, this could teach us a great deal about how to go about this.
>
> What I find most disturbing is that many of these bugs are trivial to avoid using techniques that have been known forever.


+1 on the competition approach, all the above.

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.

Open competition.  No rules.  Big prize of open endowment for 
academic/research project...  (Format already known & practiced.)

Anyone got a spare mil?


> I set out to eliminate the crashes.  It turned out that almost all of them came down to one root cause:  The LAT protocol was defined in recursive components and subcomponents, each of them encode in TLV (Type Length Value) format.


Right.  Yet, this technique works surprisingly well in languages that 
handle overflows and have exceptions.


>  They were parsed and handled in what you might, in a language parser, call recursive-descent style:  You used the T field of a subcomponent to select the right function; it pulled off the leading L field and dealt with the subcomponent and returned a pointer to where the next T field should start.  Unfortunately, damaged components often had garbage length fields.


In OO I don't think I can imagine doing it any other way.  When I port 
stuff into C for example, I port all the OO concepts (including buffer 
overflow handling) to make it happen, and when the code is up and going, 
it works and debugs very quickly.


> This would have been, oh, 1986, give or take.  But somehow C programmers at larger never learned - or were even taught - the lesson.  The only thing that's gotten us away from the never-ending stream of bad C code that scribbles memory is the fading of C from most commercial products:  C++ can be somewhat resistant (if you use the built-in types, *carefully*), and the newer languages all check array and string bounds.


Im my experience, the vast majority of programmers do not know careful. 
  They are struggling with complexity -- of the language itself, of the 
designs they have to code, of the things thrown at them.

Unless the language solves these problems for them, they're SOL.  Or 
their employer is.

My own revelation in this came at your hands a few weeks ago, I had to 
go through and find the critical Closables in my code and ... close 
them.  I have no idea why I missed that.



iang