From: Sven Eschenberg <sven@whgl.uni-frankfurt.de>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Some questions/clarifications around the LUKS spec
Date: Tue, 15 Mar 2016 15:21:27 +0100 [thread overview]
Message-ID: <56E81A67.9010307@whgl.uni-frankfurt.de> (raw)
In-Reply-To: <56E73AE2.9020404@gmail.com>
Am 14.03.2016 um 23:27 schrieb Milan Broz:
> On 03/14/2016 10:24 PM, Sven Eschenberg wrote:
>
>> Updating a spec needs more than just mentioning something. Esp. changes
>> may not be incompatible to previous revisions. If changes are
>> incompatible, a new version is needed (instead of a simple revision). A
>> change to the list of valid values as well as the change in offset
>> calculation to meet alignment requirements are indeed incompatible to
>> the original specification for the v1 header, like it or not. Thus, by
>> introducing these changes, a new version of the on disk format was
>> introduced and this should have been reflected by reversioning the
>> header as well. Having multiple possible specs for the same
>> magic+version is something one really should not go for.
>
> On-disk format should be backward compatible since cryptsetup 1.0.1,
> no change in version is needed.
> (But there were bugs - so nobody should use such old versions.)
Yes and no. It seems the spec purposefully decided to offer a fixed list
(of ciphers/modes) to make alternative implementations possible. AFAIK
none really exists (in the public domain) and since the old reference
implementation already allowed diverging from the spec it did not really
adhere it either. Any other implementationhonoring the spec before the
xts updates could legitimately consider all headers with unlisted
ciphers invalid and refuse to work (for safety). So there would no real
harm be done, yet it would have been better to make this change clear by
changing the version - afterall there's a 16-bit value and massive
changes could still change the magic string for safety. (in example your
plans for v2)
> Algorithm support is always dynamic thing (you can blacklist kernel
> module, run in FIPS mode that allows only NIST friendly algorithms...)
> So "mandatory" list for LUKS does not make sense in reality.
As I read the LUKS spec it is not limited to the stock kernel crypto
modules, in practise no alternatives showed up so far though. Example:
Imagine the crypto is done externally by a crypto device that is tied to
your box by RDMA and offers a cipher which it names rijndael. So an
implementation that sets up this device would map the name rijndael to
aes and you could still use the encrypted device with any different
kernel. I think limiting the list of ciphers and modes was for full
portability, which makes sense.
>
> Offset calculation for keyslot is the same as well ... but reading
> that pseudo-algorithm in spec - the slot alignment to 4k diverged
> in 1.0 -> 1.0.1 (2005). Clemens probably forgot to update spec here,
> so this is IMHO bug in spec (and I missed this).
>
> (Cryptsetup can still open old sector-aligned version - despite this version
> was never in any distro.)
The question though is, would that still hold true the other way round
for old cryptsetup versions (and alternative implementations) prior to
the xts spec update?
>
> User data alignment was always read from header, it was never calculated
> and I think spec expect it this way.
I think the spec is not clear on this, it suggests the offsets are
stored for safety. It does not explicitly state the stored values should
take precedence, though this is one (sane) possible interpretation. It's
never to late for an errata to clarify this ;-).
>
> Milan
Regards
-Sven
next prev parent reply other threads:[~2016-03-15 14:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-14 15:21 [dm-crypt] Some questions/clarifications around the LUKS spec Daniel P. Berrange
2016-03-14 18:58 ` Sven Eschenberg
2016-03-14 19:54 ` Milan Broz
2016-03-14 21:24 ` Sven Eschenberg
2016-03-14 22:27 ` Milan Broz
2016-03-15 14:21 ` Sven Eschenberg [this message]
2016-04-27 12:56 ` [dm-crypt] Cryptesetup and dm-crypt levent demir
2016-04-27 16:35 ` Arno Wagner
2016-03-14 20:31 ` [dm-crypt] Some questions/clarifications around the LUKS spec Milan Broz
2016-03-15 10:23 ` Daniel P. Berrange
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56E81A67.9010307@whgl.uni-frankfurt.de \
--to=sven@whgl.uni-frankfurt.de \
--cc=dm-crypt@saout.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.