[Cryptography] Shredding a file on a flash-based file system?

[Thierry Moreau]

Dear John:

Thanks for your extensive and most interesting answer. See below for a 
specific acknowledgment.

On 2014-06-20 00:10, John Gilmore wrote:
>
>> 						I would suspect that
>> the most fundamental optimization (not allocating new space when a write
>> request only turns "1" bits to "0") is applied effectively despite this
>> involved logic arrangement.
>
> This basically never happens.  First, you don't know whether the
> actual flash chip is storing your data "true" or "inverted", so you
> don't know if 1->0 or 0->1 is the fundamental write operation.  [If it
> was smart, it would decide to write each block either true or
> inverted, with a flag saying which, by counting the number of erased bits
> flipped in true versus inverted writes, thereby making the chip last
> longer.  But they probably aren't smart.]  Second, each block written
> is written with error checking and control bits, which are a hash
> value of the contents of the block.  In these bits you are almost
> guaranteed to turn a 0 to a 1 even if the contents of the block only
> turn 1's to 0's.  So EVERY write to a block of managed flash involves
> allocating a new block and putting the old block on the "to be erased"
> list.  The only place that flash controllers can probably do the trick
> of writing a block multiple times by only turning 1's to 0's, is in
> its own internal data structures that keep track of which blocks are
> in use.

Thanks for the bad news. This paragraph puts the last nail in the 
coffin, with convincing evidence (i.e. more than a mere "I would never 
trust vendors").

- Thierry