- If you're using off-the-shelf "hidden" encrypted volume schemes, you're not going to be evading state-level adversaries; if you can find these projects and conveniently use them, state vendors can and will write scanners that find them. They're paid to do it; new detections are how they get to charge for maintenance and new versions.
Then you're down to two issues:
(1) Concealing an encrypted volume jacks suspicion way up; whatever pickle you were going to be in if you just kept an encrypted DMG on your desktop, you're trebly in now.
(2) Your actual security comes down to the strength of the encrypted volume, and this is 20-year-old encryption. He can't use a memory-hard KDF because of his BOM, which, like, fair enough, but that doesn't change the fact that this KDF is probably ~50x faster than standard bcrypt hardness and on realistic human passwords is probably crackable in minutes-to-hours on a dedicated rig.
I winced particularly at the observation that the hardness was set where it is because of how long it takes to open the encrypted volume on this hardware, because whatever scheme is being used to run the KDF now, an attacker won't bother; they'll just copy the bits and attack them on serious hardware.
Point (1) isn't meaningful if your adversaries aren't states. It might make sense to have a hidden encrypted volume for the same reason you'd want an encrypted safe. But point (2) applies to everybody.
- Just chiming in that there are lots of threats that aren't state level attackers. In fact for most people the threat is never gonna be the border guard. It's your parents, an abusive partner, a sibling, a school admin or an employer.
Just because something does work vs the NSA or the FBI, that doesn't make it useless
- It might make more sense to embed the encrypted volume in some generic USB device. Require some condition to be true before the volume appears to the host, otherwise it's doing power or camera stuff.
A drive would draw more scrutiny than a camera or powerbank or even a cable. https://shop.hak5.org/products/omg-cable
- I want something like this in a keyboard: a completely hidden drive that the OS cannot see until I type in a certain string of characters (password) to activate it with a separate string of characters to deactivate it.
by matheusmoreira
1 subcomments
- Plausible deniability requires people to believe that you don't know about any so called "hidden" volumes. That goes out the window once you buy Hidden Drive from Hidden Drive Company.
by Schlagbohrer
0 subcomment
- > "Many places don’t respect privacy laws, in certain situations you may be forced to unencrypt your media, or worse, assumed to be guilty. A Veracrypt hidden volume is useful in the former situation, but not the latter.
This is why I made Phantomdrive."
Can someone explain to me how this project is different than a Veracrypt hidden volume and also what he means that Veracrypt wouldn't help if you are assumed to be guilty? I thought Veracrypt hidden volumes aren't visible.
- There are other issues with AES-CTR - an attacker can flip bits at chosen offsets in the plaintext without knowing the key. For example, if they know (or can guess/infer) what offset the relevant portion of the `sudo` binary is at, they could flip the branch instruction responsible for password checking. This can be done in one step, as opposed to the multi-step plaintext recovery attack described in the article.
With XTS, the attacker is forced to completely garble a whole block at a time.
by tim-projects
1 subcomments
- Reading this made me think that a good solution would be to write your own filesystem as a mod if an existing system. It just needs to differ enough from existing recognised systems. Then nobody would be able to read except you and the encrypted data effectively doesn't exist. It just would show up as an unreadible partition.
- We know that crooks are selling fake drives where the size is over-reported. Shouldn't something that tries to be sneaky under-report the size instead? Not just in the partition.
by purpleidea
0 subcomment
- This only makes sense if the underlying thing that gets exposed after you put in the password is a block device... I'd want to then be able to have that encrypted with LUKS myself, I don't want to rely on this homebrew stuff.
- Just a heads-up, your blog post has a broken link for
> As for the security of the device, I’ve verified things with functional tests like this
Otherwise great project!
- Another day, another one of these projects.
>With Phantomdrive, hopefully you’ll slip past authoritarian government representatives, corrupt police, and anyone else that doesn’t respect basic encryption rights.
Apart from the SD card on the board making it obvious something is going on, and the iron bar comes out
by monster_truck
1 subcomments
- Might as well be rot13.
If you rented 8 MI300X's or the nvidia equivalent, I don't even think an unreasonably long password would matter.
It should finish quickly enough that you would be upset with all of the money you have now wasted by having to commit to a month of utilization
- Rule no. 1: you don't announce your security by obscurity methods :)
by jrexilius
1 subcomments
- Good stuff! If I remember correctly there was company at Defcon selling memory cards that had this feature built into them a couple years ago?
- Could use an Opal or Pyrite drive connected to a USB caddy and sedutil-cli to manage it.
- Why not decouple the special card reader from SD card instead then? I mean it's unsuspecting already, but it probably even less sus since readers are cheap and never a target.
by pessimizer
1 subcomments
- Can this be done on boards with the same layouts as known commercial USB keys i.e will imaging just show this to be what it is?
by charcircuit
0 subcomment
- >Let’s now assume our attacker has a really powerful machine, has gotten your salt and now will compute their own “table”.
You should be using a TPM so such an attack is impossible. The TPM should be what is rate limiting the guesses. You don't need a KDF here.
- A very interesting solution!
If you can do without Windows, I would say formatting a USB with a first partition as an 8 gig DOS partition and a 2nd partition as Linux LUKS may work just a good.
But a few people may know about Linux. So if on OpenBSD, you can create a second OpenBSD encrypted partition. I think that will probably look like garbage to 99.999% of the people you may be hiding from.
Be aware, if dealing with a sophisticated Gov agency, all bets are off.
by sandworm101
1 subcomments
- Dude. Veracrypt. Hidden volumes. This is an old and well-solved problem set.
- [dead]
by sscaryterry
1 subcomments
- Encrypted USB drives, there are definite legal uses, but like others have said, it raises suspicion.
- >Many places don’t respect privacy laws, in certain situations you may be forced to unencrypt your media, or worse, assumed to be guilty. A Veracrypt hidden volume is useful in the former situation, but not the latter.
> ...
>Due to AI demand the cost of eMMC memory is unusually high, so I chose to go with an SD card for memory. Someone will find your SD card if they tear it apart, but of course everything is encrypted.
So which one is it? It sounds like this is trading off between "having veracrypt installed on your computer" vs "having a custom usb drive". In other words, hiding something in software vs hardware. I'm not really convinced hardware is better. The hardware device is going to get discovered if the x-ray it, not least because of the super suspicious embedded sd card reader. Even if we concede that hiding in hardware is better, surely you can just use whatever trick to hide the software (eg. putting in a secret password mounts a second drive with veracrypt)? That way you don't run into the crypto issues that the parent poster mentioned.
Hacker News