Bitcoin-ready linux distro

[LoyceV]

what about places like China? they may think you are just trying to do plausible deniability.

If I ever go there, I'll leave all electronics at home.

[1715331262]

1715331262

[1715331262]

1715331262

[1715331262]

1715331262

[Carlton Banks]

what do you use for encryption?

luks

Could you do this with a GUI?

I don't think so

it's easy () to do with linux dd command, just practice it with a disk you don't care about.

It's also easy to screw it up and write the random data to your main PC disk, so maybe use a VM on an old USB disk as your practice...

workflow:

• md5sum on the first x bytes of the encrypted disk, save that hash somewhere (using linux tail lets you feed the exact number of bytes to md5sum, do it with the pipe character)
• dd using x bytes as the offset to backup the header
• md5sum the file with the backed up header, compare to saved hash
• dd i=/dev/random to the encrypted disk device with that x offset as the value for where to end

the variable x will be the size of the LUKS header, I don't know what it is off the top of my head, but either LUKS utilities or the LUKS manpage (probably man cryptsetup) will also tell you

so long as you get the right number for x, and the right device for the disk, you'll be alright. possibly LUKS header is variable length (I expect it is as it's possible to add multiple keys or something like that), but that's why practicing is a good idea

[o_e_l_e_o]

You can add encrypted files inside your encrypted file system

But then you lose your explanation.

"Why has this data, which you told me was nothing but random data from a secure wipe process, changed?"
"Oh, that's just because of my encrypted files inside my encrypted file system, which is disguised within this supposedly random data. Sorry, what I meant was, I have no idea!"

It's even easier if you use a dual boot and use the second to overwrite the first.

Personally, I would have my entirely encrypted drive appearing as nothing but random data, and a laptop with nothing sensitive on it. When I get to my destination, use Tor to download Tails and run it from a USB as a live OS, and then use that to mount and decrypt my drive. This avoids the risk of my regular OS storing any unencrypted information about my drive.

[LoyceV]

You can add encrypted files inside your encrypted file system

But then you lose your explanation.

"Why has this data, which you told me was nothing but random data from a secure wipe process, changed?"

In that case, I'll take another approach: "what's random data?"
Seriously, I don't think anyone is ever going to ask me that, it's far above the investigation skills of the guy checking your suitcase for explosives.

I have no idea!"

Exactly

[Carlton Banks]

To edit the header, you could use any graphical hex editor (you need to find one which doesn't load entire /dev/sdX though).

right, it's vital to know accurately which byte the header ends so that you know which byte the encrypted volume begins. using a graphical hex editor could work, e.g. perhaps there is a byte sequence at the end of the header that's always the same.

if not, knowing exactly the length of a key slot, exactly how many key slots your header has, and the exact length of the data before them is very important.


an extra trick I thought of: I expect that the header for a disk partition is smaller than a basic disk encryption header. Instead of replacing the encryption header entirely with random data, why not:

• find out the size of a partition header
• subtract it from the size of your encryption header
• overwrite the start of the disk encryption header with a partition
• fill the remaining space with random data (only as far as the last byte of the encryption header! use the number you found in step 2)

then, instead of having a "suspicious" random data disk, you have a disk that an OS filesystem window would recognize when you plug it in. Sure the rest of the data is your encrypted volume, but it "looks" otherwise like a normal disk that's got nothing on it.

you: "really? nothing on it? damn, must've taken the wrong disk with me, my bad"

or

you: "yeah, that's my disk to put the holiday photos on, would you like to see my photos of the church organs of Europe?"

that sort of thing

[takuma sato]

To edit the header, you could use any graphical hex editor (you need to find one which doesn't load entire /dev/sdX though).

right, it's vital to know accurately which byte the header ends so that you know which byte the encrypted volume begins. using a graphical hex editor could work, e.g. perhaps there is a byte sequence at the end of the header that's always the same.

if not, knowing exactly the length of a key slot, exactly how many key slots your header has, and the exact length of the data before them is very important.


an extra trick I thought of: I expect that the header for a disk partition is smaller than a basic disk encryption header. Instead of replacing the encryption header entirely with random data, why not:

• find out the size of a partition header
• subtract it from the size of your encryption header
• overwrite the start of the disk encryption header with a partition
• fill the remaining space with random data (only as far as the last byte of the encryption header! use the number you found in step 2)

then, instead of having a "suspicious" random data disk, you have a disk that an OS filesystem window would recognize when you plug it in. Sure the rest of the data is your encrypted volume, but it "looks" otherwise like a normal disk that's got nothing on it.

you: "really? nothing on it? damn, must've taken the wrong disk with me, my bad"

or

you: "yeah, that's my disk to put the holiday photos on, would you like to see my photos of the church organs of Europe?"

that sort of thing

Someone with forensic tools would just be able to see a relevant chunk of random data irrespective of how your headers look. Sure having a reasonable looking header increases your chances of plausible deniability but I don't see how tricks anyone that has been instructed in this field. Also playing around with the header is quite dangerous if you screw up in the process. Id rather never put myself on a situation where someone gets to my encrypted data to begin with. So far I have concluded that you just cannot cross any borders with encrypted stuff.