[Cryptography] GnuTLS -- time to look at the diff.

[Jerry Leichter]

On Mar 7, 2014, at 12:22 PM, Nico Williams <nico at cryptonector.com> wrote:
> Manual memory management also isn't the problem.  Sometimes you really
> want manual memory management in security-critical components: ... because you want secrets wiped from memory as soon as possible....
Interestingly, this is where C++'s static typing and "cradle-to-grave" constructor/destructor style is a perfect fit.  At a previous job, we designed a pair of classes, RedMem and BlackMem.  This picked up on classic crypto language:  RedMem contained unencrypted, sensitive data; BlackMem contained encrypted versions of stuff from RedMem.  Encryption functions took RedMem input and produced BlackMem output; decryption functions went the other way.  I/O functions worked on BlackMem, but would refuse RedMem.  The RedMem destructor cleared memory before releasing it.  And so on.

Ordinary code could pass BlackMem around safely and treat it as just some values it didn't know how to interpret.  In fact, BlackMem was essentially a subclass of an "ordinary memory" class.  But RedMem was special, and could only be handled by trusted code.

You can't cover every possible scenario this way - e.g., when you want to create a message, the inputs have to come from *somewhere* that isn't RedMem; and presumably you want to *use* the decrypted stuff in RedMem for something.  And it's always possible to deliberately circumvent the protection offered.  But all kinds of mistaken code just outright won't compile.

It's a mistake to concentrate too much on the features the language itself gives you.  You need to be able to construct datatypes and functions appropriate to the problem domain.  With a decent language and well-designed libraries, you can write reliable code.  Without them; without careful design and implementation and checking ... all bets are off.
                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140307/cba45c99/attachment.bin>