[xaduha]

> Unfortunately it's not really practical to ask a user to type in 128 bits of binary every time they want to unlock their drive, so another approach has to be taken.

Yes, it's not practical to type that. So don't, stop using passwords for this as a main way to unlock it. You can add a password as a backup key, but the main one shouldn't include a keyboard. There are plenty of hardware options other than TPM that you can destroy if shit hits the fan.

[Vecr]

That's not legal in the US though, at least the "destroy if shit hits the fan" part. The only legal solution is a secure password that's never written down or told to anyone else, ever. I really do mean ever, if the police have given up on you but they later find out that there was no incriminating evidence against you on the drive, they could charge you years later for obstructing the investigation. You and your lawyer need to come up with a glomar response strategy (i.e. "neither confirm nor deny") that there is anything on the drive that could incriminate you. You are not protected from providing the data/password if the contents incriminate people other than you and not you, so never say under oath that there's nothing incriminating on your drive, because they will make you prove it.

[_cenw]

I found that running tang[1] at home and needing to decrypt that box (can be a Pi or whatever) requiring a complex passphrase is very sufficient. You can even just unplug it at night if it makes you sleep better.

https://github.com/latchset/tang

[xaduha]

That's usually where people bring up plausible deniability, off-topic and was discussed to death elsewhere anyway.

https://en.wikipedia.org/wiki/Deniable_encryption

[Vecr]

I don't think deniable encryption is needed, you just need to not say under oath "there is nothing on the drive that could incriminate me". If you say that you lose your protection and they can force you to provide the contents. Destroying keys, including wiping a LUKS header, wiping a TPM, destroying a USB hardware security key, etc. is destroying evidence and a crime. Not providing your really long password is not a crime, as long as there is some doubt (doubt you and your lawyer can carefully cultivate) regarding the fact that nothing on the drive incriminates you.

[xaduha]

> Not providing your really long password is not a crime

What about not providing a PIN? How is that different from password? Proper PIN protected smartcards will lock you out after several wrong attempts and would require a PUK. And you might not remember that, genuinely. What then?

[Vecr]

Intentionally entering wrong pins to lock out is probably destruction of evidence, and pins are so short I would not trust them. Just have an at least 15-length base32 password that's randomly generated with `echo "$(openssl rand -base64 20 | base64 --decode | base32 | head -c 15)"` or whatever. You might want it to be lowercase instead, or base64 for more entropy. That command should be secure on OpenSSL 1.1.1 or later, and combined with argon2id over 4GiB of memory and 12+ rounds, should be pretty much uncrackable.

[xaduha]

You don't need to trust PINs, they aren't passwords in technical sense. And you don't need to enter wrong PINs either, if someone else tries they would reach a limit very soon.

It's all seems pretty arbitrary to me as to whether something is considered destruction of evidence and it's very US-centric anyway. So I'd say yes, deniable encryption is needed. If they decide you're not playing ball, then you'll be punished. The difference is whether they will use a legal system for that in a First World country or something else if you're not so lucky.

[1827162]

In theory you could store it both offsite (using a hidden Micro SD card) and on your phone simultaneously, with a special key combination, e.g. pressing Vol Up + Vol Down + Power causing the phone to be rebooted, and the key erased from RAM... So in that case you would need to get the offsite copy, from GPS coordinates you have memorized, using a GPS receiver that is known not to leave any location information in it's EEPROM / Flash.

Of course all this info has to be double checked to see if it actually works, and forensic tools run against the phone to be really really sure the key's not being written to Flash in any way, or remains in RAM after a reboot.

[xaduha]

Sure, knock yourself out if that's your thing. But what I meant was basically "power user" level devices, like what systemd-cryptenroll lists. So fido2, pkcs11 (smartcards and tokens) and tpm2. If you want to bury any of them in the woods, I guess you can.

https://www.freedesktop.org/software/systemd/man/systemd-cry...