Threat model: average darknet enjoyer
Best combo I can think of is a TailsOS USB and Veracrypt with hidden volume to store secrets, however the wear-leveling on modern USBs could impact plausible deniability.
There has to be a way to be totally bulletproof in providing a password in a situation under duress while protecting yourself.
Is there a way to conceal an entire OS? Like have QubesOS in a hidden Veracrypt volume or something?
Things would be so much more simple in this regard just living in the US. Set a strong passphrase and boom that’s it.
1 Like
I wouldn’t store sensitive data locally if you’re that concerned.
The Opsec Bible has a workflow for deniability but I can’t vouch for it.
2 Likes
No.
No, someone with enough knowledge will always find the hidden volume.
2 Likes
There are deniable steganographic file systems, but I have never tried to use any nor know how well they work in practice.
1 Like
It lost a bit of credibility when it said “avoid Chinese products.” Practically all routers use Chinese components in some form. There is no evidence that GL.iNet products are insecure or unreliable. TP-Link, I can understand the concern, but GL.iNet?
3 Likes
There’s a lot of questionable info.
2 Likes
Im a little off-topic here, but this is exactly why i like secure cloud-based setups…not only more convenient, but in my opinion more secure in certain respects (such as this; risk of confiscation/coersion)… Of course it has its trade-offs, but i’ll take secure clouds over hardware with most things any day (these days)(authenticators, password managers, drives, etc).
2 Likes
Yeah because if you use the cloud anonymously, it’s not hard to store/remember credentials meaning it’s effectively deniable. Authorities don’t see any hardware concealing it and they have no proof that you have any data.
2 Likes
Also, its way more convenient. And if you get a little crazy one night and wake up in a foreign country with absolutely nothing, you can at least get some things rolling digitally with your two keys to the kingdom (auth and pw manager passwords), as long as you can find a device. Crypto, banking, comms, uber(?), doordash(
)
1 Like
Yeah I have that setup. It’s not 2FA, but it’s 2SV (two step verification).
It’s not that crazy of a scenario if you travel and lose your phone. It’s nice knowing all I need is any device to get into my accounts.
It would be more secure to have a 2nd factor instead of a 2nd step, but I’m not sure of a good one if you want the dropped in foreign country threat protection.
2 Likes
On the other hand can anyone that has physical access to the cloud server (e.g. hosting provider, law enforcement or people who break in) read everything.
1 Like
A cloud computer can not be E2EE.
1 Like
It’s encrypted on your device and then the encrypted data is sent to the “cloud”. The only ends where it can be decrypted are on your client because your client holds the encryption keys.
That’s what e2ee means.
No, if they break in, they only see encrypted data.
1 Like
I think there is a misunderstanding here.
With the phrase cloud setup I thought of a terminal server or cloud computer like this here https://shadow.tech/us/pro/
Not a normal cloud storage provider like Proton Drive.
2 Likes
Good point. Those are also an option. I was referring to data, which can be encrypted and hidden in the cloud.
1 Like
Your reply that started the misunderstanding reffered to pw managers, which is what made me think they were talking about an e2ee service, not a remote computer used for work or such.
2 Likes
I have a sort of wild idea. Others might know or find more reasons not to do this, but I just tested it and it does work in brief practice.
Your jurisdiction compels you to provide the password. It doesn’t demand the file work.
You could have a password-protected veracrypt container and then use a hex editor to change the binary of the header and mess it up so that it presents as a corrupted file. Just find a spot in the code you can remember easily (i.e. line 13, byte 13), and add a byte. The file will be corrupted and won’t open. Remove the byte, and the file is fine. Only you know which byte shouldn’t be there.
However, the easier it is to remember and change manually, the easier it will be to find from a casual analysis, as veracrypt containers contain a backup header at the end of the file. It’ll be easy to spot a mis-match on a deeper analysis. So either you have to find and change both header and backup header and hope for no deep forensic analysis of the OS, or just hope that a corrupted file is enough to make whoever is asking for a password shrug and blame whoever is trying to look at your volume and assume they broke it.
Also, the error that VC kicks starts with “Can’t open, probably wrong password, or…” and invalid file is towards the end of the list so it might be assumed that you’re simply not giving them the right password.
Alternatively, nest the eggs. Take a VC volume and corrupt it. Then put that in another volume with a few things that are low-risk if seen. One corrupted file isn’t exactly a massive red flag when a decrypted volume shows several files that are fine. The trend of a human to see a pattern might lead them to believe that your 4gb MKV of Shrek 3 is simply broken if next to working MKVs of Shrek 1 and 2.
YMMV. Backup your data before attempting
1 Like