My USB Drive Has a Hidden Encrypted Vault

Posted by machinehum 5 days ago

Counter286Comment163OpenOriginal

Comments

Comment by tptacek 3 days ago

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.

Comment by johnnyApplePRNG 3 days ago

>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.

Comment by tptacek 3 days ago

This is self-soothing, not a real security plan. It doesn't matter how competent a security agency is, because there's a whole ecosystem of vendors selling into that space; knowledge of how to attack encrypted disks like this is outsourced, and, importantly, those firms have incentives to mop up even random stuff like this, because vendors will be selected in part based on lists of how many different circumvention and privacy tools they can detect.

Comment by broken-kebab 2 days ago

You are right in a laboratory way of let's-assume-perfect-adversary, and you're not in a how-it-really-works way. I simply have my own RL exp in a bad repressive country on this topic, and my claim that e.g. hidden volume works most of the time. Like any tech it will stop being useful eventually, but it has been saving people for quite some time.

Why is that is a long story. And it includes both general inefficiency of state apparatus, but also the fact that repressive systems aren't optimized for getting evidence (or just correct information) in most cases.

Comment by LorenPechtel 3 days ago

This isn't stand-up-to-state-actors security. This is keep-state-actors-from-noticing security. They know you're guilty, they'll get it. The XKCD version of password cracking works no matter how secure your hardware.

But while states realistically can crack most anything it doesn't mean they can crack *every*thing. There are simply too many flash drives crossing the border every day.

But there is a big flaw I see: 8gb. You're carting around an 8gb flash drive these days??

Comment by tptacek 3 days ago

We're talking about exactly the same threat. What I'm pointing out is that state adversaries won't have to "notice" this; all they'll have to do is plug the device into a standard commercial forensics scanner product --- and we're stipulating that they're plugging the device in already (else what does it matter what bits are on it).

They pay other people to notice this stuff for them!

Comment by whizzter 3 days ago

I think part of the entire design is that it's quite hard to detect.

1: Reads/Writes are just routed to a COTS SD-card. 2: Unless the (correct?) password is detected in the write-data that starts the disconnect procedure.

The only way to detect it from what I can see is to profile writes then append a "password:" string multiple times to measure the write-delay, only works if the CPU cost is large enough to overtake the SD-card measurably and some constant-time optimizations should make it more or less undetectable.

It's a clever design and I think it should be possible to optimize to become more or less unrecognizable.

Comment by 05 3 days ago

> The only way to detect it from what I can see is to profile writes then append a "password:" string multiple times to measure the write-delay,

- Have the first check be a simple 8bit hash that filters out most passwords in microseconds, or use a customizable prefix instead of “password:”.

- have your password checking thread run in background at idle priority

- when you get an async password match, force usb disconnect and reconnect and the system will rescan the bus and mount your real drive.

Short of adversary dumping drive firmware (or them figuring out your hn account t, having a LLM scan the messages and finding this conversation) it’s not really easily detectable..

Comment by ralferoo 2 days ago

It's even easier to detect from that. From the project writeup Q&As: 'The firmware snoops for the string "password:xyz" and inhibits the write of "xyz". Otherwise, yes this would be very insecure.'

So detecting this drive is just a matter of writing "password:anything" to the drive, unmounting, remounting and checking the file you just wrote. If it's not what you wrote, then you have detected the existence of this drive.

The parent comment was correct that if this was mitigated by testing if the key is valid then you can detect it by checking for timing differences between writing a sector that starts "password:" and one that doesn't. Moving the password check async just means that you run the risk of having the real password written to the SD card before it was detected.

If you buffer that sector from being written, then you might be able to detect it because the write was faster than expected, or if you write the modified version and go back and overwrite it with the original if the check fails, then you will slow down a different subsequent access, again which would be detectable. This would also invalidate one of the design goals of never keeping the password in memory, only the derived key.

Having a customizable prefix is possible, as the project is open source. Personally, I'd be tempted to make this possible on the base build by storing the prefix in the hidden area of the SD card.

Comment by LorenPechtel 1 day ago

Simply dismounting it won't prevent the stored write. You would have to dismount and then quickly power down. The safe-to-remove indication on Windows takes at least that long.

Comment by femto 3 days ago

If I was building a black box to detect hidden data on a USB stick, I'd include a feature whereby it measures power consumption and flags USB drives that don't consume the expected power for that type of drive.

Comment by kulahan 3 days ago

