You are correct. I've simplified a bit: I boot from a 50GB decoy root partition that also has a 450GB decoy data partition along side it, both encrypted with the same weak password. This is a standard configuration and the machine works perfectly fine, you can write inside the decoy root as much as you want, as Linux would do when it boots. The data partition is largely empty and you haven't written large files there for some time, but that should not be suspicious by itself.

In the free space of the large data partition there lives the sensitive hidden root. It's maybe 250GB, with a 100GB offset from the start of the decoy data, and 50GB guard space at the back, where ext4 writes all sorts of crap. So you get to use about 50% of your raw disk capacity inside the sensitive environment, as a single encrypted root.

There is a risk of them looking at the raw data of the drive and asking what all the random data at the end of it is.

The beatings will continue until you decrypt it. Hopefully you can and it's not actually just random data...

The outer volume is itself encrypted so if you correctly initialized it as recommended, the raw disk should be full of random bits. When read from within the encrypted outer volume, these decrypt to random data as well, so there should be no way to detect the inner volume, either by looking at the raw disk sectors or at the decrypted outer volume sectors. Most importantly, you have the plausible deniability that the disk looks exactly as it should per recommendations of security experts, that the boot-loader and initrd are the stock versions that exist on any other Ubuntu machine with encrypted volumes etc.

Another caveat here is that the inner volume must use the implicit encryption parameters of cryptsetup, or that the correct parameters are supplied in the command line. A LUKS header should absolutely not be used, as it will be plainly visible inside the partition, and would indicate, at the very least, that some other encrypted data was stored in the past on the disk leading to new questions about its password etc., killing plausible deniability.

See the cryptsetup FAQ 5.2 (https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAsk...):

"This means that if you have a large set of random-looking data, they can already lock you up."

In the UK, with RIPA legislation, there is a real risk of someone dropping a USB key full of random data on you, telling the cops there's child porn in it, then you get locked up for 5 years for failing to decrypt it.

I've read the FAQ item and I'm sorry to say that it seems written by somebody talking out of their behind, giving legal advice to boot.

Sure, once in the hands of the Russian FSB, Italian Mafia or Nicolas Maduro, any detectable amount of random data could result in torture - just to be on the safe side, maybe there is a hidden volume there after all.

But in any state where rule of law is observed, the prosecution must establish probable cause and, once in court, prove beyond reasonable doubt that the illegal act was indeed committed - in this case, failure to disclose the encryption key of a locked volume. So there must exist corroborating evidence that should exclude any reasonable accidental or normal situation that could produce the random data. For example, a border agent could testify that he saw illegal material on your device's screen and a random file could be found in your home directory. In your device history, traces to a missing volume or partition could remain etc. The defense can easily explain away a partition initialized to random, if that's what standard system tools produce in their normal configuration and no other corroborating evidence exits.

A LUKS header is a clear indication that another encryption configuration was/is used on the computer, so you would then be compelled to give explanation about it's presence, it's password, the provenance of the laptop etc. The explanations given in the FAQ (experiment, random swap) are unconvincing if they are not corroborated by other patterns, for example modification timestamps on /etc/fstab and /etc/crypttab and so on.

So the absence of the LUKS header really does fill a practical gap, and it happens that most legal systems today are squeezing harder and harder into that gap. Unlike the dubious claims in that FAQ entry, Truecrypt hidden volumes actually have established legal precedent.

TrueCrypt/VeraCrypt can do this for you with the intention that the existence of a hidden partition is plausibly deniable unless the correct key is provided. The only downside to this is gross inefficiency, you may only be able to get 20GB useful space out of a 500GB disc.

I think the parent comment is describing a scheme where the outer partition contains the inner one, so both are large. As the parent notes, this is dangerous, and you have to be careful not to overwrite inner data if you boot the outer os.

It is also Linux, so there are probably three different ways to make partitions appear to be a different size or reserve certain blocks in the partition.