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

[Benjamin Kreuter]

On Sat, 2014-04-19 at 16:59 -0700, Bear wrote:
> On Sat, 2014-04-19 at 18:10 -0400, Benjamin Kreuter wrote:
> > On Fri, 2014-04-18 at 18:54 -0400, Jerry Leichter wrote:
> > > And yet the fact of the matter is that some of the most reliable code
> > > out there is written in C.
> > 
> > This is a non-sequitur.  Sure, it is *possible* to write reliable and
> > secure code in C, it is just difficult to do.
> > 
> > > 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.
> > 
> > "Possible" is not the same as "probable."  I have far less confidence in
> > the security or reliability of C or C++ programs than programs written
> > in Haskell or ML.  It's not that Haskell is a guarantee of security,
> > it's that the effort needed to avoid certain classes of errors is
> > substantially reduced.
> 
> There are different aspects of security that are important here.
> 
> I am more confident that someone will not be able to get an application 
> written in Haskell or ML to do other than behave as its writer intended.
> That is important in terms of security.
> 
> I am more confident that someone writing in C will be able to create an 
> application that doesn't leave copies of information you want private 
> sitting around the system in public places.  That is also important in 
> terms of security.  
> 
> Now, if only I could be confident that the person writing in C had
> *BOTHERED* to write an application that doesn't leave copies of
> confidential information lying around, I'd feel better. But the person
> writing in Haskell or ML, literally CANNOT avoid leaving copies of 
> data values lying around in memory.

I do not think these issues are as orthogonal as you make it seem.  You
cannot really say that an application does not leave copies of
confidential data lying around without being confident that the
application behaves as intended.  This is painfully apparent with
heartbleed:  data is unintentionally copied because array boundaries are
not enforced.

On the other hand, if we had the motivation, we could certainly create
an ML that presents a "secure buffer" data type that cannot be copied
and that will be cleared when it is no longer in use.  Then we would
have a much stronger guarantee about "not-to-be-copied" data actually
not being copied.

-- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140420/b2f81c89/attachment.pgp>