What an unreasonably complex device to imply you’re going to make 50,000 copies of and ship out to every border agent in the nation after telling them every SINGLE flash drive crossing the border MUST be scanned. That’s so much wasted time, energy, and money. Are you building a similar device for SD cards? HDDs? SSDs? External drives? You’re going to build a database of exact charge draws for every device in existence which happens to have some form of storage on it?

Fucking up every single import and traveler on the off-chance one in seven billion scans detects one of these devices and, further, carries some data the US cares enough about to chase down to this degree?

No. Nope. Nuh uh. Insanely unreasonable. You will get ONE at a station, which you only bother to use if you can convince your $12/hr employee to even give a shit. Literally an insane proposition.

Comment by femto 3 days ago

A complete USB voltmeter/ammeter costs $1.

https://www.alibaba.com/product-detail/MX17-Current-and-Volt...

Ignore the case and connector, on the basis that the circuit will be integrated into a larger scanner, and the cost will be substantially less. Most USB controllers already monitor current, so even the <$1 circuit probably would not be needed. The main cost would be the manufacturer putting together a database of power consumption figures to allow a pass/fail test.

Law enforcement, airports and so on already boxes to scan USB devices. They don't use them for every USB drive, just those that they decide they have cause to scan.

Comment by marysol5 3 days ago

I'm confused here, what are you trying to detect?

You're not going to get the uA level of detection to be able to decipher between a R/W operation and some sort of crypto in the CPU with these cheap components.

Comment by LorenPechtel 1 day ago

Power use is not deterministic unless it's in a known state. The power hungry circuit is the erase and that's mostly a background thing.

Comment by marysol5 3 days ago

laughs in that flash drive I have that just gets hot instead of working

Comment by fragmede 2 days ago

https://usbkill.com/

Comment by tptacek 3 days ago

Can you flesh that out? If I've missed something and oversimplified the design here, I'd want to clarify that!

Comment by whizzter 21 hours ago

The encryption/hiding is done by the firmware, hence..

