[dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Christoph Anton Mitterer]

Hey.


I'm using cryptsetup since nearly the beginngin and now I'd like to
sooner or later switch to LUKS2 and integrity protection.

I'd have some questions... maybe you can help :-)


1) Is there any current known bug in LUKS2 / AEAD of cryptsetup/dm-
crypt/dm-integrity?
I read about the limitations of the GCM mode with the small nonces
(more on that below)... but apart from that... even though it's still
experimental... do you think I can use it and be safe (in terms of the
crypto)?


2) I was reading through the release notes and parts of them kinda were
written as if MAC-then-Encrypt would be done wich has all kinds of
security issues as we know from TLS... Is this correct or does it use
Encrypt-Then-MAC?


3) --sector-size
Does this also change the crypto block size? I vaguely think to
remember that some loooooong time ago when XTS was introduced, someone
said it wouldn't be safe to use with block sizes >512?
Or does this just set how many 512bit crypto blocks are written/read at
once to the underlying device?


4) --integrity-no-journal
Manpage says it would be safe to use if journaling is done on a
different layer.
I assume this could be layers above OR below dm-crypt?
So what about e.g ext* filesystems with journaling or btrfs with CoW
enabled... are these safe to use without a dm-integrity journal?
Has the answer to this question been coordinated with the respective
filesystem developers?


5) integritysetup options not provided in cryptsetup
integritysetup has a number of options not provided in cryptsetup,
e.g.:
--journal-size, --interleave-sectors, --journal-watermark, --journal-
commit-time, --tag-size, --journal-*

How does cryptsetup choose these values?


6) v2.0.0-ReleaseNotes.gz side node
These release notes say:
  FDE authenticated encryption is not a replacement for filesystem
layer
  authenticated encryption. The goal is to provide at least something
because
  data integrity protection is often completely ignored in today
systems.
Does the note that FDE AE is not a repleacement for fs lvl AE really
just refer to the "authentication/integrity protection part"?
Or does it also refer to the encrpytion part... cause I've always
assumed block layer disk encryption would be rather saver than just
plain filesystem level encryption (like there is e.g. for ext).

Do I loose anything in terms of encryption security when I use the AE
as well? I mean it's ok if the integrity protection is not perfect,...
but I wouldn't want to loose anything in the encryption security
compared to what we have now.


7) Are we going to see SHA3 anytime soon in dm-crypt/cryptsetup? E.g.
for HMAC in integritry... or for --hash?




8) Something more important for me:
a) Which algos are already safe to use for encryption/integrity?
In the release notes you basically list these three:
  * aes-xts-plain64 with hmac-sha256 or hmac-sha512 as the
authentication tag.
  * aes-gcm-random (native AEAD mode)
    DO NOT USE in production! The GCM mode uses only 96-bit nonce,
  * ChaCha20 with Poly1305 authenticator (according to RFC7539)

But in another place it also says that Chacha20-poly1305 is affacted by
the small nonce:

  NOTE: Currently available authenticated modes (GCM, Chacha20-
poly1305)
  in kernel have too small 96-bit nonces that are problematic with
  randomly generated IVs (the collison probability is not negligible).
  For the GCM, nonce collision is a fatal problem.

b) So is only aes-xts-plain64 / with hmac-sha* safe to use? Or is even
that safe to use at all?


c) Can I also use serpent-xts-plain64 / hmac-sha512 and will that be
safe?


d) Which key sizes (--key-size) would I need to use?
For aes-xts-plain64 I always used --key-size 512, which I think results
in AES256, right? With 256 bit for AES and the other 256 for XTS?

But for AEAD with HMAC I'd need another key, right? What's --key-size
then? Or is it still 512 and crypsetup selects  they auth key based on
the auth-algo?
And how would one need to set it for SERPENT?


e) Is there anything better in the meantime than:
  [aes|serpent]-xts-plain64
and
  hmac-sha512
?




9) Authenticated encryption do not set encryption for dm-integrity
journal.

Just wondered why this isn't a security problem? Isn't all data written
to the journal... and if this isn't encrypted...?


10) We plan to use AEGIS and MORUS, as CAESAR finalists.
Are these then safer than aes-xts-plain64 / hmac-*?
I stumbled over a paper which shows that these algos fail pretty bad if
a nonce is reused:
https://eprint.iacr.org/2017/1137.pdf


11) The persistent settings stored with --persistent...
Are these encrypted/integrity protected? Otherwise an attack could
trick a user into e.g. using TRIM even though he doesn't because of
security concerns.




Last but not least:


12) Next to normal disk encryption (and in the future integrity
protection) like on a laptop,... I'd like to "abuse" cryptsetup/dm-
crypt for now to encrypt plain files, i.e. very large (~20GiB) dar
files that are backups of all my personal data and which I want to
write to tape.
Since this will be long term archival,... I'd like to
- triple encrypt with different algos (AES, SERPENT, <something else>)
- use a recent password hashing algo (Argon2*)

GPG only supports AES (not SERPENT) and none of the other newer algos
like ChaCha20 is on the horizon... same for password hashing, where
OpenPGP has it's own s2k algo, which is however even with the highest
possible iteration count pretty fast. Same here... nothing on the
horizon that gpg/openpgp will support anything better.


So my idea was basically to do three layers of encryption:
plain data -> dm-crypt/luks2 [serpent-xts-plain64 + hmac-sha256] -> 
-> dm-crypt/luks2 [some algo, chacha20+poly if it would be save] -> gpg
[AES256 + signature]


For cryptsetup I'd simply create image files of the right sizes, so
that the previous layer fits in perfectly (i.e. not trailing unused
bytes on the dm-crypt "device").
I'd use Argon2id, which seems the safest.


a) Do you see (apart from the crazy overkill ;-) ) any apparent mistake
or something that could be made better / more secure)?

Since I will get anyway regular files in the end (i.e. an image file
containing dm-crypt/LUKS encrypted other such LUKS container files)... 

b) ... I assume I can safely use --integrity-no-journal (either I
finish writing the file or I just start over again, so a crash doesn't
bother me here).

c) ... I assume I can also safely use --integrity-no-wipe, as I will
anyway write the complete dm-crypt/integrity "device" which is just of
the size (in terms of the payload) of the regular file I want to
encrypt.



Thanks a lot,
Chris.

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Milan Broz]

Hi,

(I asked Chris to send this to the list, so just copying some
my short notes that I replied in private mail before.)

On 16/08/18 17:52, Christoph Anton Mitterer wrote:
> 1) Is there any current known bug in LUKS2 / AEAD of cryptsetup/dm-
> crypt/dm-integrity?
> I read about the limitations of the GCM mode with the small nonces
> (more on that below)... but apart from that... even though it's still
> experimental... do you think I can use it and be safe (in terms of the
> crypto)?

There are many bugs, but most them are implementation things that
are not related to security.

LUKS2 as on-disk format should be ok but AEAD is still something I would
better see to be analysed by some other people.

> 2) I was reading through the release notes and parts of them kinda were
> written as if MAC-then-Encrypt would be done wich has all kinds of
> security issues as we know from TLS... Is this correct or does it use
> Encrypt-Then-MAC?

Everything is encrypt-then-MAC (both for native AEAD and combined mode),
it is mentioned in the paper https://arxiv.org/abs/1807.00309

> 3) --sector-size
> Does this also change the crypto block size? I vaguely think to
> remember that some loooooong time ago when XTS was introduced, someone
> said it wouldn't be safe to use with block sizes >512?
> Or does this just set how many 512bit crypto blocks are written/read at
> once to the underlying device?

It is mainly about the crypto block. Limitation for XTS block is I think
at most 2^20 AES blocks, we have maximum 4096 bytes sector size (because of
the 4k page size), so this is not a problem.

It should map to atomic unit of the device. With dm-integrity journal
you can use this even for smaller sector, without journal you can get partial
sector update on fail. (IIRC mentioned it in the paper above as well.)

(You can set larger sector size even without authenticated encryption.
And sometimes it helps a lot in the performance sense. If it is "safe"
really depends on hw - with native 4k sectors it should be...)

> 4) --integrity-no-journal
> Manpage says it would be safe to use if journaling is done on a
> different layer.
> I assume this could be layers above OR below dm-crypt?
> So what about e.g ext* filesystems with journaling or btrfs with CoW
> enabled... are these safe to use without a dm-integrity journal?
> Has the answer to this question been coordinated with the respective
> filesystem developers?

It should be above dm-crypt. But this is more complicated - you need
to think what underlying dm-integrity is doing (store data + auth and IV
tags to another sector. If a write is corrupted, you can corrupt even other
sectors that shares metadata sector with tags...)

TBH this need better analysis. Better ask on dm-devel list, I am sume
Mikulas (as author of dm-integrity journaling code) can answer better.

> 5) integritysetup options not provided in cryptsetup
> integritysetup has a number of options not provided in cryptsetup,
> e.g.:
> --journal-size, --interleave-sectors, --journal-watermark, --journal-
> commit-time, --tag-size, --journal-*
> 
> How does cryptsetup choose these values?

