On Sat, 25 Jun 2016, agner_io wrote:

> But I believe making it harder for them to break our autonomy is way
> more important than any political means to win this arms race... As
> your also noted, using encryption schemes like this does increase
> the need for scarce resources and knowledge about the situation.
> Thus, this works well either way... The key point is "scarce
> resources",

yes, one approach doesn't excludes the other. I totally agree with the
goal being important and with your assesment on resource consumption.
yet if this gets mainstream is rather trivial to make a bootable stick
that does just block-device analysis, for the average-joe cop will
just mean "take the laptop, stick on boot, eat donut, watch screen"
while one is being held in a room for an amount of hours inversely
proportional to the speed and size of harddisk.

I recommend instead, especially during difficult travels, to hold
crypto volumes online and separate the keys, retrieve them on
arrival. Anything like transfer.sh works well for that, as one doesn't
needs to trust the host and doesn't needs to provide proof of carrying
crypto.


however, I'm considering to adopt Amir's approach to header removal
and in-file offset indexing as an option for Tomb 3 development.
So far in Tomb we are keeping volumes that are 100% LUKS to allow
opening them also with other software (for instance ZuluCrypt now
supports them with a plugin), but thats it. Veracrypt doesn't even
considers compatibility with other programs, even if its a low hanging
fruit. I think there is too much competition-minded development out
there to get any advantage out of compatibility. So perhaps its OK to
fiddle a bit with LUKS in order to make it less detectable.


ciao