[Cryptography] [Crypto-practicum] Secure erasure in C.

[Henry Baker]

At 09:25 AM 9/8/2016, Kent Borg wrote:
>The optimizer isn't so perverse as to reverse engineer random(), is it?
>
>I like using random (-ish) data for things like testing disk speed or network speed or RAM bandwidth, because zero is a common thing to cheat about, some subsystem recognizes what you are doing and agrees to pretend the data is now zero, effectively doing some really efficient compression.  As memory subsytems get more and more like disks, they might start doing these tricks, too.  And as has been mentioned, with virtualization sneaking in without always telling you, you aren't just doing battle with the optimizer; your zeros might get deduplicated with other's while your real data lives on, sitting there, itself trying to be deduplicated with completely unrelated data belonging to completely unrelated customers.

Disks are almost gone, so we're talking about flash technology going forward.

The problem with flash is that you're typically separated from the actual flash memory by a proprietary layer (FTL?) that is free to do anything it pleases -- including performing as much compression (including deduplication) as it likes.

So you can assume that every flash memory is also compromised, and will look for (and squirrel away) interesting data for later exfiltration.

Include *Flint* (as in Derek Flint; Google it!) in your list of attackers, along with Eve, etc.

It's past time to consider some form of ORAM for flash memory...

Also, consider some form of bit-slicing, so that no single flash memory chip can see the whole memory reference string, nor the whole memory bus.  This will force multiple flash chips to at least cooperate in order to attack the stored information.