It is in the API structure, but we did not provide these option on commandline yet.
So you get only defaults here. I think it need to be/will be implemented one day.


> 6) v2.0.0-ReleaseNotes.gz side node
> These release notes say:
>   FDE authenticated encryption is not a replacement for filesystem
> layer
>   authenticated encryption. The goal is to provide at least something
> because
>   data integrity protection is often completely ignored in today
> systems.
> Does the note that FDE AE is not a repleacement for fs lvl AE really
> just refer to the "authentication/integrity protection part"?
> Or does it also refer to the encrpytion part... cause I've always
> assumed block layer disk encryption would be rather saver than just
> plain filesystem level encryption (like there is e.g. for ext).
> 
> Do I loose anything in terms of encryption security when I use the AE
> as well? I mean it's ok if the integrity protection is not perfect,...
> but I wouldn't want to loose anything in the encryption security
> compared to what we have now.

I would say both the algorithms (encryption, integrity) are the same for filesystem layer.

What I meant is that with FDE we are missing a data context - you have one key
for everything, one user can decrypt all data etc.
You perhaps do not want this on multi-user system.

My threat model does not protect to data replay (you can revert sectors from old copy).
Filesystem usually have better approach (ZFS uses Merkle tree IIRC) and per-file
integrity.

I think filesystem can do better work here - but nobody merged this to mainline
kernel yet.
And seems encryption in fs (ext4 etc) is just doing what dmcrypt had 10 years ago...

> 7) Are we going to see SHA3 anytime soon in dm-crypt/cryptsetup? E.g.
> for HMAC in integritry... or for --hash?

Kernel should support whatever hash/hmac is there. I perhaps limited this with
fixed list of algorithms in userspace. (SHA3 has strange name like sha3-256, I think we
had to fix the code to support it).

But it will be terribly slow. Anyway, this should be supported in next release (2.1).
Kernel interface should be ok already (I hope :) so you can play with dmsetup :)

> 8) Something more important for me:
> a) Which algos are already safe to use for encryption/integrity?
> In the release notes you basically list these three:
>   * aes-xts-plain64 with hmac-sha256 or hmac-sha512 as the
> authentication tag.
>   * aes-gcm-random (native AEAD mode)
>     DO NOT USE in production! The GCM mode uses only 96-bit nonce,
>   * ChaCha20 with Poly1305 authenticator (according to RFC7539)
> 
> But in another place it also says that Chacha20-poly1305 is affacted by
> the small nonce:
> 
>   NOTE: Currently available authenticated modes (GCM, Chacha20-
> poly1305)
>   in kernel have too small 96-bit nonces that are problematic with
>   randomly generated IVs (the collison probability is not negligible).
>   For the GCM, nonce collision is a fatal problem.
> 
> b) So is only aes-xts-plain64 / with hmac-sha* safe to use? Or is even
> that safe to use at all?

It depends, what you expect. It is "safe" but I would better use random IV
(so every write will regenerate IV).


> c) Can I also use serpent-xts-plain64 / hmac-sha512 and will that be
> safe?

It will work, and definitely it will be "better" than without integrity
protection but what is safe really depends on what you really expects.
 
> d) Which key sizes (--key-size) would I need to use?
> For aes-xts-plain64 I always used --key-size 512, which I think results
> in AES256, right? With 256 bit for AES and the other 256 for XTS?

It is the same as without authentication - XTS mode has 2 keys, so
512 => AES256, 256 => AES128.

> But for AEAD with HMAC I'd need another key, right? What's --key-size
> then? Or is it still 512 and crypsetup selects  they auth key based on
> the auth-algo?
> And how would one need to set it for SERPENT?

Yes. For AEAD modes, there is only one key (integrity is an integral part).
For composed modes (XTS + HMAC etc) code internally calculates size of
integrity key and adds it to the encryption key (keys are independent).

So with this command

cryptsetup luksFormat --type luks2 /dev/sdb -c aes-xts-plain64 --integrity hmac-sha512 --key-size 512

you will see 
Keyslots:
  0: luks2
        Key:        1024 bits
 
(HMAC(sha512) => additional 512 bits)

But for now, only some combinations are hardcoded. I will make this more configurable in 2.1.


> e) Is there anything better in the meantime than:
>   [aes|serpent]-xts-plain64
> and
>   hmac-sha512
> ?

I bet for AEGIS and MORUS in 4.18, see below.

> 9) Authenticated encryption do not set encryption for dm-integrity
> journal.
> 
> Just wondered why this isn't a security problem? Isn't all data written
> to the journal... and if this isn't encrypted...?

Data are always encrypted. (dm-integrity journal handles encrypted sectors).
Journal metadata are not encrypted yet.

The problem here is that you can see particular pattern (which sectors are
in journal) and that the metadata of journal are not encrypted.
Attacker can mangle journal so journal reply can corrupt your data - but this
corruption will be detected by AEAD later on read.

 
> 10) We plan to use AEGIS and MORUS, as CAESAR finalists.
> Are these then safer than aes-xts-plain64 / hmac-*?
> I stumbled over a paper which shows that these algos fail pretty bad if
> a nonce is reused:
> https://eprint.iacr.org/2017/1137.pdf

Nonce must not be reused here.

That's why we use random IV - with 128bit nonce the probability of
collision is negligible even if you write lot of sectors.
With 96bit nonce you can get collision quite "soon".
See Ondrej's master thesis - he described this very well https://is.muni.cz/th/qvh3t


> 11) The persistent settings stored with --persistent...
> Are these encrypted/integrity protected? Otherwise an attack could
> trick a user into e.g. using TRIM even though he doesn't because of
> security concerns.

These are not encrypted, it is stored in LUKS header in JSON.
Actually no change here - today it is stored in crypttab in not encrypted initramfs.

You can trick user already today - bu modyfing crypttab. or binaries in initramdisk.
You need to sign everything if you want to be safe (Qubes OS signs even LUKS header IIRC.)


> Last but not least:
> 
> 
> 12) Next to normal disk encryption (and in the future integrity
> protection) like on a laptop,... I'd like to "abuse" cryptsetup/dm-
> crypt for now to encrypt plain files, i.e. very large (~20GiB) dar
> files that are backups of all my personal data and which I want to
> write to tape.
> Since this will be long term archival,... I'd like to
> - triple encrypt with different algos (AES, SERPENT, <something else>)
> - use a recent password hashing algo (Argon2*)

I think I read your mail on some crypto list. Not sure if I can help here.

(I agree with the comment there that the big problem is to remember passphrases after 20 years :-)

Milan

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Christoph Anton Mitterer]

Hey Milan!

Thanks for your replies :-)



On Fri, 2018-08-17 at 14:23 +0200, Milan Broz wrote:
> > 1) Is there any current known bug in LUKS2 / AEAD of cryptsetup/dm-
> > crypt/dm-integrity?
> 
> There are many bugs, but most them are implementation things that
> are not related to security.
When you say "most" are there some related to security?
Or would you (for security) rather suggest that I make one layer with
luks2+AEAD... and one with traditional luks1 without AEAD (especially
for the triple encryption of plain files, I've mentioned below)?



> LUKS2 as pon-disk format should be ok but AEAD is still something I
> would
> better see to be analysed by some other people.
Is anything planned here? Guess there are quite some people with high
knowledge of crypto in the kernel community... maybe Ted Ts'o.


> I hope so. It is more fragile though - if the journaling in dm-
> integrity
> is broken, we have no proper tool for recovery yet.
Well at least for my long-term-backup (ab)use of cryptsetup, that
fragility wouldn't be a problem anyway.


> > 3) --sector-size
> > Does this also change the crypto block size? I vaguely think to
> > remember that some loooooong time ago when XTS was introduced,
> > someone
> > said it wouldn't be safe to use with block sizes >512?
> > Or does this just set how many 512bit crypto blocks are
> > written/read at
> > once to the underlying device?
> 
> It is mainly about the crypto block.

So --setctor-size sets the crypto-block size, if I understand you
correctly.


>  Limitation for XTS block is I think
> at most 2^20 AES blocks, we have maximum 4096 bytes sector size
> (because of
> the 4k page size), so this is not a problem.
Not sure about this,...
The FAQ in section 5.16 already mentions:
"There is a potential security issue with XTS mode and large
blocks.  LUKS and dm-crypt always use 512B blocks and the issue does
not apply."
But it doesn't tell when the issues start... 

I found:

https://crypto.stackexchange.com/questions/35383/how-many-blocks-can-securely-be-encrypted-with-xts
But that isn't fully clear to me either...
could be that the recommendation says the block size should be no more
than 128*2^20 bits... which would bei fine for us... but I don't find
that at all in the NIST specs... neither whether it's about the crypto
block size or the total size (disk).


