You are not logged in.

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

abc12345
Member
Registered: 2022-03-30
Posts: 57

partitionless filesystem for security?

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)

Offline

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

Slithery
Administrator
From: Norfolk, UK
Registered: 2013-12-01
Posts: 5,776

Re: partitionless filesystem for security?

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?


No, it didn't "fix" anything. It just shifted the brokeness one space to the right. - jasonwryan
Closing -- for deletion; Banning -- for muppetry. - jasonwryan

aur - dotfiles

Offline

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

abc12345
Member
Registered: 2022-03-30
Posts: 57

Re: partitionless filesystem for security?

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.

Offline

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

frostschutz
Member
Registered: 2013-11-15
Posts: 1,409

Re: partitionless filesystem for security?

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.

Online

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

Maniaxx
Member
Registered: 2014-05-14
Posts: 732

Re: partitionless filesystem for security?

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.


sys2064

Offline

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

Head_on_a_Stick
Member
From: London
Registered: 2014-02-20
Posts: 7,680
Website

Re: partitionless filesystem for security?

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.

Offline

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

WorMzy
Forum Moderator
From: Scotland
Registered: 2010-06-16
Posts: 11,788
Website

Re: partitionless filesystem for security?


Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD

Making lemonade from lemons since 2015.

Offline

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

abc12345
Member
Registered: 2022-03-30
Posts: 57

Re: partitionless filesystem for security?

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

Offline

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

abc12345
Member
Registered: 2022-03-30
Posts: 57

Re: partitionless filesystem for security?

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.

Offline

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

Maniaxx
Member
Registered: 2014-05-14
Posts: 732

Re: partitionless filesystem for security?

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


sys2064

Offline

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

loqs
Member
Registered: 2014-03-06
Posts: 17,197

Re: partitionless filesystem for security?

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.

Offline

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

sabroad
Member
Registered: 2015-05-24
Posts: 242

Re: partitionless filesystem for security?

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)


--
saint_abroad

Offline

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

mpan
Member
Registered: 2012-08-01
Posts: 1,188
Website

Re: partitionless filesystem for security?

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.


Sometimes I seem a bit harsh — don’t get offended too easily!

Offline

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

abc12345
Member
Registered: 2022-03-30
Posts: 57

Re: partitionless filesystem for security?

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

Offline

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

loqs
Member
Registered: 2014-03-06
Posts: 17,197

Re: partitionless filesystem for security?

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.

Offline

Board footer

Powered by FluxBB