[Cryptography] Heartbleed and fundamental crypto programming practices

[Viktor Dukhovni]

On Thu, Apr 10, 2014 at 07:15:14AM -0400, Jerry Leichter wrote:

> In a language
> like C, you can have a library routine to create a RedString that allocates
> extra memory and returns an address offset into the block malloc() gave
> you.  If someone tries to free() it directly, there's a good chance the
> memory allocator will crash, and someone will find the problem.

Postfix with a couple of minor exceptions that need to interoperate
with external libraries, calls malloc() and free() only via mymalloc()
and myfree() that always overwrite memory on free() and initialize
on malloc(), both with a non-zero fill byte.  mymalloc() indeed
returns a pointer to a non-zero offset into a larger block obtained
from the real malloc().  The larger block has a header and a trailer,
both of which are unconditionally verified on free().

The Postfix way to process packet content would not be to use a
local pointer that is an offset into the packet which requires each
function that is handling packet content to implement its own bounds
checks.  Rather the packet would be a data-structure with an explicit
offset, and there would be read/write routines for consuming and
producing packet data and the bounds checks would be in one place!

In other words, C++ discipline in a C program.  There are multiple
structural changes (or a complete rewrite) that would dramatically
improve the robustness of OpenSSL, but who's going to pay for this?

MIT Kerberos are beginning to dig themselves out of the Kerberos
code quality hole they were in after creating the MIT Kerberos
Consortium, and getting enough funding to run the project.

If we're to have a free (as in beer) open source SSL implementation,
perhaps it needs a more robust funding structure and stake-holders
who are focused on improving code quality over feature of the day.

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

There are many good programming practices, I will not attempt to
list those here, I want to add a couple of practices that are less
about project management that help maintain code quality:

 * High quality software projects are not democracies.  The code
   needs strong guardians who defend it against hastily conceived
   features.  This goes beyond "code review".  The guardian is
   responsible for the long-term quality of all or a subset of the
   code base and must be able to reject features that mess up the
   product architecture or are not implemented robustly.

 * All new code must be documented, do not accept contributions
   of code without documentation.

 * No new features in patch updates of stable releases.

-- 
	Viktor.