> What I meant is that the problem with FDE is missing data context -
> you have one key
> for everything, one user can decrypt all data etc.
> You perhaps do not want this on multi-user system.
Ah I see :-)



> My threat model does not protect to data replay (you can revert
> sectors from old copy).
AFAIU this is the case even *with* AEAD, right?

I'd have hoped that this would effectively be solved when a fs above
does checksumming and has something like btrfs generations...



> > 7) Are we going to see SHA3 anytime soon in dm-crypt/cryptsetup?
> > E.g.
> > for HMAC in integritry... or for --hash?
> 
> Kernel should support whatever hash/hmac is there. I perhaps limited
> this with
> fixed list of algorithms in userspace. (SHA3 has strange name like
> sha3-256, I think we
> had to fix the code to support it).
> 
> But it will be terribly slow. Anyway, this should be supported in
> next release (2.1).
> Kernel should be ok already (I hope :)

Yeah, seems it's hardcoded... any estimate on when 2.1 sees the light?

Would it even make sense to use SHA3 with HMAC?

https://crypto.stackexchange.com/questions/35127/should-hmac-sha3-be-preferred-over-hck-m
Says KMAC would be more suited for it.




> > 8) Something more important for me:
> > a) Which algos are already safe to use for encryption/integrity?
> > In the release notes you basically list these three:
> >   * aes-xts-plain64 with hmac-sha256 or hmac-sha512 as the
> > authentication tag.
> >   * aes-gcm-random (native AEAD mode)
> >     DO NOT USE in production! The GCM mode uses only 96-bit nonce,
> >   * ChaCha20 with Poly1305 authenticator (according to RFC7539)
> > 
> > But in another place it also says that Chacha20-poly1305 is
> > affacted by the small nonce:
> > 
> >   NOTE: Currently available authenticated modes (GCM, Chacha20-
> > poly1305)
> >   in kernel have too small 96-bit nonces that are problematic with
> >   randomly generated IVs (the collison probability is not
> > negligible).
> >   For the GCM, nonce collision is a fatal problem.
> > 
> > b) So is only aes-xts-plain64 / with hmac-sha* safe to use? Or is
> > even
> > that safe to use at all?
> 
> It depends, what you expect.
Well as much confidentiality and integrity as possible, without looking
at performance


>  It is "safe" but I would better use random IV
> (so every write will regenerate IV).
Okay what does that mean now? Should/can one use [aes|serpent]-xts-
random? What nonce sizes would that use?
I'd always assumed aes-xts-plain64 was the "best" choice so far.


But apart from that, right now it's not recommended to use either aes-
gcm-random or ChaCha20/Poly1305, right?
Once this would use bigger nonces... what's then the suggested "best"
cipher spec... for both AEAD and non-AEAD?


Btw: Has anyone had a look at Ketje?



> > 10) We plan to use AEGIS and MORUS, as CAESAR finalists.
> > Are these then safer than aes-xts-plain64 / hmac-*?
> > I stumbled over a paper which shows that these algos fail pretty
> > bad if
> > a nonce is reused:
> > https://eprint.iacr.org/2017/1137.pdf
> 
> Nonce must not be reused here.
> 
> That's why we use random IV - with 128bit nonce the probability of
> collision is negligible even if you write lot of sectors.
> With 96bit nonce you can get collision quite "soon".

I assume you'd use /dev/random for that?!


> > 11) The persistent settings stored with --persistent...
> > Are these encrypted/integrity protected? Otherwise an attack could
> > trick a user into e.g. using TRIM even though he doesn't because of
> > security concerns.
> 
> These are not encrypted, it is stored in LUKS header in JSON.
> Actually no change here - today it is stored in crypttab in not
> encrypted initramfs.
> 
> You can trick user already today - bu modyfing crypttab. or binaries
> in initramdisk.

Well if you have a fully encrypted system, than an attacker cannot
easily mangle with the crypttab... sure you always have to start
somewhere, but there's always the choice for people to keep their
(unencrypted) boot USB-stick always with them...


So I think that's a bit problematic,... if potentially security
relevant settings are now unsecured in the header... cryptsetup will
take them from there and the current model, where one was safe by
having the initramfs always at the (physical) keyring is basically
broken.

Can't you sign these options? Or at least provide a crypttab option to
ignore any non-secured options in the header?


> > 12) Next to normal disk encryption (and in the future integrity
> > protection) like on a laptop,... I'd like to "abuse" cryptsetup/dm-
> > crypt for now to encrypt plain files, i.e. very large (~20GiB) dar
> > files that are backups of all my personal data and which I want to
> > write to tape.
> > Since this will be long term archival,... I'd like to
> > - triple encrypt with different algos (AES, SERPENT, <something
> > else>)
> > - use a recent password hashing algo (Argon2*)
> 
> I think I read your mail on some crypto list.
It's a small world ;-)

> Not sure if I can help here.
Well the main question is probably... are there any concerns/weaknesses
in using XTS when not doing normal FDE?

Sure, AFAIU, in XTS every sector is independent, so there's the change
of replay attacks (which is not that easy with e.g. CBC as everything
is chained)... but when I use a single key for every encrypted
container and encrypt only once, replaying shouldn't anyway be possible
at all.


Thanks,
Chris.

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Milan Broz]

On 17/08/18 15:26, Christoph Anton Mitterer wrote:
> On Fri, 2018-08-17 at 14:23 +0200, Milan Broz wrote:
>>> 1) Is there any current known bug in LUKS2 / AEAD of cryptsetup/dm-
>>> crypt/dm-integrity?
>>
>> There are many bugs, but most them are implementation things that
>> are not related to security.
> When you say "most" are there some related to security?
> Or would you (for security) rather suggest that I make one layer with
> luks2+AEAD... and one with traditional luks1 without AEAD (especially
> for the triple encryption of plain files, I've mentioned below)?

LUKS2 is new code, with new bugs. FDE AEAD started as an academic experiment
and I believe we have to push authenticated encryption forward (in general),
so it is now part of upstream LUKS.

Some bugs can have security impact. That's all I meant here.


For the stacking layers and different cipher:

Well, I personally do not believe it is worth to use chained ciphers or multiple
layer of encryption, but on the other hand, I do not want block it.
(One of the item on my TODO list is to add new VeraCrypt chains to cryptsetup.)

>> LUKS2 as pon-disk format should be ok but AEAD is still something I
>> would
>> better see to be analysed by some other people.
> Is anything planned here? Guess there are quite some people with high
> knowledge of crypto in the kernel community... maybe Ted Ts'o.
> 
> 
>> I hope so. It is more fragile though - if the journaling in dm-
>> integrity
>> is broken, we have no proper tool for recovery yet.
> Well at least for my long-term-backup (ab)use of cryptsetup, that
> fragility wouldn't be a problem anyway.

If your use case is a long-term backup only, an authenticated encryption
is good to detect silent errors. Better would be to have something
that even repairs it (forward error correction).

>>> 3) --sector-size
>>> Does this also change the crypto block size? I vaguely think to
>>> remember that some loooooong time ago when XTS was introduced,
>>> someone
>>> said it wouldn't be safe to use with block sizes >512?
>>> Or does this just set how many 512bit crypto blocks are
>>> written/read at
>>> once to the underlying device?
>>
>> It is mainly about the crypto block.
> 
> So --setctor-size sets the crypto-block size, if I understand you
> correctly.

Yes. And it implies that dm-crypt device must present this block
as an atomic unit (we abuse hw-sector size). Check lsblk -t output.


>>  Limitation for XTS block is I think
>> at most 2^20 AES blocks, we have maximum 4096 bytes sector size
>> (because of
>> the 4k page size), so this is not a problem.
> Not sure about this,...
> The FAQ in section 5.16 already mentions:
> "There is a potential security issue with XTS mode and large
> blocks.  LUKS and dm-crypt always use 512B blocks and the issue does
> not apply."
> But it doesn't tell when the issues start... 
> 
> I found:
> 
> https://crypto.stackexchange.com/questions/35383/how-many-blocks-can-securely-be-encrypted-with-xts
> But that isn't fully clear to me either...
> could be that the recommendation says the block size should be no more
> than 128*2^20 bits... which would bei fine for us... but I don't find
> that at all in the NIST specs... neither whether it's about the crypto
> block size or the total size (disk).

I am trying to avoid doing any mathematical analysis (I know that I am not good in it :-)

But the XTS mode seems to be nice target of so many confusions...

So the extremely pragmatic engineering view:

- Read  NIST 800-38E and IEEE 1619-2007 - this is all the source of confusion, it is unclear in some aspects.
Also see https://en.wikipedia.org/wiki/Disk_encryption_theory#XTS

Two limits:
1) limit to XTS block size (strictly set in NIST 800-38E) to 2^20 AES blocks.
No poblem with dmcrypt, maximum block size is 4096 bytes (256 AES blocks, 2^8).

2) There is a limit in IEEE 1619, discussed in link you provided, to number of encrypted blocks
with one encryption key. (And there a limit for AES in any mode in general.)

