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

11–20 of 40 posts

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#11

Post by bmalehorn »

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.

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#12

Post by saghm »

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.

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

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#13

Post by Denvercoder9 »

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

Yes, it can be, and it's already present.

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#14

Post by Teknoman117 »

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.

Is there a good writeup on why this is such a horrific vulnerability? I see a lot of doom and gloom about this without a lot of explanations.

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#15

Post by wyager »

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 this security-critical system.

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#16

Post by mjepronk »

Teknoman117 wrote: post #14
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.

Is there a good writeup on why this is such a horrific vulnerability? I see a lot of doom and gloom about this without a lot of explanations.

Plausible deniability. For example, from the trimmed sector you can inference that the disk is being used.

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#17

Post by loeg »

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.

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#18

Post by loeg »

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.

> Using JSON here is a very strange choice.

I agree! Perhaps the userspace administrative tool (which links json-c) parses it and converts it to something more like an ioctl struct for the kernel.

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#19

Post by nly »

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.

This isn't without precedence. IIRC the LVM (Linux Volume Management) metadata is also mostly text format

https://github.com/libyal/libvslvm/blob/master/documentation...

Re: Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

#20

Post by sprash »

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.

This is an engineering problem where tradeoffs have to be made. E.g. You could make it appear that the disk is about 90% full all the time if you queue up the trim commands in some deterministic way. This way you only could determine if the disk is more or less than about 90% full at any time. I think good engineers would come up with something even better.

This would be on a level of a nice CS Bachelors/Masters thesis.

Post reply on HN