[Cryptography] Rubber-hose resistance?

[Patrick]

Peter Gutmann wrote on 12/19/2017 08:49 PM:

> Howard Chu <hyc at symas.com> writes:
>> Peter Gutmann wrote:
>>> I cross borders with a wiped-clean laptop and scp in anything
>>> work-related that I need once I get there.  That seems to be a common strategy
>>> among IT-savvy travellers who are worried about travelling with
>>> NDA'd/commercially sensitive material.
>>
>> I do this too. But just out of curiosity, what do you use for ssh credentials
>> when traveling?
> 
> A password.  That's the one thing that's completely deniable (when it's used,
> as in this case, to scp something over from some random server at some random
> IP address).


So just enable password authentication on the server, instead of
restricting the server to private key only authentication.

Use a strong 128-bit memorized password (e.g. from Diceware or using Ray
Dillinger's technique) to ssh into the server.

Travel with an unencrypted laptop which contains only files that you
don't mind other people seeing.  That's probably better than traveling
with an encrypted laptop that's totally clean.

When you get to your destination, you may rsync/scp any sensitive files
from the server to your laptop, using your strong memorized password.
If you can avoid copying them to the laptop, so much the better, but you
may need some of them stored locally on the laptop.

You can even store your GPG key ring and SSH private keys on the server
if you encrypt them with a different 128-bit memorized password.  Don't
use the same password as the one for logging into the server, because I
think that's revealed to the server when you log in.

Before you leave to return home, you need to delete all the confidential
information from the laptop.  To ensure no trace of it remains on the
disk, the simplest safe way I can imagine is this:

$ cat /dev/urandom >tmp1
# Now wait until you run out of disk space.

$ gpg --print-md sha256 tmp1

# Now wait for gpg to hash the many gigabytes of random data.
# This ensures that it was actually stored on disk.  Well, not
# exactly.  You might want to reboot the machine first, then
# compute the hash again.  When you see the same result, it is
# safe to say:

$ rm tmp1

# And thus reclaim your disk space.


-- Patrick