Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

kernel.org

Post reply on HN
Print view View original

21–30 of 40 posts

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#21

Post by sslalready »

bmalehorn wrote: post #11
sprash wrote: post #6

Doesn't solve my most important problem with LUKS: Allowing Trim passthrough on SSDs without impacting vulnerability. Also, why use json for meta-data instead of simple C Structs? No human is supposed to read this kind of data anyways.

> Alowing Trim passthrough on SSDs without impacting vulnerability. Unfortunately I don’t think that’s possible. If I scan your encrypted disk and see that 10% of blocks are zeroed out, I can assume that your disk is 90% full. So information has been leaked, which is arguably a vulnerability.

I think TRIM is dangerous not because of information leaks, but because of the risk of IV/nonce reuse when SSD data blocks are unmapped but not cleared. This would pose a risk if someone dumps the raw content of the NAND chips and find two or more data blocks encrypted with the same IV/nonce.

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#22

Post by kakarot »

saghm wrote: post #12
bmalehorn wrote: post #11

Earlier quoted context omitted.

> Alowing Trim passthrough on SSDs without impacting vulnerability. Unfortunately I don’t think that’s possible. If I scan your encrypted disk and see that 10% of blocks are zeroed out, I can assume that your disk is 90% full. So information has been leaked, which is arguably a vulnerability.

Couldn't this be an opt-in feature? For some people, this might be a reasonable trade-off given their threat model

Fedora decided with release 27 to enable trim by default on newly created encrypted devices. I was not happy about this decision and try to make some noise but nobody really seem to care. There is a reason that it is disabled by default in the Linux kernel, and making this kind of decision on behalf of the users without any input from the community is pretty fucked up.

Personally, I would like to explore the idea of a secure enclave that keeps a map of which blocks are in use that gets referred to during write operations. This seems like a problem that is going to need to be solved with hardware.

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#23

Post by [deleted] »

loeg wrote: post #17
2bluesc wrote: post #4

Section regarding the format: LUKS2 format and features ~~~~~~~~~~~~~~~~~~~~~~~~~ The LUKS2 is an on-disk storage format designed to provide simple key management, primarily intended for Full Disk Encryption based on dm-crypt. The LUKS2 is inspired by LUKS1 format and in some specific situations (most of the default configurations) can be converted in-place from LUKS1. The LUKS2 format is designed to allow future upd…

JSON seems like a weird choice for a kernel-parsed data structure. Or perhaps it's just parsed in userspace and signaled to the kernel in a more direct format.

[deleted]

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#25

Post by jwilk »

loeg wrote: post #17
2bluesc wrote: post #4

Section regarding the format: LUKS2 format and features ~~~~~~~~~~~~~~~~~~~~~~~~~ The LUKS2 is an on-disk storage format designed to provide simple key management, primarily intended for Full Disk Encryption based on dm-crypt. The LUKS2 is inspired by LUKS1 format and in some specific situations (most of the default configurations) can be converted in-place from LUKS1. The LUKS2 format is designed to allow future upd…

JSON seems like a weird choice for a kernel-parsed data structure. Or perhaps it's just parsed in userspace and signaled to the kernel in a more direct format.

I'm pretty sure this JSON is not parsed by kernel.

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#26

Post by Crontab »

codys wrote: post #9
2bluesc wrote: post #4

Section regarding the format: LUKS2 format and features ~~~~~~~~~~~~~~~~~~~~~~~~~ The LUKS2 is an on-disk storage format designed to provide simple key management, primarily intended for Full Disk Encryption based on dm-crypt. The LUKS2 is inspired by LUKS1 format and in some specific situations (most of the default configurations) can be converted in-place from LUKS1. The LUKS2 format is designed to allow future upd…

> JSON text format for metadata It seems like it could be better to use some easier to parse binary format that allows the same flexibility that json does, like cbor/msgpack/bson. Using JSON here is a very strange choice.

To me, the worst part is that it introduces a library dependency, which itself can introduce security issues unless they intend to audit it. I don't under this choice at all.

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#27

Post by klodolph »

codys wrote: post #9
2bluesc wrote: post #4

Section regarding the format: LUKS2 format and features ~~~~~~~~~~~~~~~~~~~~~~~~~ The LUKS2 is an on-disk storage format designed to provide simple key management, primarily intended for Full Disk Encryption based on dm-crypt. The LUKS2 is inspired by LUKS1 format and in some specific situations (most of the default configurations) can be converted in-place from LUKS1. The LUKS2 format is designed to allow future upd…

> JSON text format for metadata It seems like it could be better to use some easier to parse binary format that allows the same flexibility that json does, like cbor/msgpack/bson. Using JSON here is a very strange choice.

BSON, despite its name, is really just a format for MongoDB rather than a binary alternative for JSON.

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#28

Post by freedomben »

wyager wrote: post #15
2bluesc wrote: post #4

Section regarding the format: LUKS2 format and features ~~~~~~~~~~~~~~~~~~~~~~~~~ The LUKS2 is an on-disk storage format designed to provide simple key management, primarily intended for Full Disk Encryption based on dm-crypt. The LUKS2 is inspired by LUKS1 format and in some specific situations (most of the default configurations) can be converted in-place from LUKS1. The LUKS2 format is designed to allow future upd…

> internally uses JSON text format for metadata. What the hell? Why would they do this? The only (tenuous) justification for using a parsed human-oriented text format in any protocol is so that humans can edit things by hand, but this will presumably not be the case for file metadata. I don’t want to read too much into this since there might be a sane explanation, but this seriously makes me question the design of th…

JSON is a language agnostic format that is widely supported, so one could read/parse the metadata from virtually any language. This is much more flexible and powerful than a specific binary format. It may also make debugging a lot easier since it is human readable.

I don't know if that's the reason they chose JSON, but that's what I would think about IIWM.

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#29

Post by [deleted] »

klodolph wrote: post #27
codys wrote: post #9

Earlier quoted context omitted.

> JSON text format for metadata It seems like it could be better to use some easier to parse binary format that allows the same flexibility that json does, like cbor/msgpack/bson. Using JSON here is a very strange choice.

BSON, despite its name, is really just a format for MongoDB rather than a binary alternative for JSON.

[deleted]

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#30

Post by tinus_hn »

loeg wrote: post #17
2bluesc wrote: post #4

Section regarding the format: LUKS2 format and features ~~~~~~~~~~~~~~~~~~~~~~~~~ The LUKS2 is an on-disk storage format designed to provide simple key management, primarily intended for Full Disk Encryption based on dm-crypt. The LUKS2 is inspired by LUKS1 format and in some specific situations (most of the default configurations) can be converted in-place from LUKS1. The LUKS2 format is designed to allow future upd…

JSON seems like a weird choice for a kernel-parsed data structure. Or perhaps it's just parsed in userspace and signaled to the kernel in a more direct format.

That doesn't really matter as the program parsing it is probably running with full privileges.
Post reply on HN