I think the IEEE standard is just confusing. Better read Rogaway's analysis in chapter 6 from
Evaluation of Some Blockcipher Modes of Operation, web.cs.ucdavis.edu/~rogaway/papers/modes.pdf


Anyway, many FDE systems use XTS mode today.

And note, that with AEAD extension we should use random IV. It not only causes that
XTS mode start to behave partially as a wide-block mode (there is no longer AES-block granularity,
all the sector changes) but also I think the analysis need to bee tweaked, because we no longer
use consecutive IV, that is fixed for the particular sector.

(On the other hand, you must not use random IV without authentication, because then relocation
of ciphertext sector is possible. We depend on authentication of not only data but also IV
and sector number.)

...
 
>>> 7) Are we going to see SHA3 anytime soon in dm-crypt/cryptsetup?
>>> E.g.
>>> for HMAC in integritry... or for --hash?
>>
>> Kernel should support whatever hash/hmac is there. I perhaps limited
>> this with
>> fixed list of algorithms in userspace. (SHA3 has strange name like
>> sha3-256, I think we
>> had to fix the code to support it).
>>
>> But it will be terribly slow. Anyway, this should be supported in
>> next release (2.1).
>> Kernel should be ok already (I hope :)
> 
> Yeah, seems it's hardcoded... any estimate on when 2.1 sees the light?

I hope, as already promised, end of this year.


> Would it even make sense to use SHA3 with HMAC?

Kernel crypto api allows any construction here, kernel can use sha3 already,
but userspace has problem with dash in "sha3-256", I have to fix it.
(You can trick it manually but I do not want to post hacks how to do this
otherwise people start to use it :)))

...
>>  It is "safe" but I would better use random IV
>> (so every write will regenerate IV).
> Okay what does that mean now? Should/can one use [aes|serpent]-xts-
> random? What nonce sizes would that use?

nonce = IV = size of cipher block here (16 bytes)

...

>> That's why we use random IV - with 128bit nonce the probability of
>> collision is negligible even if you write lot of sectors.
>> With 96bit nonce you can get collision quite "soon".
> 
> I assume you'd use /dev/random for that?!

It is in kernel,  and it actually calls
  get_random_bytes(iv, iv_size);

So yes, it is directly kernel RNG.

>>> 11) The persistent settings stored with --persistent...
>>> Are these encrypted/integrity protected? Otherwise an attack could
>>> trick a user into e.g. using TRIM even though he doesn't because of
>>> security concerns.
>>
>> These are not encrypted, it is stored in LUKS header in JSON.
>> Actually no change here - today it is stored in crypttab in not
>> encrypted initramfs.
>>
>> You can trick user already today - bu modyfing crypttab. or binaries
>> in initramdisk.
> 
> Well if you have a fully encrypted system, than an attacker cannot
> easily mangle with the crypttab... sure you always have to start
> somewhere, but there's always the choice for people to keep their
> (unencrypted) boot USB-stick always with them...

Then also take detached LUKS header on USB.


> So I think that's a bit problematic,... if potentially security
> relevant settings are now unsecured in the header... cryptsetup will
> take them from there and the current model, where one was safe by
> having the initramfs always at the (physical) keyring is basically
> broken.
> 
> Can't you sign these options? Or at least provide a crypttab option to
> ignore any non-secured options in the header?

crypttab is handled by systemd. But activation options in LUKS2 header
have priority (in fact it was meant as a replacement for these options).

But if you keep attacker mangling with LUKS header, he can always do harm here.
(Try to move data offset in LUKS1 or just change cipher, it will corrupt data after activation.)
You have to secure whole LUKS header here.


And there is quite high press to make TRIM as default for dm-crypt,
it started here https://www.redhat.com/archives/dm-devel/2016-September/msg00061.html
and it is reappearing regularly (not on public list though).

BTW Fedora has discard option as a default for several releases.

And ... we do not support TRIM on FDE AEAD (dm-integrity) yet...  :-)
(Once supported, it can only trim data blocks, not metadata. So it will be tricky.

...

m.

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Christoph Anton Mitterer]

Hey.



On Sun, 2018-08-19 at 12:07 +0200, Milan Broz wrote:
> LUKS2 is new code, with new bugs. FDE AEAD started as an academic
> experiment
> and I believe we have to push authenticated encryption forward (in
> general),
> so it is now part of upstream LUKS.
> 
> Some bugs can have security impact. That's all I meant here.

Okay, but there are no already known issues... :)



> > > I hope so. It is more fragile though - if the journaling in dm-
> > > integrity
> > > is broken, we have no proper tool for recovery yet.
> > Well at least for my long-term-backup (ab)use of cryptsetup, that
> > fragility wouldn't be a problem anyway.
> If your use case is a long-term backup only, an authenticated
> encryption
> is good to detect silent errors. Better would be to have something
> that even repairs it (forward error correction).

I will anyway add PAR files :-) ... and gpg signatures as well.
So for me it was just important here, that the dm-integrity journal
causes no issues... (and actually I think I can disable it - for the
long term backup thingy, not for "normal" disk encryption with AEAD)


> > So --setctor-size sets the crypto-block size, if I understand you
> > correctly.
> 
> Yes. And it implies that dm-crypt device must present this block
> as an atomic unit (we abuse hw-sector size). Check lsblk -t output.

I've added this as a potential todo for the documentation at:
https://gitlab.com/cryptsetup/cryptsetup/issues/404#note_95375083

> - Read  NIST 800-38E and IEEE 1619-2007 - this is all the source of
> confusion, it is unclear in some aspects.
> Also see https://en.wikipedia.org/wiki/Disk_encryption_theory#XTS
> 
> Two limits:
> 1) limit to XTS block size (strictly set in NIST 800-38E) to 2^20 AES
> blocks.
> No poblem with dmcrypt, maximum block size is 4096 bytes (256 AES
> blocks, 2^8).
> 
> 2) There is a limit in IEEE 1619, discussed in link you provided, to
> number of encrypted blocks
> with one encryption key. (And there a limit for AES in any mode in
> general.)

I've added this as a potential todo for the documentation at:https://gitlab.com/cryptsetup/cryptsetup/issues/404#note_95375142




> > > It is "safe" but I would better use random IV
> > > (so every write will regenerate IV).
> > 
> > Okay what does that mean now? Should/can one use [aes|serpent]-xts-
> > random? What nonce sizes would that use?
> 
> nonce = IV = size of cipher block here (16 bytes)

Ah it's in /proc/crypto as well :-)

Looking at this:
- All SERPENT+XTS or AES+XTS modes have 128 bit IV.
- Some GCM have the 96 bit IVs... but some have even only 64 bit
  (__gcm-aes-aesni, rfc4106(gcm(aes)) and __gcm-aes-aesni).

- ChaCha20 seems to have all 128 bit IV... but is this correct? I've
  modpobed chacha20poly1305 ... but at least ther's no reference to
  poly1305 in /proc/crypto


> And note, that with AEAD extension we should use random IV. It not
> only causes that
> XTS mode start to behave partially as a wide-block mode (there is no
> longer AES-block granularity,
> all the sector changes) but also I think the analysis need to bee
> tweaked, because we no longer
> use consecutive IV, that is fixed for the particular sector.
> 
> (On the other hand, you must not use random IV without
> authentication, because then relocation
> of ciphertext sector is possible. We depend on authentication of not
> only data but also IV
> and sector number.)

Okay now I'm still confused about what one can safely use and what not
:-(

AFAIU:
1) aes-gcm-random
   => NOT safe to use

   Because up to at least 4.17, kernel crypt uses just 96 bit nonces
   for which the collision chance is too big.


2) [aes|serpent]-xts-plain64 with hmac-[sha256|sha512]
   (or in cryptsetup with hmac-sha3-[256|512]
   => SAFE to use

   But *-xts-random would be better (if, and only if, AEAD/integrity
   is used, right?
   Also, do NOT use -random, if no AEAD/integrity is used.


3) [aes|serpent]-xts-random with hmac-[sha256|sha512]
   (or in cryptsetup with hmac-sha3-[256|512]
   => SAFE to use

   -random is better than -plain64 (but ONLY with AEAD)


4) chacha20-random with poly1305
   => SAFE to use

   Could this safely be used with -plain64?



> > Well if you have a fully encrypted system, than an attacker cannot
> > easily mangle with the crypttab... sure you always have to start
> > somewhere, but there's always the choice for people to keep their
> > (unencrypted) boot USB-stick always with them...
> 
> Then also take detached LUKS header on USB.
I always didn't like this because one can easier mix up things and
"open" the device with the wrong header.

Perhaps one could have a stub header that contains just enough
information to tell at least whether a matching device/key has been
selected.



> But if you keep attacker mangling with LUKS header, he can always do
> harm here.
> (Try to move data offset in LUKS1 or just change cipher, it will
> corrupt data after activation.)
Well but at least these one would notice immediately...

> You have to secure whole LUKS header here.
... but one wouldn't notice e.g. someone silently enabling TRIM for you


> And there is quite high press to make TRIM as default for dm-crypt,
> it started here 
> https://www.redhat.com/archives/dm-devel/2016-September/msg00061.html
> and it is reappearing regularly (not on public list though).
Well even if this request comes from the very top, it's still wrong.
dm-crypt/cryptsetup is for people who want security, and the defaults
should be just for that.
And after all, every distro can just override that defaults if it
believes their users aren't "crazy-anal people" o.O



Thanks,
Chris.

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Milan Broz]

