Hacker News Reader

Comment by rendx | Hacker News Reader

There is https://github.com/kriswebdev/cryptsetup-deluks: "The DeLUKS header is designed to be indistinguishible from random data."

And also volumes by the quite popular TrueCrypt and its successor VeraCrypt have random headers... https://www.raedts.biz/forensics/detecting-truecrypt-veracry...

Looks like a nice enough project, but be careful with claims like "first".

View on HN

> DeLUKS

Interesting, hadn't seen this project yet, or would have been more careful, thanks.

A few thoughts:

- The lack of a link to a white paper makes DeLUKS difficult to analyze, but it looks like they're hashing the password using PBKDF2-SHA1, which is quite outdated. (PUREE uses argon2id.)

- The installation/usage seems slightly complex. I'd suggest people compare to the PUREE quick start instructions.

> TrueCrypt/VeraCrypt

As per your link: "When you create an encrypted volume using TrueCrypt or VeraCrypt it is stored as a file (container) on your hard drive.".

And as per VeraCrypt's wikipedia page: "VeraCrypt supports plausible deniability[16] by allowing a single "hidden volume" to be created within another volume"

I didn't read too much deeper, but the phrases "stored in a file" and "hidden volume within another volume" are red flags.

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

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.

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

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)

> PBKDF2-SHA1

What's the problem?

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

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.

You can also simply have LUKS with a detached header - I know some people that have their header and boot partitions exclusively on a USB, so that it's required to be in possession of the USB key to unlock and boot your computer.

Be careful with that solution, you then have to have a separate backup strategy for that USB data.

Only if the computer has important (and not backed up/replicated) state.

Throw it in an S3 bucket. Done.

Exactly, and that backup strategy is likely to be the weak link.

I called this out in the PUREE paper:

> To be fair, some tools do support support completely-random-looking disk layouts, but in most cases, they either:

> 1. Are key-based (e.g., require a 128-bit or 256-bit key) rather than password based, in which case, the key must stored elsewhere. (Where do you store the key?)

> 2. Ask the user to store a (non-random-looking) disk-encryption header elsewhere (i.e., “detached header mode”). (Where do you store the header?)

> 1. Are key-based (e.g., require a 128-bit or 256-bit key) rather than password based, in which case, the key must stored elsewhere. (Where do you store the key?)

Is there a reason why this is notably different? Why can't the password be hashed to get the fixed length key?

Yes, it's a pretty standard approach. I can't even recall anything that uses passwords directly these days. Mostly due to world relying mainly on aes where you have to derive the key.

> 2. Ask the user to store a (non-random-looking) disk-encryption header elsewhere (i.e., “detached header mode”). (Where do you store the header?)

If the header isn't needed on a daily basis, storing it as a QR-Code on paper would be a possibility.

Reply on news.ycombinator.com