[Cryptography] Secure erasure in C.

[Ray Dillinger]

On 09/11/2016 07:18 PM, Tony Arcieri wrote:
> On Sun, Sep 11, 2016 at 8:08 AM, Henry Baker <hbaker1 at pipeline.com> wrote:
> 
>> As many people have pointed out, the problem with erasure is that it deals
>> with a concept not captured by normal programming languages, operating
>> systems or computing hardware.
> 
> 
> Except it is? I pointed out a compiler intrinsic, memset_s(), that solves
> this problem, and pointed to a library (libsodium) that provides a cross-OS
> solution to this problem, but nobody cared. Honestly, that should've been
> the end of the thread, but it persisted.


Honestly?  Yes, I cared.  Thank you for those resources.

memset_s() is the right thing, at least w/r/t this specific
issue.  I look forward to the day when it is widely enough
implemented and reliably available to be the simple solution.
That day has not yet arrived, as the libsodium code
demonstrates.

Because I also went and looked at the libsodium code.  It's
good.  It checks for the availability of memset_s and calls
it if it can.  Then it checks for the availability of the
Windows not-quite-equivalent and calls that if it's available.
Then it falls back to the same thing I was doing with a
volatile pointer to memset.  If and when memset_s is more
widely implemented it will be a viable solution; as it is,
it's better than what I was doing.

However, I took another bit from the list and implemented it,
and expect to find nothing that reduces it.  The program
isn't allowed to cheat on I/O, and I can do transformations
on the buffer (such as XOR'ing it with /dev/urand output)
which destroy the information in it - and which can't be
skipped because I then make _use_ of the transformed values
when I turn around and write them to /dev/random.  A minor
variation on my initial idea, but simpler to implement.

/dev/random can always use some more mixing, right?

Of course even these operations aren't *absolutely* required
to be done in the same buffer overwriting the old data, either,
as long as the "same" values get written back to dev/random.
But if the most *efficient* way to do these ops and get these
values is to in fact overwrite the buffer, I don't think I
should need to worry about an optimizer cheating its way
out.  At least not before memset_s is ready to take over.

Of course, before I call that I'll check for memset_s.

				Bear



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160911/6e9d6009/attachment.sig>