Hi,

sorry for long delay, I was most of the time offline.

On 19/08/18 19:27, Christoph Anton Mitterer wrote:
>>>> It is "safe" but I would better use random IV
>>>> (so every write will regenerate IV).
>>>
>>> Okay what does that mean now? Should/can one use [aes|serpent]-xts-
>>> random? What nonce sizes would that use?
>>
>> nonce = IV = size of cipher block here (16 bytes)
> 
> Ah it's in /proc/crypto as well :-)
> 
> Looking at this:
> - All SERPENT+XTS or AES+XTS modes have 128 bit IV.
> - Some GCM have the 96 bit IVs... but some have even only 64 bit
>   (__gcm-aes-aesni, rfc4106(gcm(aes)) and __gcm-aes-aesni).
> 
> - ChaCha20 seems to have all 128 bit IV... but is this correct? I've
>   modpobed chacha20poly1305 ... but at least ther's no reference to
>   poly1305 in /proc/crypto

No, we use RFC7539 wrapper for Chacha20-poly1305 and here the nonce is
only 96bit.

So the same probability of collision as in GCM, just a nonce collision
does not cause such fatal failure as in GCM.

> Okay now I'm still confused about what one can safely use and what not
> :-(

I will probably oversimplify it, but until we have time to really
write documentation examples (and explain it in detail), these are my advices:

- authenticated encryption remains as experimental feature

- never use GCM mode

- Avoid Chacha20-poly1305 as well (because of 96bit nonce)

- For authenticated modes use random IV only.

- For NON-authenticated modes, never use random IV.

- Do not use slow hashes (sha3) or too long hashes (sha512) in HMAC-based
authentication tags (it is overkill and performance will suffer extremely).
SHA256 should be enough.

So for (this oversimplified) LUKS2 authenticated encryption there are only two options:

1) Combine existing length-preserving block mode with additional
HAMC-based authentication tag and random IV, for example (luksFormat parameters)

  "--cipher aes-xts-random --integrity hmac-sha256"

2) Use new native AEAD algorithms with 128bit nonces (in kernel 4.18 and later)
(aegis128,aegis256,aegis128l,morus640,morus1280), for example

  "--cipher aegis128-random --key-size 128 --integrity aead" or
  "--cipher aegis256-random --key-size 256 --integrity aead" or
  "--cipher morus640-random --key-size 128 --integrity aead" ...

(The key-size option should not be needed but there is apparently some
bug and it tries to use only default 256 bits - will fix this later in version 2.1)

Milan

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Christoph Anton Mitterer]

On Mon, 2018-09-03 at 09:48 +0200, Milan Broz wrote:
> sorry for long delay, I was most of the time offline.
Thanks, and no worries :-)


> On 19/08/18 19:27, Christoph Anton Mitterer wrote:
> > - ChaCha20 seems to have all 128 bit IV... but is this correct?
> > I've
> >   modpobed chacha20poly1305 ... but at least ther's no reference to
> >   poly1305 in /proc/crypto
> 
> No, we use RFC7539 wrapper for Chacha20-poly1305 and here the nonce
> is
> only 96bit.
> 
> So the same probability of collision as in GCM, just a nonce
> collision
> does not cause such fatal failure as in GCM.

Are there any plans to provide ChaCha20/Poly1305 with larger nonces in
the future?

I mean having it would be at least interesting from the PoV that they
seem to have quite some substantial amount of cryptoanalysis.


> I will probably oversimplify it, but until we have time to really
> write documentation examples (and explain it in detail), these are my
> advices:
> 
> - authenticated encryption remains as experimental feature
> 
> - never use GCM mode
> 
> - Avoid Chacha20-poly1305 as well (because of 96bit nonce)
> 
> - For authenticated modes use random IV only.
> 
> - For NON-authenticated modes, never use random IV.

It would be nice if cryptsetup and the other tools give a warning or
allow to use "unsafe" combinations (like e.g. non-AEAD + random-IV or
GCM/ChaCha20+Poly1305-with-96bit-nonce) only when a special option like
--unsafe-but-i-know-what-i-do is given :-)


> - Do not use slow hashes (sha3) or too long hashes (sha512) in HMAC-
> based
> authentication tags (it is overkill and performance will suffer
> extremely).
> SHA256 should be enough.

Okay, but that's only a performance thingy.


> 2) Use new native AEAD algorithms with 128bit nonces (in kernel 4.18
> and later)
> (aegis128,aegis256,aegis128l,morus640,morus1280), for example
> 
>   "--cipher aegis128-random --key-size 128 --integrity aead" or
>   "--cipher aegis256-random --key-size 256 --integrity aead" or
>   "--cipher morus640-random --key-size 128 --integrity aead" ...

Do these work already in 2.0 with 4.18? I thought some algos were still
hardcoded in cryptsetup?


Thanks for your explanations :-)

Cheers,
Chris.

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Arno Wagner]

On Tue, Sep 04, 2018 at 14:49:29 CEST, Christoph Anton Mitterer wrote:
> On Mon, 2018-09-03 at 09:48 +0200, Milan Broz wrote:
> > sorry for long delay, I was most of the time offline.
> Thanks, and no worries :-)
> 
> 
> > On 19/08/18 19:27, Christoph Anton Mitterer wrote:
> > > - ChaCha20 seems to have all 128 bit IV... but is this correct?
> > > I've
> > >   modpobed chacha20poly1305 ... but at least ther's no reference to
> > >   poly1305 in /proc/crypto
> > 
> > No, we use RFC7539 wrapper for Chacha20-poly1305 and here the nonce
> > is
> > only 96bit.
> > 
> > So the same probability of collision as in GCM, just a nonce
> > collision
> > does not cause such fatal failure as in GCM.
> 
> Are there any plans to provide ChaCha20/Poly1305 with larger nonces in
> the future?

I don't think that is a concern. 96bit, even if randomly chosen, 
is unlikely to collide in the remaining lifetime of this star-system.

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Milan Broz]

On 04/09/18 17:53, Arno Wagner wrote:
> On Tue, Sep 04, 2018 at 14:49:29 CEST, Christoph Anton Mitterer wrote:
>> On Mon, 2018-09-03 at 09:48 +0200, Milan Broz wrote:
>>> sorry for long delay, I was most of the time offline.
>> Thanks, and no worries :-)
>>
>>
>>> On 19/08/18 19:27, Christoph Anton Mitterer wrote:
>>>> - ChaCha20 seems to have all 128 bit IV... but is this correct?
>>>> I've
>>>>   modpobed chacha20poly1305 ... but at least ther's no reference to
>>>>   poly1305 in /proc/crypto
>>>
>>> No, we use RFC7539 wrapper for Chacha20-poly1305 and here the nonce
>>> is
>>> only 96bit.
>>>
>>> So the same probability of collision as in GCM, just a nonce
>>> collision
>>> does not cause such fatal failure as in GCM.
>>
>> Are there any plans to provide ChaCha20/Poly1305 with larger nonces in
>> the future?

I don't think so.  The dmcrypt use case is quite special and for network
protocols it is ok (you will regenerate encryption key after some time anyway).

> I don't think that is a concern. 96bit, even if randomly chosen, 
> is unlikely to collide in the remaining lifetime of this star-system.

Nonce is here generated on every sector write, if you can record all sector
writes (usually not the case though), then it depends on probability of
collision you need.

And people noted, I think I posted it here already
https://twitter.com/solardiz/status/882163531176697857

This is for GCM though but it illustrates the problem.
If we want to use AEAD FDE in future, I vote for doing no compromises
and just use 128bit random nonces/IVs, that is really enough :)

(There will be perhaps need to reencrypt device/change key after some time anyway.)

Milan

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Christoph Anton Mitterer]

Hey.


Coming back (from vacation ;-) and back) on this and since 4.18 is out
in the meantime:

>2) Use new native AEAD algorithms with 128bit nonces (in kernel 4.18
>and later)
>(aegis128,aegis256,aegis128l,morus640,morus1280), for example
>
>  "--cipher aegis128-random --key-size 128 --integrity aead" or
>  "--cipher aegis256-random --key-size 256 --integrity aead" or
<  "--cipher morus640-random --key-size 128 --integrity aead" ...

1) Should these work by now with the current cryptsetup? Or will one
require 2.1?


