[Cryptography] Heartbleed and fundamental crypto programming practices

[Sandy Harris]

On Thu, Apr 10, 2014 at 7:15 AM, Jerry Leichter <leichter at lrw.com> wrote:

> We've all by now heard of the Heartbleed security disaster.  I haven't seen the actual coding error, but the descriptions indicate that an attacker could cause the server to allocate and return a large buffer, almost all of which was left uninitialized - and often ended up containing various pieces of left-over sensitive information from previously-deleted and now-reused memory blocks.
>
> Years ago, when I developed some software in C++, I had a pair of classes called RedString and BlackString, imitating classic crypto usage of the colors.  A RedString contained "sensitive" data - data to be encrypted or that had been encrypted, keys in the clear, etc.  You could convert a RedString to a BlackString by encryption, or the other way around by decryption.  You could not misused a RedString in many obvious ways - e.g., the services that sent data over a link wouldn't access a RedString.
>
> More to the point, the destructor of a RedString cleared its memory before releasing it to the free pool.  A Heartbleed attack that revealed 64K of former RedString's would have revealed ... 64K blocks of zeros.
>
> It is - or should be - just a fundamental principle of secure coding that you minimize the amount and time you keep "sensitive" data around in memory - *and that you never release control of it*.  It's your responsibility - you don't hand it to the memory allocator.

Yes.

Here's an alternate take saying don't do your own buggy allocation and
lose the error checking in system one.
http://article.gmane.org/gmane.os.openbsd.misc/211963

> I've seen comments over the years that crypto- (and all security-)related programming should not be left to "general" programmers with no domain expertise.  I'm not aware of any attempt to collect a list of "issues and programming techniques a crypto programmer must know".  Might be useful to have....

A fine suggestion.

One reference has:

"As for databases and real-time programming, cryptography looks
deceptively simple. The basic ideas are indeed simple and almost any
programmer can fairly easily implement something that handles
straightforward cases. However, as in the other fields, there are also
some quite tricky aspects to the problems and anyone who tackles the
hard cases without both some study of relevant theory and considerable
practical experience is almost certain to get it wrong. This is
demonstrated far too often."

http://en.citizendium.org/wiki/Cryptography#Cryptography_is_difficult