1: The drive more or less looks like any boring old usb-stick, it isn't even uncommon for cheap fake Amazon sellers to sell sticks with SD-card's as faked large drives (so even with X-ray inspection it doesn't look too much out of order).

2: To a computer, since the firmware presents a regular UMASS device, there isn't anything telling the computers over-the-wire protocol that anything is amiss (since the real size is hidden by the firmware and regular accessible blocks just behave normally).

So, short of an intrusive teardown of the device to read the true size of the SD-card and even knowing the presence of a hidden volume, the only over the wire that can help discerning this from a regular drive is timing attacks (And as you notice from this thread, people are jumping on to suggest solutions to minimize or even remove that).

Comment by awesome_dude 3 days ago

> They pay other people to notice this stuff for them!

Money, even at state level, is not some infinite resource (and neither is time).

States put effort into what they consider worth investigating - no state strip searches every incoming traveller, and goes through every item in their possession - it's possible for them to do, and if they did they'd find a hang of a lot more contraband, but it's costly, time consuming, and politically risky.

Comment by mediaman 3 days ago

He's saying they just plug your USB stick into some gizmo sold to the state, and it's going to find enough to escalate it.

If the idea is that there's no point in encrypting anything on a USB stick, and you just hope they don't look at it at all, sure.

But there is no threat model here that includes "check the USB stick" and does not automatically lead to finding and breaking "hidden" content.

Comment by NetMageSCW 3 days ago

Try to explain how the hidden content would be found? It effectively doesn’t exist until the password is in place. It isn’t hidden, it isn’t connected at all.

Comment by mingus88 3 days ago

I’m no expert but I can imagine a scenario where an x-ray scan can notice an SD card embedded into the controller and flag that for follow-up

SD card the author says was added to offset the cost of eMMC but would presumably stand out as anomalous with whatever AI is classifying the scan

Comment by marysol5 3 days ago

Yeah the SD card is going to be glaring for anybody with actual investigation into this device.

But saying that, the sheer amount of fake flash storage out there now, that's just a glorified USB-SD reader in a box.

Comment by awesome_dude 12 hours ago

I mean - if there are multiple sdcards in the device - and they each contain a hidden partition - how is the X-RAY going to determine that the reported 5GB (or whatever) isn't matching the devices actual 7GB (for example)

Comment by otherme123 3 days ago

> But there is a big flaw I see: 8gb. You're carting around an 8gb flash drive these days??

What is the problem? I have promotional flash drives from 1 Gb up to 8 Gb, that I use to store music for my car, or to carry pdfs to print in shared printers. I don't care if they break or get lost. I know people that carry similar promotional items with similar capacities. What is suspicious about 8 Gb drives? Maybe the lack of external branding, like "SanDisk" or "Walmart"?

Comment by marysol5 3 days ago

I found a 8GB USB drive in my pocket after doing the washing the other day (RIP).

I'd been using it to boot the debian installer from.

Comment by raddan 2 days ago

You should check to see if it still works. My favorite thumb drive went through the washing machine several times and still works.

Comment by LorenPechtel 1 day ago

Most drives are bigger. I have some around that size--but they're old.

Comment by zyx321 2 days ago

It would be less suspicious if the drive advertised 512GB and returned garbage data for any read past 8GB

Comment by giancarlostoro 3 days ago

> The XKCD version of password cracking works no matter how secure your hardware.

Lavabit would like to enter the conversation.

Comment by ThePowerOfFuet 3 days ago

The xkcd approach worked in that case; the wrench in that case was legal, not physical, but boy would it have hurt nonetheless.

Comment by giancarlostoro 3 days ago

He deleted everything ultimately. He printed it out in ultra tiny font in order to comply, but it was nearly impossible for law enforcement to use it. The FBI never decrypted the files.

Comment by tptacek 3 days ago

It's hard to tell if you're being serious here. At the end of the day, Lavabit's security came down to... the FBI's inability to read an ultra tiny font?

That's not the actual story (like, that happened, but all it did was provoke the DOJ), but it's remarkable to see someone cite that as a success for Levison.

Comment by akerl_ 3 days ago

What about the other Lavabit users whose data he had handed over previously, before deciding to say no?

Comment by marysol5 3 days ago

FBI = legal

Comment by matheusmoreira 3 days ago

> It didn't look like anything they had seen before so they didn't think anything of it.

You will miss your government's incompetence when they start rectifying these failures. I know I do.

They are the tyrants who oppress us with a clean conscience. They never rest and have infinite money. Their occasional episodes of bumbling incompetence is the only respite, but those won't last. Especially now with AI to think for them.

Comment by pixl97 3 days ago

Ya. Especially when were at the point they know you know about hidden encrypted disks because they have your full internet history for the last 10 years.

I guess it's human nature to build the Torment Nexus.

Comment by brookst 2 days ago

Actually I’ve found some flaws in the Torment Nexus and have a PR to improve it.

Comment by 3 days ago

Comment by dijit 3 days ago

I was arrested once and interrogated in great detail about how to access the data on a bluetooth usb dongle.

Just to say, I know what you mean.

Comment by marysol5 3 days ago

In court I had to explain how a TPM works, to the prosecution.....

Comment by ozim 3 days ago

You are conflating „state level actor” with „police level action”.

There is a world of difference if you get searched by your local police and a country level agency.

There are military units dealing with forensic investigations they have 100x or 1000x more budget and much smarter people.

But they don’t care about some drug dealers. They don’t waste time on silly stuff.

Comment by marysol5 3 days ago

The military really doesn’t have "much smarter people", the intelligent people are all in private industry, then LEO, THEN the military.

The military is stuffed full of grunts who are just there for the pay, and in many cases, conscription.

You can throw all the money you want at something, it doesn't make it work, just look at the US military

Comment by fhdkweig 3 days ago

> Most "state-level" adversaries are just high school dropouts working border jobs told to "investigate suspicious things".

The state-level threat isn't just about the direct employees' competence. They also have the funding to purchase tools made by people who really know what they are doing. Think of things like Pegasus spyware or Darksword iPhone hacking.

I can believe that a keystone cop wouldn't know the difference between a bong and a flower vase, but border crossing guards will know a USB drive when they see one and pass a copy of it to someone who knows what they are doing.

Comment by NetMageSCW 3 days ago

A copy of this USB drive would show nothing from the encrypted portion.

Comment by johnnyApplePRNG 3 days ago

Pegasus spyware operations cost something like $500k a pop, last I checked.

Comment by fhdkweig 3 days ago

That's kinda the defining characteristic of a state-level threat. They have all the money they could ever need. The reason Pegasus can charge that much is because there are people able and willing to pay that much.

Comment by tptacek 3 days ago

Can you check again and share where you're getting that number?

Comment by ninju 3 days ago

It may have gotten cheaper

https://prodefence.io/news/pegasus-spyware-operating-costs-c...

Comment by tptacek 3 days ago

Thanks! Per-seat licensing here checks out.

Comment by XorNot 3 days ago

Trying to keep data on a USB drive hidden long term is a losing game is the thing.

If you're intercepted with anything of value what you want is to rapidly destroy it.

This was the big problem I found when I was trying to figure out a secure way use Yubikeys: they're both long term unreliable, and short term impossible to wipe or destroy fast enough.

Literally a printout of 1 time passwords has better security properties in an adversarial situation.

For a storage device what you want isn't a secure store, what you want is a pin pull or switch which wipes it instantly.

Comment by giancarlostoro 3 days ago

Anyone using forensic software can dump an image of your entire drive including all partitions, byte for byte copy. Just because you got away with being careless once doesn't mean this will work every time. If you don't want your files to be copied in encrypted or plain unencrypted form, don't bring them with you. You're better off re-downloading them over the web at that point.

Comment by ted_dunning 3 days ago

Unless they disassemble this drive, a forensic dump will only show the open partition.

Comment by marysol5 3 days ago

A cursory X-Ray would show the internal SD. This product needs a hardware re-design (which I've seen other projects do) to have onboard flash instead.

Saying that, any proper investigation would read the firmware from the flash and identify the decryption routing anyway

Comment by zyx321 2 days ago

It has an SD card because proper flash is expensive. Surely the people making "4TB" flash drives on Temu must be using the same methods, or else they will be soon.

Comment by stackghost 3 days ago

>Most "state-level" adversaries are just high school dropouts working border jobs told to "investigate suspicious things".

Even dumb cops know how to use a Cellebrite machine.

Comment by aeturnum 3 days ago

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.

Comment by tptacek 3 days ago

I'm generally pretty fatalistic about avoiding state-level adversaries. So, in a sense, it doesn't really matter how one thinks a security countermeasure is going to stack up against an IC attacker. The important thing is that people understand how hard this is to do, and take that into consideration before adopting tools like these. You can easily make things worse for yourself.

I think this post is a fun technical case study on its own. It only takes on urgency because it literally markets itself as a tool to slip past state adversaries. I think it's important that people understand that it isn't the state itself that's going to take the time to detect something like this; it's some commercial forensics vendor they use automatically.

Comment by rectang 3 days ago

A while ago I participated in security design for an open source foundation. (Security is not a specialty of mine, but I aspire to be competent enough for my role as a developer working in web dev and open source.) We attempted to design our processes to assure some level of defense against state-level threat actors despite assuming we could not keep them out of our network. The main goal was to ensure an audit trail in the event that our source repositories or release archives were compromised and changed.

Comment by PaulHoule 3 days ago

My first take is that it is terrible terrible opsec to talk about this sort of thing if you actually want to take it across a border or have any kind of "elevated" encounter with law enforcement or intelligence.

Like if they have good tools for profiling you from your posts they'll totally expect the OP to have some interesting hardware and stories to tell. Contrast that to just being some boring guy who has a cover story that happens to be true or the colorful character who doesn't really have anything to hide but who can keep spooks talking for hours.

Comment by cindyllm 3 days ago

[dead]

Comment by Retr0id 3 days ago

> 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.

Comment by ianburrell 3 days ago

Instead of FAT32, use the flash drive mapping. Flash drive contain mapping from sectors to blocks. This is used to deal with flash erasure, wear leveling, and failures. Custom firmware could map the real filesystem to bad blocks.

Does the forensic software read the whole physical flash drive or just the logical one? They might if they want to get deleted files. Can they detect that there are lots of failures?

Comment by Retr0id 3 days ago

You need the wear levelling system for actual wear leveling, otherwise the drive won't last very long. Competent forensic analysis can check the firmware and the physical flash contents, although most forensic analysis is not especially competent.

Comment by forlorn_mammoth 2 days ago

wait, so the device has "good" blocks and "worn out" blocks... sounds like a binary format to me, maybe you could encrypt the data in that format...

You can ship my genius award to me at X..x>X..X.

Comment by jandrese 3 days ago

Doesn't FAT have the concept of "badblocks" to handle the old days when sectors could randomly fail on drives and they had to work around it? It would only be slightly more suspicious but it would allow the drive to be mounted and used as a regular drive to avoid the even more suspicious unmounted volume issue. The data in the sectors would obviously be encrypted so it looks like random noise if someone does start poking around looking at it.

Comment by Retr0id 3 days ago

It does, but it's extremely unusual for the feature to be in use on modern hardware.

I thought of a much simpler approach though. Personally, it's completely normal for my USB drives to contain some OS installer dd'd to the first few GB, and to be wiped with urandom between uses. The installer .iso is typically immutable and will never expand beyond its initial size. Rather than mess around with block mappings, I can just use last n GB as a hidden storage volume. dm-crypt "plain" mode is headerless and can be configured to start from some offset within the underlying block device.

The only giveaway here might be forensic examination of the drive's internal wear-leveling data.

Comment by marysol5 3 days ago

>It does, but it's extremely unusual for the feature to be in use on modern hardware.

FAT is a filesystem, it isn't hardware. They're talking about the table storing numbers of bad sectors/blocks.

The system you just described is exactly what TrueCrypt did, where if you overwrote the capacity and into the "hidden" data, you'd end up killing the hidden partition.

Comment by Retr0id 2 days ago

Modern hardware tries not expose bad sectors to the filesystem layer at all, they are managed by the drive firmware (transparently remapped, until the drive runs out of spare sectors). Thus, you will ~never see bad sectors marked in the FAT on modern hardware.

Comment by pixl97 3 days ago

>This could be solved by bundling it with OSes by default.

Apple and Microsoft? I trust apple a bit more and MS none at all.

Linux is a bit different because the kernel is the OS, but only a small part of all its different packages. Also you'll have to watch it like a hawk because nation states will constantly try to compromise it.

Comment by palmotea 3 days ago

> 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.

Comment by StilesCrisis 3 days ago

Given that the name defaults to "Phantomdrive" I have a hunch that it is not as fully nondescript as you are suggesting it ought to be.

Comment by cyberax 3 days ago

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.

Comment by ErroneousBosh 3 days ago

> 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.

Comment by ButlerianJihad 3 days ago

There once was a time when I'd be on Facebook all day, subscribed to many groups and pages that published really dank memes. And I would enjoy laughing at these memes, and the dankest memes I would duly collect and forward to my mother who is a boomer.

And my mother would duly sift through these forwarded meme images for the dankest of the dank, and then she would eagerly forward them to her friend from church, who also had a large distribution list, and so that is how I became a conduit for the dankest GenZ Facebook memes to the boomer generations in another state.

And then I became a Cybersecurity educator, and our curriculum contained a module on steganography, and we all had the students do a proof-of-concept where they cryptographically embedded secret messages in innocent-looking photograph files.

And that is where my meme-sharing came to a screeching halt, and I deleted every meme I ever collected, and I unsubbed from every possible source, and I began completely ignoring memes, and my mother's distribution dried up. Good god that was absolutely shocking. I have no idea what sort, if any, secret messages I was responsible for, and I hope that we never ever find out!

Comment by dude187 3 days ago

I'm pretty sure the meme WAS the message. What other messages are being distributed through random meme sharing, where the recipient has to know it contains some secondary hidden message and requires the means to decode it?!

Comment by ButlerianJihad 3 days ago

It didn't matter; once I found out even the possibilities for steganography across a large catalog of JPEG images, it was game over for me. It doesn't matter if there were zero or five dozen secret messages in the files I forwarded. I didn't want to be a conduit for that possibility.

The risk, of becoming a mule, an unwitting accessory to some evil cause, was just far outweighing the rewards of sharing dumb crap with my mother, you know?

Comment by drugstorecowboy 2 days ago

But.. unless your mother or the people she was sharing them with were the intended target of the secret messages how would you be a mule? Do you think terrorists were depending on you to save the memes so that later they could break into your sweet meme stash and find all their evil secret plans?

Normally would not comment just to make fun of someone but this is just a wild take, how could you be sure that HN is not full of coded messages?

Comment by ButlerianJihad 2 days ago

You're begging the question that secret messages necessarily require "targets" to work or to be passed along. That is not true.

If your pastime involved trading envelopes with other collectors of envelopes, and you started passing along a bunch of sealed envelopes with unknown contents, how would you feel? Or if you enjoyed well-constructed cartons, and you found yourself trafficking in sealed cartons with unknown contents? That would basically make you a shipping, receiving, and logistics provider. Anything at all could be in those parcels. Why do it? Why open up to risk?

The main point here is that there was no point to my trading in memes. It was recreation; it was optional; it was totally a lark with my boomer mom and her audience. I had no reason to look at these memes and I had no reason to forward them on. Sure, the risk was very, very low that anyone "evil" was encoding "secret messages" or "targeting" anyone I knew. But since I had no reason to engage in this activity in the first place, why not quit? Why not just distance myself? Thereby removing 100% of the risk.

Comment by drugstorecowboy 1 day ago

To be honest with you, you haven't convinced me. Secret messages do in fact require "targets"... I would love to hear an example of a situation where someone might want to send a secret message with no "targets" in mind. For all you know, my replies are coded messages and you are providing the cover for it right now. And to use your example were I trying to traffic in something illicit, handing it to a random carton or envelope collector in the hopes that they will trade it again to the intended person would be an extremely risky and ineffective method of doing that, so ineffective in fact that I would never consider that to be possible. Someone attaching a package to the underside of your car and the target grabbing it when you park would be much more likely, would actually make sense, and still is not really a risk worth considering.

I don't agree with you at all, nor do I understand how your mind works, but I very much appreciate you taking the time to respond and respect your commitment not to facilitate anything nefarious even though we disagree.

Comment by phyzome 3 days ago

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.

Comment by marysol5 2 days ago

You do not do any writes in a forensics scenario. Especially if you want to make it stand in court.

You have to always keep a clean hashed copy, and then work on copies from there.

Comment by phyzome 1 day ago

You can't make a "clean hashed copy" of hardware.

Comment by Ntrails 2 days ago

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?

Comment by Dylan16807 3 days ago

You can compensate for not just 50x but 500x by adding 2 characters to your password. If that's the speedup factor, it's not itself a big worry.

Comment by tptacek 3 days ago

You can eliminate the problem entirely by using a random full-allowed-character-set password. The whole point of KDFs is that the password/passphrase is predictable (usually: by being generated from a seed dictionary).

Comment by Dylan16807 3 days ago

Random is important, character set not so much. And yes when I say 2 characters I mean random ones. Even 26x26 is plenty to compensate. Or you can add one random word.

Comment by tptacek 3 days ago

We're both saying the same thing: you can make the KDF irrelevant if you (as you just specified) use an AES key as an input. The entire point of KDF is that humans don't do that.

Comment by Dylan16807 3 days ago

No, what I'm saying is: If your password was good enough for a quality KDF, then improving it to use a 50x worse KDF is very easy. If the worse one requires you "use an AES key", then the good one pretty much also required you to "use an AES key". If the good one didn't require that, then the 50x worse one also doesn't require that. Generate a single letter and slap it on the end, or human-pick two letters.

50x is not the decider between allowing a good password and allowing a bad password. It's a tiny little nudge.

Edit: To put "little nudge" another way, if you have a 1-10 scale of password quality, most steps in that scale are going to be more than 5.6 bits apart.

Comment by SAI_Peregrinus 17 hours ago

To add (and agree), if you've got (say) a 10-word Diceware-style passphrase with ≥128 bits of entropy, the point of a KDF becomes solely for the domain separation that KDFs provide. That's not particularly relevant for the USB drive case, but it's very useful in the general case of deriving keys. If I'm writing encryption software for my own use where I know I'll be generating a secure (≥128 bits of entropy) passphrase, I just use HKDF or Blake3's KDF mode.

Comment by 3 days ago

Comment by machinehum 3 days ago

6x not 50x

I use 100k rounds instead of 600k https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...

Comment by amelius 3 days ago

Someone should write a disk formatting utility that randomizes the bits on your drive.

Now you can claim that any encrypted drive (which just looks like pure noise if done correctly) is a drive that was just formatted.

Comment by kevin_thibedeau 3 days ago

This is what GNU shred does. It has a high speed PRNG meant to avoid performance issues from directly using /dev/[u]random. Point it at your preferred block device or partition and let it fill your drive with entropy. With modern flash devices there is still the issue of hidden reserved space for block replacement but you will cover most of the drive. Reduce iterations to 1 since the default is meant for legacy hard drives and will needlessly add erase cycles to flash.

Comment by fhdkweig 3 days ago

Be careful in countries like UK which have laws requiring the decryption of any data they find. There are people sitting in jail because they couldn't decrypt the "random noise" on their computers.

Comment by amelius 3 days ago

This is exactly the point. If storing random data was the norm (formatting utilities would offer it) then it would be hard to make a case against it.

And it actually _does_ make sense for formatting utilities to offer it, as this is a good way to ensure that data is really gone after formatting (writing all 0s or all 1s could leave information at the physical layer; and any intermediate layer could not compress random data much so the data must be overwritten).

Comment by NikolaNovak 3 days ago

Fair warning; any links to specific cases (not the law itself)?

Comment by fhdkweig 3 days ago

This lists two unnamed individuals.

https://edri.org/our-work/edri-gramnumber7-16decrypt-data-ca...

Comment by marysol5 2 days ago

None of which are what OP is claiming

Comment by prmoustache 2 days ago

They don't mention anything about data being claimed as random noise nor the sentences.

Comment by prmoustache 2 days ago

> There are people sitting in jail because they couldn't decrypt the "random noise" on their computers.

Sources or names?

Comment by marysol5 2 days ago

Why do people just invent this absolute bullshit.

No there isn't. even people who have been prosecuted for refusing to decrypt data, it takes a lot of working by the prosecution to PROVE it's encrypted and not just "random data".

I'm from the UK and have been in court with encrypted data myself.....

Comment by ErroneousBosh 3 days ago

> There are people sitting in jail because they couldn't decrypt the "random noise" on their computers.

No, there isn't.

Comment by monster_truck 3 days ago

There literally are not. Anyone competent enough to be an expert witness will be able to plainly explain to everyone else how statistical analysis obviously delinates the difference between truly random noise and an encrypted volume.

Comment by monocasa 3 days ago

If there's a difference visible, that's a weakness in the encryption algorithm.

Encrypted data should be statistically indistinct from random noise.

It's an information theory thing. Everything in the ciphertext should be sitting at maximum entropy.

Comment by monster_truck 3 days ago

Try it for yourself brother, there is a plainly obvious difference between the random noise of writing garbage compared to a properly encrypted binary.

There are even statistically measurable differences in the garbage written across versions of a tool or OS, which, unlike the invented scenario above, has been successfully used to place a time window on when exactly someone destroyed evidence.

Comment by monocasa 2 days ago

I'm a security researcher.

"Garbage" isn't the same thing as random noise.

I have looked at the entropy graphs of encrypted data commonly. It's one of the first things I look at when looking at a new firmware image I haven't seen before.

Comment by pixl97 3 days ago

Loll, you have a lot of faith in the legal system that I do not. Expert witnesses are commonly full of shit.

Comment by monster_truck 3 days ago

I didn't say all expert witnesses are good nor did I claim they are all used in good faith.

Merely that, unlike in the invented scenario above, statistical differences in the random garbage that gets written to a disk across different tool or OS versions has been successfully used to place a time window on when exactly someone destroyed evidence.

Comment by giancarlostoro 3 days ago

I heard one argue that "zooming" on an image by adding pixels with an algorithm is normal, and he's had such "evidence" used in court before. I was a little horrified as someone who has worked on digital forensic software at a former employer. Adding pixels to an image is not evidence, you're fabricating something out of thin air, especially if its drastically smaller, its even more likely to be BS.

Comment by dataflow 3 days ago

Are you saying any photos I take with phone that had digital zoom is automatically I admissible? Or if not, isn't that consistent with what they said?

Comment by jbxntuehineoh 3 days ago

but... how _else_ would you Enhance the image?

Comment by marysol5 2 days ago

You know that defence can bring in an expert witness too right?

Comment by fhdkweig 3 days ago

Even if that is true, I have better things to do with my time and money than pay a expert witness to explain: see, I wasn't breaking the law, I just wanted the cops to think I did. That just seems like a really bad idea.

Comment by ThePowerOfFuet 3 days ago

> the difference between truly random noise and an encrypted volume

A LUKS volume with a detached header is indistinguishable from random data.

Comment by monster_truck 3 days ago

Have you actually compared the random data that various tools write to a disk to encrypted files? Load up binwalk and give it a rip, you will be surprised by how distinct the entropy graph is between the two

Comment by ThePowerOfFuet 3 days ago

What you propose ("the random data that various tools write to disk") is not _random data_.

Compare the entropy graph of /dev/random against a LUKS volume with a decrypted header, and you will see no difference.

Comment by ErroneousBosh 3 days ago

That would just be dd if=/dev/urandom of=/dev/path/to/device

Comment by giantg2 3 days ago

Sounds a lot like stenography.

https://github.com/dishather/steganodisk

Comment by tptacek 3 days ago

The security track record of steganography is not great.

Comment by giantg2 3 days ago

Isn't the same true of consumer grade encryption? In a perfect world, they should be used together.

Comment by tptacek 3 days ago

Depends on what you mean, but my subtext was that a lot of steganographic designs have turned out to be detectable; it's a design-level concern, where most consumer encryption problems are implementation issues.

Comment by 3 days ago

Comment by 3 days ago

Comment by rsingel 3 days ago

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

Comment by tlhunter 3 days ago

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.

Comment by jrexilius 2 days ago

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.

https://www.anomie.tech/

Comment by imglorp 3 days ago

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

Comment by matheusmoreira 3 days ago

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.

Comment by jp191919 3 days ago

Probably better just to use a veracrypt hidden volume, and preferably not a SSD.

Comment by boobsbr 2 days ago

Why not an SSD?

Comment by jp191919 2 days ago

SSDs are hard to completely sanitize

Comment by boobsbr 1 day ago

I thought that spreading the writes and bytes around for even wear would make it even harder to piece together data from a dump without a partition table.

Comment by Retr0id 3 days ago

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.

Comment by megous 3 days ago

Rule no. 1: you don't announce your security by obscurity methods :)

Comment by tim-projects 3 days ago

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.

Comment by dolmen 3 days ago

Not very practical for an USB device used to move data from one computer to another.

Comment by Schlagbohrer 2 days ago

> "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.

Comment by jmclnx 3 days ago

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.

Comment by mixmastamyk 3 days ago

Hmm, a partition of any sort has mapped the territory.

Comment by 2 days ago

Comment by ted_dunning 3 days ago

But this partition would be visible.

The OP had a version that is invisible.

Comment by jmclnx 2 days ago

rue, but I think if crossing a border, this would be enough to get by. I doubt the border guards would know what fdisk is showing and you can say "that was there when I bought it".

But the big question would the guards even know about fdisk type utilities ?

Comment by maxprimes 3 days ago

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!

Comment by purpleidea 3 days ago

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.

Comment by Dwedit 2 days ago

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.

Comment by monster_truck 3 days ago

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

Comment by felooboolooomba 3 days ago

If you need 8 MI300X's for a month to do ROT13, then you're doing it wrong.

Comment by charcircuit 3 days ago

>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.

Comment by dzhiurgis 3 days ago

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.

Comment by marysol5 3 days ago

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

Comment by pessimizer 3 days ago

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?

Comment by marysol5 2 days ago

You would need to re-engineer this to not have an SD card. And you'd also need the MCU where you can't just read off the firmware and decompile it to see the encryption routing.

Comment by jrexilius 3 days ago

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?

Comment by JoeBOFH 3 days ago

I miss TrueCrypts alt boot option. You enter a specific password it boots an alt OS so you could have an automatic alternative thing if under duress.

Comment by marysol5 2 days ago

VeraCrypt exists

Comment by marysol5 2 days ago

Also there is patches for luksOpen that destroys the key if you give a "duress" key. Not that would work in proper forensic operations.

Comment by russfink 3 days ago

Could use an Opal or Pyrite drive connected to a USB caddy and sedutil-cli to manage it.

Comment by sandworm101 3 days ago

Dude. Veracrypt. Hidden volumes. This is an old and well-solved problem set.

Comment by NetMageSCW 3 days ago

Hidden volumes aren’t that hidden if Veracrypt can find them.

Comment by loneboat 3 days ago

iirc it's even invisible to veracrypt until it has your correct password in hand. The hidden volume headers are indistinguishable from random bytes (which Veracrypt fills the volume with on creation).

Comment by marysol5 2 days ago

They are hidden if one of the "sources" to find them is only known to the user.

Comment by 3 days ago

Comment by mrloopex 3 days ago

[dead]

Comment by sscaryterry 3 days ago

Encrypted USB drives, there are definite legal uses, but like others have said, it raises suspicion.

Comment by NetMageSCW 3 days ago

The whole point is you are unable to detect that the drive is encrypted because it is only visible to USB once the password is written.

Comment by daneel_w 3 days ago

In this case you can just crack it open and see that the SD card inside is larger than the 8 GB block device exposed.

Comment by sscaryterry 3 days ago

The whole point is asking what is so sensitive.

Comment by gruez 3 days ago

>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.

Comment by ronsor 3 days ago

Could've at least sealed the SD card in an epoxy blob.