2a) AFAIU, AEGIS will always have either key-sizes of 128 or 256 bit,
right?
I'm also assuming that larger key size will give a better security
margin,right?
But what's the 128L?


2b) And MORUS will have either 640 bit for the internal state with
"only" 128 bit keys... OR... the 1280 bit internal state with either
128 or 256 bit keys, right?
Again, I'm assuming that larger internal state and larger key size will
give a better security margin, right?


3) Is there any comparison (in terms of security) between AEGIS and
MORUS?


Thanks,
Chris.

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Milan Broz]

Hi,

On 15/10/2018 17:11, Christoph Anton Mitterer wrote:
>> 2) Use new native AEAD algorithms with 128bit nonces (in kernel 4.18
>> and later)
>> (aegis128,aegis256,aegis128l,morus640,morus1280), for example
>>
>>  "--cipher aegis128-random --key-size 128 --integrity aead" or
>>  "--cipher aegis256-random --key-size 256 --integrity aead" or
> <  "--cipher morus640-random --key-size 128 --integrity aead" ...
> 
> 1) Should these work by now with the current cryptsetup? Or will one
> require 2.1?

These should work with 2.0.4 (most of it even with older releases).
You just need kernel with modules enabled.

> 2a) AFAIU, AEGIS will always have either key-sizes of 128 or 256 bit,
> right?
> I'm also assuming that larger key size will give a better security
> margin,right?
> But what's the 128L?

It just another variant with internal state size of 1024 bits.

This is table from Ondra's master thesis that focused on
these dm-crypt AEAD extensions (https://is.muni.cz/th/qvh3t/)

                  AEGIS-128L AEGIS-128 AEGIS-256
Input block size    256 bits  128 bits  128 bits
Nonce size          128 bits  128 bits  256 bits
Key size            128 bits  128 bits  256 bits
Tag size            128 bits  128 bits  128 bits
State size         1024 bits  640 bits  768 bits


> 2b) And MORUS will have either 640 bit for the internal state with
> "only" 128 bit keys... OR... the 1280 bit internal state with either
> 128 or 256 bit keys, right?

Yes, but see the link above, it is described there as well.

> Again, I'm assuming that larger internal state and larger key size will
> give a better security margin, right?

It depends. It needs some time people really analyze these in detail.
Larger internal state does not unconditionally imply better properties.

> 
> 3) Is there any comparison (in terms of security) between AEGIS and
> MORUS?

I hope there will be more analysis as CAESAR crypto competition
is nearing its end.

My main intention for dm-crypt is just to show that we need to use
AEAD (authenticated encryption) in future, and the best algorithm we had
now is CAESAR candidates (and recently some SIV variants but someone need
to implement them in kernel).

I am not a theoretic crypto analyst but an engineer that tries to use that
in real world. There is some risk in it, but someone should at least try :-)

Seriously, it can happen that something will be broken in future or something
better will appear. I would like to see much more active discussions between
academic world and practitioners and more innovations here.
(And innovation means also some fails. :)

m.

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Christoph Anton Mitterer]

Hey Milan

I was playing a bit around with this on 4.18.10 with cryptsetup 2.0.5 -
all the current unstable versions from Debian (all tried with LUKS2).


Some questions and things arose:



1) Does --hash have an effect on on anything but PBKDF2?
For PBKDF2, a line like
Keyslots:
  0: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	PBKDF:      pbkdf2
	Hash:       sha512
**************************
	Iterations: 2024276
	Salt:       4f fa 24 69 9a 5e 27 f6 3c b6 47 58 21 cb 4f 08 
	            23 02 3c de 01 df e8 93 bf 21 19 8d 88 58 57 79 
	AF stripes: 4000
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0

will shop up and even hold, e.g.:
	Hash:       sha3-256
**************************

or give me an error when I specify e.g. just "sha3":
Not compatible PBKDF2 options (using hash algorithm sha3).

But according to the manpage it should also:
>Specifies the hash used in the LUKS key setup scheme and  volume
>key  digest  for luksFormat. The specified hash is used as hash-
>parameter for PBKDF2 and for the AF splitter.




2) Does the VK digest and the one for the AF splitter not show up in
luksDump?

There's:
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 76293
	Salt:       55 f8 ec f6 9e 92 d0 4a 75 ff 2d 1e 52 31 7b 5d 
	            a0 d1 20 9c 8e a4 be 24 43 a4 4e df 0d dc 55 bb 
	Digest:     5a 54 5b 8c 3c 50 bc fc fa 4a 22 37 5d 6a 6b f8 
	            ad 04 fa 62 0e 90 45 a0 18 59 3f ce e1 9e 75 1f 
But whatever I set, it always gives sha256 there.




3) Why does such a Tokens:/Digests:/0: pbkdf2 show even up when I
selected argon2id? See below:

# cryptsetup --batch-mode --verbose --use-random --cipher aes-xts-plain64 --key-size 512 --hash sha512 --pbkdf argon2id --type luks2 luksFormat /dev/loop0 key
Existing 'crypto_LUKS' superblock signature on device /dev/loop0 will be wiped.
Key slot 0 created.
Command successful.

# cryptsetup luksDump /dev/loop0 
LUKS header information
Version:       	2
Epoch:         	3
Metadata area: 	12288 bytes
UUID:          	83caef7a-0735-4fe7-990b-cd64522b114a
Label:         	(no label)
Subsystem:     	(no subsystem)
Flags:       	(no flags)

Data segments:
  0: crypt
	offset: 4194304 [bytes]
	length: (whole device)
	cipher: aes-xts-plain64
	sector: 512 [bytes]

Keyslots:
  0: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	PBKDF:      argon2id
	Time cost:  4
	Memory:     1048576
	Threads:    4
	Salt:       b7 09 da 74 b0 69 9a 78 75 14 8a 7a 72 56 ce b0 
	            b2 21 e8 d2 a6 ea a5 c6 8b 32 2a 8a 33 55 5a 56 
	AF stripes: 4000
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 76293
	Salt:       55 f8 ec f6 9e 92 d0 4a 75 ff 2d 1e 52 31 7b 5d 
	            a0 d1 20 9c 8e a4 be 24 43 a4 4e df 0d dc 55 bb 
	Digest:     5a 54 5b 8c 3c 50 bc fc fa 4a 22 37 5d 6a 6b f8 
	            ad 04 fa 62 0e 90 45 a0 18 59 3f ce e1 9e 75 1f 




4) Next I wanted to try an AEAD mode:
# cryptsetup --batch-mode --verbose --use-random --cipher aes-xts-plain64 --key-size 512 --hash sha512 --pbkdf argon2id --cipher morus640-random --key-size 128 --integrity aead --type luks2 luksFormat /dev/loop0 key
Key slot 0 created.
device-mapper: reload ioctl on   failed: No such file or directory
Command failed with code -1 (wrong or missing parameters).


The reason for the error is probably that Debian doesn't have
MORUS/AEGIS modules compiled... yet it gives me a dumpable LUKS
container:

# cryptsetup luksDump /dev/loop0 
LUKS header information
Version:       	2
Epoch:         	3
Metadata area: 	12288 bytes
UUID:          	401977c4-5f57-4346-b256-01d0e7839252
Label:         	(no label)
Subsystem:     	(no subsystem)
Flags:       	(no flags)

Data segments:
  0: crypt
	offset: 4194304 [bytes]
	length: (whole device)
	cipher: morus640-random
	sector: 512 [bytes]
	integrity: aead

Keyslots:
  0: luks2
	Key:        128 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	PBKDF:      argon2id
	Time cost:  4
	Memory:     1048576
	Threads:    4
	Salt:       26 ff e4 24 f4 fa 8a 96 6c 97 78 0f ce 6c 6e 56 
	            f2 71 37 b0 2d 65 73 1f 5b 80 38 ae 81 9d 6e b4 
	AF stripes: 4000
	Area offset:32768 [bytes]
	Area length:65536 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 161418
	Salt:       5f 03 4b 99 60 fa c1 7e 7e 10 64 98 1f 89 b5 97 
	            c0 4e 22 da b8 4a 48 46 9d 19 b4 7f d7 5a 24 0c 
	Digest:     be f8 31 87 ab b4 fe e7 10 85 12 ee 2b a5 63 0c 
	            16 d0 41 f8 1e 9e 4b 03 74 c4 e4 46 be 54 57 97 

=> again, some PBKDF2 references, though Argon2id selected...
=> Why is there some aes-xts-plain64 in it?
=> Even if I change the key size to other values it will store it:
   e.g. cryptsetup --batch-mode --verbose --use-random --hash sha512 --pbkdf argon2id --cipher morus640-random --key-size 1024 --integrity aead --type luks2 luksFormat /dev/loop0 key
        or
        cryptsetup --batch-mode --verbose --use-random --hash sha512 --pbkdf argon2id --cipher morus640-random --key-size 768  --integrity aead --type luks2 luksFormat /dev/loop0 key
   => I thought the only valid value for MORUS640 would be 128? And for
      MORUS1280 it would be 256? Why does it accept other values and
      what would that change?




