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
> Tails-dev@???
> https://mailman.boum.org/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to Tails-dev-unsubscribe@???.
>
