Thanks for your thorough reply, to be honest I hadn't thought about those issues.
In the spirit of using already developed solutions I reckon truecrypt's successor, veracrypt, must have been given some thoughts, what were the conclusions? In what way is it unsuitable for our purpose? Regards, On 27/04/17 11:34, Andrew Gallagher wrote: > On 2017/04/27 08:10, forgottenbeast wrote: >> This way we would be able to write some random data here and there in >> the persistent volume (random locations) at every boot without taking >> much risks regarding the integrity of existing persistent data. Either >> there IS a persistent volume and the encoding could deal with it or >> there isn't and then who cares? > > The only reason to zero (randomise) an encrypted partition is so that an > attacker can't be sure how much data has been written to it. In > particular, they shouldn't be able to determine whether it has ever been > mounted - this provides herd cover so that I can plausibly claim that > any data on the partition was made entirely automatically (and randomly) > by Tails and no I don't know the password for it, honest. > > But a random pattern of writes is easily distinguishable from a real > filesystem until the partition has been almost completely filled - and > by this point if you've been writing in random locations you've > certainly overwritten your error correction codes many times over. If > you haven't been mounting (and thereby preening) your encrypted > partition on a regular basis, you may be beyond recovery. > > A better plan might be to a) randomize only fully-zero blocks, and b) in > the same order that a real filesystem would allocate them. That way the > disk looks more like a real disk, even at intermediate stages. And the > chances of real data getting encoded to a fully-zeroed block are > vanishingly small, so you don't need error correction. > > There are buckets of problems with any such approach though. For > example, in a real filesystem not every block that is written gets fully > written - the last block in each file will in general be only partially > used. Inode blocks will also have a different pattern of usage than data > blocks. A statistical analysis of partially-written blocks may be > sufficient to fingerprint a dummy filesystem. > > And it gets worse. For example, an attacker could use the amount of > nonzero data on the disk to determine that a particular Tails install > isn't new. If Tails wrote random data to the encrypted partition at a > predictable rate, one could make a guess at how long a particular Tails > drive had been in a running state, and so distinguish a regularly-booted > Tails disk from a freshly-downloaded one. That in itself may be > problematic - and is an *extra* leak over and above what Tails leaks > right now by default. This not only changes the threat model for those > who use encrypted partitions, but also for those who don't - and should > probably therefore not be default behaviour. > > But if it's not default behaviour, then you diminish the herd cover, > which defeats the original purpose... > > A > > > > _______________________________________________ > Tails-dev mailing list > [email protected] > https://mailman.boum.org/listinfo/tails-dev > To unsubscribe from this list, send an empty email to > [email protected]. > _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