In case it matters.... kernel gave the following log messages during my
tries above:
Nov 19 20:40:19 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:40:19 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:41:43 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:41:43 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:42:36 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:42:36 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:42:56 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:42:56 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:43:24 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:43:24 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:43:34 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:43:34 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:44:13 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:44:13 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:44:43 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:44:43 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:45:16 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:45:16 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:45:37 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:45:37 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 21:25:02 heisenberg kernel: alg: No test for authenc(hmac(sha256),xts(aes)) (authenc(hmac(sha256-generic),xts-aes-aesni))
Nov 19 21:25:02 heisenberg kernel: device-mapper: crypt: Integrity AEAD, tag size 32, IV size 16.
Nov 19 21:26:13 heisenberg kernel: device-mapper: table: 253:2: crypt: Error decoding and setting key
Nov 19 21:26:13 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 21:26:28 heisenberg kernel: device-mapper: table: 253:2: crypt: Error decoding and setting key
Nov 19 21:26:28 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 21:26:43 heisenberg kernel: device-mapper: table: 253:2: crypt: Error decoding and setting key
Nov 19 21:26:43 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 21:27:04 heisenberg kernel: device-mapper: crypt: Integrity AEAD, tag size 32, IV size 16.

Guess most are because of the missing modules,... but these are strange:
Nov 19 21:25:02 heisenberg kernel: alg: No test for authenc(hmac(sha256),xts(aes)) (authenc(hmac(sha256-generic),xts-aes-aesni))
Nov 19 21:25:02 heisenberg kernel: device-mapper: crypt: Integrity AEAD, tag size 32, IV size 16.



Thanks,
Chris :-)

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Ondrej Kozina]

On 11/19/18 10:03 PM, Christoph Anton Mitterer wrote:
> Hey Milan
> 
> I was playing a bit around with this on 4.18.10 with cryptsetup 2.0.5 -
> all the current unstable versions from Debian (all tried with LUKS2).
> 
> 
> Some questions and things arose:
> 
> 
> 
> 1) Does --hash have an effect on on anything but PBKDF2?
> For PBKDF2, a line like
> Keyslots:
>    0: luks2
> 	Key:        512 bits
> 	Priority:   normal
> 	Cipher:     aes-xts-plain64
> 	PBKDF:      pbkdf2
> 	Hash:       sha512
> **************************
> 	Iterations: 2024276
> 	Salt:       4f fa 24 69 9a 5e 27 f6 3c b6 47 58 21 cb 4f 08
> 	            23 02 3c de 01 df e8 93 bf 21 19 8d 88 58 57 79
> 	AF stripes: 4000
> 	Area offset:32768 [bytes]
> 	Area length:258048 [bytes]
> 	Digest ID:  0
> 
> will shop up and even hold, e.g.:
> 	Hash:       sha3-256
> **************************
> 
> or give me an error when I specify e.g. just "sha3":
> Not compatible PBKDF2 options (using hash algorithm sha3).

Interesting, when applied to LUKS2 it has interesting implications, see 
below.

> 
> But according to the manpage it should also:
>> Specifies the hash used in the LUKS key setup scheme and  volume
>> key  digest  for luksFormat. The specified hash is used as hash-
>> parameter for PBKDF2 and for the AF splitter.

Yes that's correct. The --hash parameter applies also to AF even with 
argon2 (LUKS2). And you may set different hash per keyslot with LUKS2. 
Unfortunately when I was experimenting with it inspired by your 
questions, I discovered ugly bug:

When you request non existing hash the luksAddKey operation or 
luksFormat operation (for LUKS2) would pass even though it should have 
failed. I've created new issue for it: 
https://gitlab.com/cryptsetup/cryptsetup/issues/422

So, thank you for report:)

> 
> 2) Does the VK digest and the one for the AF splitter not show up in
> luksDump?
The hash for AF splitter is not shown in ordinary LUKS2 luksDump 
command. But you can see it, if you add --debug among luksDump 
parameters. If you do, we print complete LUKS2 json metadata. I'm not 
sure if it was omitted from normal luksDump on purpose...

> 
> There's:
> Tokens:
> Digests:
>    0: pbkdf2
> 	Hash:       sha256
> 	Iterations: 76293
> 	Salt:       55 f8 ec f6 9e 92 d0 4a 75 ff 2d 1e 52 31 7b 5d
> 	            a0 d1 20 9c 8e a4 be 24 43 a4 4e df 0d dc 55 bb
> 	Digest:     5a 54 5b 8c 3c 50 bc fc fa 4a 22 37 5d 6a 6b f8
> 	            ad 04 fa 62 0e 90 45 a0 18 59 3f ce e1 9e 75 1f
> But whatever I set, it always gives sha256 there.

It's currently hardcoded to sha256 in LUKS2, for volume key digests. 
There's already issue tracking that: 
https://gitlab.com/cryptsetup/cryptsetup/issues/396

> 3) Why does such a Tokens:/Digests:/0: pbkdf2 show even up when I
> selected argon2id? See below:

Volume key digest is currently always pbkdf2, even with LUKS2.

> 
> # cryptsetup --batch-mode --verbose --use-random --cipher aes-xts-plain64 --key-size 512 --hash sha512 --pbkdf argon2id --type luks2 luksFormat /dev/loop0 key
> Existing 'crypto_LUKS' superblock signature on device /dev/loop0 will be wiped.
> Key slot 0 created.
> Command successful.
> 
(...)
> Digests:
>    0: pbkdf2
> 	Hash:       sha256
> 	Iterations: 76293
> 	Salt:       55 f8 ec f6 9e 92 d0 4a 75 ff 2d 1e 52 31 7b 5d
> 	            a0 d1 20 9c 8e a4 be 24 43 a4 4e df 0d dc 55 bb
> 	Digest:     5a 54 5b 8c 3c 50 bc fc fa 4a 22 37 5d 6a 6b f8
> 	            ad 04 fa 62 0e 90 45 a0 18 59 3f ce e1 9e 75 1f
> 
> 
> 
> 
> 4) Next I wanted to try an AEAD mode:
> # cryptsetup --batch-mode --verbose --use-random --cipher aes-xts-plain64 --key-size 512 --hash sha512 --pbkdf argon2id --cipher morus640-random --key-size 128 --integrity aead --type luks2 luksFormat /dev/loop0 key
> Key slot 0 created.
> device-mapper: reload ioctl on   failed: No such file or directory
> Command failed with code -1 (wrong or missing parameters).
> 
> 
> The reason for the error is probably that Debian doesn't have
> MORUS/AEGIS modules compiled... yet it gives me a dumpable LUKS
> container:

I guess the problem is that we're unable to check the cipher involved in 
aead setup is configured properly (or exists in kernel) before we 
actually try to activate it via dm-crypt mapping. But Milan will know 
better.

Thank you for feedback!
O.

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Christoph Anton Mitterer]

On Tue, 2018-11-20 at 11:08 +0100, Ondrej Kozina wrote:
> Yes that's correct. The --hash parameter applies also to AF even
> with 
> argon2 (LUKS2). And you may set different hash per keyslot with
> LUKS2. 

Has someone ever evaluated whether e.g. the other algos like SHA3-* can
be safely used in these situations?


> > 2) Does the VK digest and the one for the AF splitter not show up
> > in
> > luksDump?
> The hash for AF splitter is not shown in ordinary LUKS2 luksDump 
> command. But you can see it, if you add --debug among luksDump 
> parameters. If you do, we print complete LUKS2 json metadata. I'm
> not 
> sure if it was omitted from normal luksDump on purpose...

Ah I see :-)


> It's currently hardcoded to sha256 in LUKS2, for volume key digests. 
> There's already issue tracking that: 
> https://gitlab.com/cryptsetup/cryptsetup/issues/396
> 
> > 3) Why does such a Tokens:/Digests:/0: pbkdf2 show even up when I
> > selected argon2id? See below:
> 
> Volume key digest is currently always pbkdf2, even with LUKS2.

Isn't both, like a weak element in the whole security chain?
At the one side we try to use Argon2* to get rid of the deficiencies of
PBKDF2... and then it's still used for the VK?



> I guess the problem is that we're unable to check the cipher involved
> in 
> aead setup is configured properly (or exists in kernel) before we 
> actually try to activate it via dm-crypt mapping. But Milan will
> know 
> better.

At least at some point cryptsetup seems to actually get the error...
it's perhaps just that the LUKS container has already been written by
then?



Thanks,
Chris.

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Milan Broz]

On 20/11/2018 14:57, Christoph Anton Mitterer wrote:
> On Tue, 2018-11-20 at 11:08 +0100, Ondrej Kozina wrote:
>> Yes that's correct. The --hash parameter applies also to AF even
>> with 
>> argon2 (LUKS2). And you may set different hash per keyslot with
>> LUKS2. 
> 
> Has someone ever evaluated whether e.g. the other algos like SHA3-* can
> be safely used in these situations?

