TrueCrypt/VeraCrypt can do the same stuff but with physical drives, so yes, the claim of 'first' is inaccurate even with that technicality in mind.

The reason why that's not the focus of TrueCrypt/VeraCrypt is because they also go significantly further. One problem with plausible deniability with this concept is that it's difficult and limiting to have to try to hide traces of access to an encrypted disk from a host OS that is stored on unencrypted media (and, obviously since it's the point of the whole project, even if it was encrypted, you could be compelled to decrypt it.)

TrueCrypt/VeraCrypt FDE supports hiding an encrypted, bootable partition within the free space of another encrypted, bootable partition, in such a way that it is not generally possible to tell that there is a hidden partition, but you can boot into either depending on what password you enter. (Of course, the bootloader that allows you to enter the password is not encrypted, so for bootable partitions there is evidence that some encrypted partition exists, but this is unavoidable.)

I fully admit to prior ignorance of VeraCrypt's abilities. From what I read on their website, I don't disagree with you.

I will add that the PUREE specification does support subvolumes: different passwords may unlock different regions of the disk. Yet, while the spec is quite simple, this feature isn't implemented yet, nor is the ability for a PUREE disk to be bootable.

My hope is that, despite PUREE currently lacking these features in version 1.0.0, anyone who has been discouraged by the learning curve and installation overhead of the alternatives will find use in PUREE, given its simplicity, clearly strong security properties, and user-friendly interface.

Another system that had similar goals and was developed quite a long time ago (between 1997 and 2000) was rubberhose[1] by Julian Assange, Suelette Dreyfus, and Ralf Weinmann. It had the additional goal of being designed so that if you were forced to decrypt the drive, it would be impossible for the attacker to know if there were more subvolumes to decrypt (a precursor to how VeraCrypt subvolumes work).

However you should be aware that this property is not widely considered a "good thing" because if you are in a situation where an attacker is willing to physically harm you, then they may not be convinced that you've given them all of the keys (even if you have). The same problem exists for cryptosystems that self-destruct -- how do you convince the attacker that you weren't the cause of the data being destroyed?

[1]: https://en.wikipedia.org/wiki/Rubberhose_(file_system)

I would be more careful about calling something 'the first ever' if you haven't actually researched the other solutions.

Duly noted, title has been changed.

Very nice to see someone admitting and making changes after someone makes valid points!

You would think it would be the obvious action, but history has taught us people can go a long way in trying to convince others they are right, when they are not.

Hat tip

> the phrases "stored in a file" and "hidden volume within another volume" are red flags.

Why? Files are lot easier than full partition encryption. And how else would you hide a volume with anything like plausible deniability?

If entire disk appears to be empty - it is much more plausible to have an argument that this is indeed just an empty spare. If you have a "hidden" file -- that file can be found to begin with -- _something_ in the file system will be pointing at it. And then - a large file filled with random data - that's one hell of a red flag if I ever saw one.

It's not an actual file, it's unmarked in the free space of the first volume. If you mount only the first volume, it will appear normal, and data loss will occur if more space is used.

https://www.truecrypt71a.com/documentation/plausible-deniabi...

Also, as jchw mentioned above, the headers are indistinguishable from random data already, and truecrypt supports full volume encryption already. This nesting feature is on top of the "volume looks like random data" feature.

TrueCrypt can also do full disk encryption however full disk encryption is LESS safe than a hidden file/volume. The reason is that the lack of a non-encrypted volume on a disk implies there is an encrypted volume. The existence of a dummy non-encrypted volume does not. Plausible deniability keeps you safer especially in cases where not providing a decryption key results in indefinite jail time.

TrueCrypt can do full disk encryption with plausible deniability (a separate passphrase mounts a different encrypted section).

> PBKDF2-SHA1

What's the problem?

No memory hardness and no data dependence. Along with that SHA1 is really simple to implement on ASICs, FPGA, GPUs and such. This means that you can do lots of tests in parallel trivially (not much ram needed for each test, and no branching). You can use lots of PBKDF2 rounds to help against this but it will always mean that the cost of attacking it will scale much lower than something like scrypt or the argon2 family. In this application I don't believe there's any specific attacks against SHA1 or PBKDF2 but they don't provide the additional security that more modern things provide.

Fair enough. I use a ton of rounds, but yeah that's fair.

See https://en.wikipedia.org/wiki/PBKDF2#Alternatives_to_PBKDF2