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