For AF, any hash function is ok (it just diffuses the information
to multiple sectors, this is a basic property all hash functions provide).

(AF makes no much sense with modern drives anyway, the slot encryption
and KDF is where the security is important.) 

For PBKDF2, I think you can also use any cryptographic hash
(if there is a problem, I guess the hash has problem itself even
without PBKDF2).

Argon2 uses BLAKE2 internally and it cannot be changed.

>>> 3) Why does such a Tokens:/Digests:/0: pbkdf2 show even up when I
>>> selected argon2id? See below:
>>
>> Volume key digest is currently always pbkdf2, even with LUKS2.
> 
> Isn't both, like a weak element in the whole security chain?
> At the one side we try to use Argon2* to get rid of the deficiencies of
> PBKDF2... and then it's still used for the VK?

I think LUKS key digest were discussed here several times and it is apparent
candidate for FAQ.

No, it is not a weak point. Digest is just a convenient way how to check that
candidate decrypted key form keyslot key is correct.

If your RNG is not flawed, the key is random, even if there is one iteration
for PBKDF2 you have to run bruteforce scan. It should be impossible,
so adding weak fingerprint will not make it worse here :)

I do not see any additional value to use Argon2 here. So I preferred
the digest to be always compatible with LUKS1 (just there is hardcoded
sha256, this will be fixed).

So: it is always much simpler for attacker to run bruteforce through
decryption of a sector (for example searching for known ext4 signature).
(Veracrypt for example use this approach.)


>> I guess the problem is that we're unable to check the cipher involved
>> in 
>> aead setup is configured properly (or exists in kernel) before we 
>> actually try to activate it via dm-crypt mapping. But Milan will
>> know 
>> better.
> 
> At least at some point cryptsetup seems to actually get the error...
> it's perhaps just that the LUKS container has already been written by
> then?

We are checking availability of encryption in kernel by calling
encryption of one sector. But I did not yet implemented this function
for AEAD modes. So it fails too late - yes, it is ugly, but we will fix it.

Milan

p.s.
You already found one nice bug (non-existant hash is written to metadata),
and it was consequence of two issues. The first one is our apparent fault
(missing check, despite TODO in code:-) and one very old bug in AF/LUSK1
(this part of code is shared; it lost the error exit code, it otherwise
failed much earlier).
Fixed already in devel branch, but it need more review.

Thanks for the report!

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Christoph Anton Mitterer]

On Tue, 2018-11-20 at 17:05 +0100, Milan Broz wrote:
> For AF, any hash function is ok (it just diffuses the information
> to multiple sectors, this is a basic property all hash functions
> provide).
> 
> (AF makes no much sense with modern drives anyway, the slot
> encryption
> and KDF is where the security is important.) 
Well but here too, it would be good if cryptsetup warns for anything
that's not sane... e.g. if hash algo xyz would be not fine with the
KDF.

Or like when you said -plain64 shouldn't be used with AEAD... or
-random shouldn't be used with non-AEAD.


> I think LUKS key digest were discussed here several times and it is
> apparent
> candidate for FAQ.
> 
> No, it is not a weak point. Digest is just a convenient way how to
> check that
> candidate decrypted key form keyslot key is correct.
Ah I see.. well then it's clear of course.

> We are checking availability of encryption in kernel by calling
> encryption of one sector. But I did not yet implemented this function
> for AEAD modes. So it fails too late - yes, it is ugly, but we will
> fix it.
Well at least it already fails "properly"... i.e. giving an error
message and exit code non-0.


> You already found one nice bug (non-existant hash is written to
> metadata),
> and it was consequence of two issues. The first one is our apparent
> fault
> (missing check, despite TODO in code:-) and one very old bug in
> AF/LUSK1
> (this part of code is shared; it lost the error exit code, it
> otherwise
> failed much earlier).
> Fixed already in devel branch, but it need more review.

You've also noted that it seems to store bogus key-sizes?
Like when I did:
>cryptsetup --batch-mode --verbose --use-random --hash sha512 --pbkdf argon2id --cipher morus640-random --key-size 1024 --integrity aead --type luks2 luksFormat /dev/loop0 key
it gave:
>Keyslots:
>  0: luks2
>        Key:        1024 bits
but AFAIU, MORUS640 should always have 128, while for MORUS1280 it's
256, right?


Last thing I don't understand:
Why - despite of using e.g. MORUS - does it still give me aes-xts-
plain64 in the keyslot?:
>Keyslots:
>  0: luks2
>        Key:        512 bits
>        Priority:   normal
>        Cipher:     aes-xts-plain64
>        PBKDF:      argon2id
>        Time cost:  4
>        Memory:     1048576
>        Threads:    4

?

Thanks,
Chris.

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Milan Broz]

On 20/11/2018 18:07, Christoph Anton Mitterer wrote:
> You've also noted that it seems to store bogus key-sizes?
> Like when I did:
>> cryptsetup --batch-mode --verbose --use-random --hash sha512 --pbkdf argon2id --cipher morus640-random --key-size 1024 --integrity aead --type luks2 luksFormat /dev/loop0 key
> it gave:
>> Keyslots:
>>  0: luks2
>>        Key:        1024 bits
> but AFAIU, MORUS640 should always have 128, while for MORUS1280 it's
> 256, right?

But if fails in the end, right (in the worst case on activation)?

Actually it is the same problem - once we can check AEAD modes availability,
it can fail early (key is just one attribute to check).
For now it creates valid  LUKS2 with stored 1024bit key (it works, because it
fallbacks to non-AEAD encryption for keyslot, see below) and just fails
later. Yes, it is user unfriendly, I know...
(Perhaps hardcoded values to check would be better here for now.)

... 
> Last thing I don't understand:
> Why - despite of using e.g. MORUS - does it still give me aes-xts-
> plain64 in the keyslot?:

I think described it somewhere, but apparently not in manual:

We cannot use AEAD mode for keyslots (no problem, because it is authenticated
through the digest already).
In this case it fallbacks to default algorithm (aes-xts).
There will be options to change encryption per-keyslot (format allows it),
but again it is not yet implemented (but it still have to be a length-preserving
mode, not AEAD).

Milan

p.s.
I wish we have more time to fix these issues much quicker.
It is not my ignorance :)

Re: [dm-crypt] some questions on dm-crypt/cryptsetup and LUKS2+integrity

[Christoph Anton Mitterer]

Hey.

Better late than never... (I shall hope) ^^


On Tue, 2018-11-20 at 18:54 +0100, Milan Broz wrote:
> On 20/11/2018 18:07, Christoph Anton Mitterer wrote:
> > You've also noted that it seems to store bogus key-sizes?
> > Like when I did:
> > > cryptsetup --batch-mode --verbose --use-random --hash sha512 --
> > > pbkdf argon2id --cipher morus640-random --key-size 1024 --
> > > integrity aead --type luks2 luksFormat /dev/loop0 key
> > it gave:
> > > Keyslots:
> > >  0: luks2
> > >        Key:        1024 bits
> > but AFAIU, MORUS640 should always have 128, while for MORUS1280
> > it's
> > 256, right?
> 
> But if fails in the end, right (in the worst case on activation)?

Either I haven't checked this back then, or I just forgot the outcome.
But with cryptsetup 2.0.6 it fails as it should:
# cryptsetup --batch-mode --verbose --use-random --hash sha512 --pbkdf argon2id --cipher morus640-random --key-size 1024 --integrity aead --type luks2 luksFormat /dev/loop0 key
Cipher morus640-random (key size 1024 bits) is not available.
Command failed with code -1 (wrong or missing parameters).
# echo $?
1


> Actually it is the same problem - once we can check AEAD modes
> availability,
> it can fail early (key is just one attribute to check).
> For now it creates valid  LUKS2 with stored 1024bit key (it works,
> because it
> fallbacks to non-AEAD encryption for keyslot, see below) and just
> fails
> later. Yes, it is user unfriendly, I know...
> (Perhaps hardcoded values to check would be better here for now.)

I think in any case, if such a failure (invalid parameters) occurs an
unusable LUKS header should be created (in format, and unusable key
slots when adding keys, etc), maybe as a safety simply zeroing the
header (respectively the keyslots).

If cryptsetup (even though bailing out with an error) produces a
working (but because of fallback defaults possibly weaker) volume,... a
user may end up using it accidentally.


> I wish we have more time to fix these issues much quicker.
> It is not my ignorance :)

No worries… your efforts are greatly appreciated :-)



One further thing that came up on my questions list, with
LUKS2+integrity:

Is there a formula to calculate for a given size of the "opened" LUKS
device (i.e. the usable size as shown e.g. by blockdev --getsize64),
the required size for the underlying device?

Obviously it won't just be <desired data size>+<size of metadata area>,
as one has the integrity information in addition (which varies of
course with the size).


Thanks,
Chris.