
Cryptsetup 2.0.0 introduces new on-disk LUKS2 format - tyngde
https://www.kernel.org/pub/linux/utils/cryptsetup/v2.0/v2.0.0-ReleaseNotes
======
fpgaminer
I'm surprised to see so many comments here throwing up on the use of JSON.
Have we really forgotten the Unix philosophy?

> Write programs to handle text streams, because that is a universal
> interface.

A lot of the data formats I've written recently have used JSON. Partly because
of that aforementioned principal, but mostly because it's just easier and
there are very little downsides. Almost every language has support for it so
it's fairly universal, it's self documenting, it's easy to debug, easy to
manipulate by hand, and easy to maintain.

Put more simply: I've implemented several data formats using custom binary and
several data formats using JSON. JSON was easier and faster every single time.

My recommendation for data formats: just use JSON; unless you have a really
good reason not to.

And I do mean really good reason. For example, many might think concerns about
data size would be a reason not to use JSON. But go ahead and run some JSON
through a compression algorithm some time. You'll be amazed. Compressed JSON
is very competitive versus a custom binary format.

~~~
codys
> several data formats using custom binary and several data formats using JSON

You may not realize it, but you've presented a false dichotomy here.

The alternate to JSON isn't "custom binary", it's standardized binary
encodings that allow the same flexibility (or additional flexibility) compared
to JSON. Some examples include cbor & msgpack.

>> Write programs to handle text streams, because that is a universal
interface.

cryptsetup manipulates block devices. I don't think that line can or should
really be applied to something that is fairly similar to a filesystem's on-
disk format.

------
sprash
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.

~~~
bmalehorn
> 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.

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

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

~~~
saghm
Oops, probably should have checked before asking

------
wonderous
Anyone aware of any independent formal security audits of this version of this
or any prior version of LUKS?

------
2bluesc
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 updates of various
        parts without the need to modify binary structures and internally
        uses JSON text format for metadata. Compilation now requires the json-c library
        that is used for JSON data processing.
     
        On-disk format provides redundancy of metadata, detection
        of metadata corruption and automatic repair from metadata copy.
     
        NOTE: For security reasons, there is no redundancy in keyslots binary data
        (encrypted keys) but the format allows adding such a feature in future.
     
        NOTE: to operate correctly, LUKS2 requires locking of metadata.
        Locking is performed by using flock() system call for images in file
        and for block device by using a specific lock file in /run/lock/cryptsetup.
     
        This directory must be created by distribution (do not rely on internal
        fallback). For systemd-based distribution, you can simply install
        scripts/cryptsetup.conf into tmpfiles.d directory.
     
        For more details see LUKS2-format.txt and LUKS2-locking.txt in the docs
        directory. (Please note this is just overview, there will be more formal
        documentation later.)

~~~
codys
> 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.

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

~~~
jwilk
Why can't it be both?

~~~
klodolph
I see no reason why it can't be both, it's just that BSON happens to be a poor
format for general interchange, and if you went back and redesigned you could
probably fix many of its flaws. I'm a little skeptical though, I would rather
just throw it out.

It's kind of shitty that it was called BSON, because it falls so far short of
the generality that JSON has.

------
jwilk
LUKS2 on-disk format specification:

[https://gitlab.com/cryptsetup/cryptsetup/raw/v2.0.0/docs/LUK...](https://gitlab.com/cryptsetup/cryptsetup/raw/v2.0.0/docs/LUKS2-format.txt)

------
raverbashing
As noted on the release notes, do not use this for production systems (for
now) unless you have a backup of your data

