partitionless filesystem for security?

abc12345 · 2022-09-24 16:23:15

Is there a partitionless filesystem? As in, no partition table, no boot sector, just entire space taken by files and the working data?
EXT4 have all initial offset. This is a major security issue to have a filesystem container to require initial space that's identical or near identical for common filesystems. (Impossible to mkfs.ext4 with offset=0) You can mitigate the issue of having your encryption vector map to a sector filled with zeroes but if you have several containers with identical encryption schema&password - their presence on the storage medium is readily identifiable.

Last edited by abc12345 (2022-09-24 16:28:10)

Slithery · 2022-09-24 17:27:32

abc12345 wrote:

This is a major security issue to have a filesystem container to require initial space that's identical or near identical for common filesystems.

Why is this a 'major security issue' for your specific use case?
What threats are you trying to protect yourself from that are actually relevant to your use-case?

abc12345 · 2022-09-24 18:12:17

The major security issue - if your crypt container contains zeros in the beginning, you have a direct 1 to 1 mapping between encrypted data and known data, which makes decrypting it easier. It might even solve mathematically neatly to some encryption vector. I mean that's the whole point of encryption - to never know the data that's encrypted ever, let alone to have a special case of zeros for data.
Threats are - anyone can decrypt your crypt container.

frostschutz · 2022-09-24 20:35:40

If that was possible, there would be no safe encryption in the world.

But if you're truly worried about this point, it's easy to solve... just put another layer of encryption inside the encryption... with cryptsetup plain mode you can achieve 100% of device looking like random data, no discernible headers.

Still strongly recommend you put a regular partition table on your drives first. Otherwise it might get formatted / corrupted by other software.

Maniaxx · 2022-09-24 21:31:03

You're thinking in plain symmetrical encryption. There are counter measures (salts, nonce, entropy, etc). You were asked for a 'specific use case' for a reason. Which tools/processing chain are we talking about.

Head_on_a_Stick · 2022-09-24 21:50:08

I've had a system booting from a Btrfs "super-floppy" drive: https://wiki.archlinux.org/title/GRUB/T … nless_disk

I wouldn't recommend it though.

WorMzy · 2022-09-24 21:50:19

https://xkcd.com/538/

abc12345 · 2022-09-26 12:37:42

WorMzy wrote:

https://xkcd.com/538/

Brain implants to visual cortex and verbal thoughts area. Soon as cheap as $5 dollars, too.

abc12345 · 2022-09-26 12:39:06

Maniaxx wrote:

You're thinking in plain symmetrical encryption. There are counter measures (salts, nonce, entropy, etc). You were asked for a 'specific use case' for a reason. Which tools/processing chain are we talking about.

It's plain encryption I was talking about.

Maniaxx · 2022-09-26 16:52:52

A more specific forum might help you better here:
https://crypto.stackexchange.com

loqs · 2022-09-26 22:31:37

abc12345 wrote:

Maniaxx wrote:
You're thinking in plain symmetrical encryption. There are counter measures (salts, nonce, entropy, etc). You were asked for a 'specific use case' for a reason. Which tools/processing chain are we talking about.
It's plain encryption I was talking about.

What application are you using that uses plain encryption for disk encryption?
A note on mkfs.ext4 a value of 0 is considered invalid for offset size as an offset is required to have a size. If you do not want an offset do not use that feature. If having an offset allows encryption to be broken then such encryption is not fit for use.

sabroad · 2022-09-27 11:18:32

abc12345 wrote:

The major security issue - if your crypt container contains zeros in the beginning, you have a direct 1 to 1 mapping between encrypted data and known data, which makes decrypting it easier.

For anything less than 512GB known data, that's simply not true.

AES-XTS protects against known-plaintext attacks by using 2 keys (and block address) to ensure that blocks of identical data will not produce identical cipher text [1]. By default, cryptsetup<=2.06 uses aes-xts-plain64 for LUKS with a (128+128) key size [2]. For a 128-bit block cipher, plaintext-recovery attack is feasible with 2^32 known blocks in the target sectors, and 2^96 local computations [3].

[1] https://www.kingston.com/unitedkingdom/ … encryption
[2] https://superuser.com/a/1428927
[3] https://eprint.iacr.org/2019/825.pdf

Last edited by sabroad (2022-09-27 11:38:39)

mpan · 2022-09-27 12:30:59

Before everybody falls into the rabbit hole of trying to prove security of proven cryptographic solutions, it may be worth noticing that one of the assumptions in OP’s question is wrong. The assumption is that location of the file system affects presence of the 1KiB padding, which ext4 reserves for stuff like volume boot record.

It does not. ext4 doesn’t care where it is created. It may be placed in a partition, directly on a physical device, in a file, in a mapped device — it will work the same and that 1KiB padding will be present. The offset parameter will not affect its presence, as it’s a part of the file system itself, not an offset before the file system. So the entire idea of placing a file system elsewhere is wrong.

While other file systems may not place literal 1024 zeros there, they will store other quite predictable values at the beginning. LUKS2 itself pads the initial 512-byte header with 3584 zeros. So trying to use another file system is hardly a solution to the perceived threat.

abc12345 · 2022-10-03 16:20:40

loqs wrote:

abc12345 wrote:
It's plain encryption I was talking about.
What application are you using that uses plain encryption

I use this for Archlinux installation https://wiki.archlinux.org/title/dm-cry … n_dm-crypt

loqs · 2022-10-03 21:45:47

cryptsetup --help
....
Default compiled-in device cipher parameters:
	loop-AES: aes, Key 256 bits
	plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
	LUKS: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom
	LUKS: Default keysize with XTS mode (two internal keys) will be doubled.

Unless you are overriding the defaults and removing the use of cbc-essiv or xts-plain(64) which guard against watermarking the issue you are seeking to avoid is already addressed.

Arch Linux

#1 2022-09-24 16:23:15

partitionless filesystem for security?

#2 2022-09-24 17:27:32

Re: partitionless filesystem for security?

#3 2022-09-24 18:12:17

Re: partitionless filesystem for security?

#4 2022-09-24 20:35:40

Re: partitionless filesystem for security?

#5 2022-09-24 21:31:03

Re: partitionless filesystem for security?

#6 2022-09-24 21:50:08

Re: partitionless filesystem for security?

#7 2022-09-24 21:50:19

Re: partitionless filesystem for security?

#8 2022-09-26 12:37:42

Re: partitionless filesystem for security?

#9 2022-09-26 12:39:06

Re: partitionless filesystem for security?

#10 2022-09-26 16:52:52

Re: partitionless filesystem for security?

#11 2022-09-26 22:31:37

Re: partitionless filesystem for security?

#12 2022-09-27 11:18:32

Re: partitionless filesystem for security?

#13 2022-09-27 12:30:59

Re: partitionless filesystem for security?

#14 2022-10-03 16:20:40

Re: partitionless filesystem for security?

#15 2022-10-03 21:45:47

Re: partitionless filesystem for security?

Board footer