Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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
- If you need 8 MI300X's for a month to do ROT13, then you're doing it wrong.
- 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!
by maxprimes - 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 jmclnx - But this partition would be visible.
The OP had a version that is invisible.
by ted_dunning - Hmm, a partition of any sort has mapped the territory.by mixmastamyk
- > "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.
by Schlagbohrer - 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.by tim-projects
- Not very practical for an USB device used to move data from one computer to another.by dolmen
- Rule no. 1: you don't announce your security by obscurity methods :)by megous
- 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 Retr0id - 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.
- Probably better just to use a veracrypt hidden volume, and preferably not a SSD.by jp191919
- 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
by imglorp - 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 tlhunter
- That is actually what my company built. The primary purpose was for encrypted messaging, but it also acted as secrets store and password manager. The great thing about it being built into the keyboard is there is no chance for a rooted host to intercept passwords/messages etc.by jrexilius
- 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
by rsingel - 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.
by tptacek - At the risk of being dumb, wouldn't an easier solution be physical? ie have a usb stick with two actual "disks" and a an appropriately obscured physical switch to define what plugging it in actually does?
Again, this isn't going to beat someone who knows you've got something to hide, they can physically deconstruct/analyse the drive, but at least it's not going to be found by automatic scanning/software etc?
by Ntrails - This is probably fine for evading local cops.
I'll also note that anyone plugging this into a forensics machine is going to have a bit of a dilemma: Perform write tests, or not? Because if they probe it with password:... attempts to check on timing leakage, that's potentially damaging evidence.
by phyzome - > 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.
Time to bust out the old "Can't tell if this MP3 is a steganographically important encrypted file or just a Nurse With Wound EP" trick then.
- One possible trick: round down the normal volume size to the nearest 1Gb and encrypt it (who doesn't use encryption today?!?) and use it for non-secret data with a password that you're willing to divulge if pressed. This is innocuous enough.
Then use the rest of the drive (~1Gb) for a hidden TrueCrypt volume with a secure key.
by cyberax - > 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.
How would those scanners work? If the device presents itself as a bog-standard usb drive, with all the same identification strings, etc., and the hidden volume is completely inaccessible until triggered (e.g. like swapping on sd card for another), it seems like such a scanner would have to rely on things like precise timing and performance characteristics vs what the drive presents as, and there are a lot of legitimate USB drives out there to characterize.
Edit: and if that's the case, maybe pick a lower-performance drive to mimic (and use its case). Then have some kind of characterization step to add custom delays to match its timing and performance characteristics.
> (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 agree. What's the point of doing on-device encryption? Seems like this device should only do the volume-swapping bit. Once it "it unmounts [the unhidden section] and remounts the second hidden section, you should have to decrypt that hidden section with soemthing like VeraCrypt.
by palmotea - > If you're using off-the-shelf "hidden" encrypted volume schemes, you're not going to be evading state-level adversaries;
I kinda assumed this was a solved problem now, up to the information-theoretic limit. Just create a FAT32 fs (for example), put some boring decoy files on it, and then unmount it. Traverse the FAT to map which blocks are in-use vs not-in-use, and use the not-in-use ones to store your encrypted data in some arbitrary header-free indistinguishable-from-random format. The result should look just like someone had set up a FAT filesystem on top of a securely erased drive.
If anyone ever mounts and subsequently writes to the FAT volume they'll clobber your data - oh well.
The remaining issue is that you need some special software on the host to mount the hidden volume, which itself raises suspicions. This could be solved by bundling it with OSes by default.
by Retr0id - I often see comments like this on encryption related project. Depending on the reader you make what might be an essential point - but I also don't really know how useful it is to say it here. The author makes no claims about what adversaries this should be sufficient against and is completely open about their constraints and decisions (allowing you to make the critique in the first place).
Basically evading a state-level actor is going to be hard. People do get lucky but to evade them in a straight-up contest you need to very clever (if it's possible at all). Given that, I just dunno how useful it is to emblazen warnings on AES-based encryption schemes that it won't fool the NSA. Either the person reading it is not technically equipped to evaluate the claims and may be scared off of a solution that protects against some adversaries while searching for an impossible zero-config state-proof solution. Or the person already knew as soon as they saw 'AES' that this isn't the project they need.
I don't mean to denigrate the inclination to highlight weaknesses like this - good communication around this is genuinely challenging.
by aeturnum - >If you're using off-the-shelf "hidden" encrypted volume schemes, you're not going to be evading state-level adversaries;
This would evade 99% of them.
Most "state-level" adversaries are just high school dropouts working border jobs told to "investigate suspicious things".
I once had a police officer literally raid my room for drugs during a massive party we were throwing in university, for example.
They took everything. They found everything. Everything except for the $1,000 piece of drug paraphernalia I had sitting right out in open view in the middle of the apartment... the Volcano vaporizer.
It didn't look like anything they had seen before so they didn't think anything of it.
Same would be true with this USB drive in 99% of border crossing privacy invasions... plug in USB, ask for password, read it/copy it/whatever... they're not taking it apart and performing open heart surgery on a $5 USB drive at the border.
They might throw it out... or keep it or something... sure... but in general... this is a hell of a lot better than a regular USB drive imho.