Plausible deniability

[andrewgdotcom]

We could use t-c-p to address Tails feature request 5929 [https://labs.riseup.net/code/issues/5929] if we had:

a) a "deniable" option to tcp-helper to fully zero the encrypted partition before creating the filesystem. (#4) (done!)

b) call "deniable" instead of "new" from t-c-p by default. (#5)

c) a feature in t-c-p to detect which device has just had tails installed and use it (#6)

d) allow blank --skel parameter to t-c-p. (#7) (done!)

e) an option to t-c-p to silently use a random password instead of prompting. (--randpass) (#8)

f) an option to t-c-p to force a call to liveusb-creator even if there is an existing tails drive attached. (--force-install) (#9)

We would then be able to install tails on a second drive with a default deniable FS by cloning nothing to a new persistent partition. The following changes to other packages would then need to be made:

1) call t-c-p --force-install --randpass --skel from liveusb-creator-launcher instead of liveusb-creator directly

2) call t-c-p --force-install --randpass --skel from persistence setup

[andrewgdotcom]

Initial experiments in randomising a persistent partition on my test laptop (a bit crap, but not unrepresentative) give a wait time of about 4 minutes/GB. If we used /dev/urandom directly instead of zeroing through the encryption layer it might be faster - but also less deniable if /dev/urandom's output is in any way fingerprintable (e.g. through entropy starvation).

[andrewgdotcom]

Due to wear-leveling on flash devices, it may be possible for an adversary to determine how much data has ever been written to a device, not just how much data can be written. This can be partially defeated if we only zero a random amount of disk. However, if the user then writes more data to the disk than our random process will ever do, they are exposed. Thus the only way to be sure is to make sure that the disk is overwritten several times, plus a random %. This will be preposterously slow.