[dm-crypt] Questions about new ciphers

Milan Broz gmazyland at gmail.com
Sun Jan 14 16:33:44 CET 2018


thanks for asking, actually this is probably the best way how to get some feedback

On 01/13/2018 05:57 PM, Geo Kozey wrote:
> Hi, I have two more questions, this time about new experimental ciphers with
> authentication.
> 1. What happens when integrity check fails during unlocking container, i.e.
> due to data corruption? Can we still unlock such container?

Unlocking should never fail because of data integrity check (only if a keyslot
or both LUKS2 header copies are corrupted. Then it is basically the same problem
like in corrupted LUKS1 header - you have to use backup header).

IOW: unlocking (luksOpen) will always map the device, only the later access to device
could fail with integrity error (that is propagated to userspace as IO error).

You can overwrite such a failed sectors using direct-io write to fix auth tags then.

> 2. I know there is a IV reuse problem with current AE ciphers. What amount of
> data (roughly) can be written to disk before probability of such reuse will be
> significant?

This is very interesting question and I expected to have some more formal analysis.
Unfortunately, math people I asked lost interest, so below is my short explanation.

It should be in accordance of more qualified people that noted it immediately here
https://twitter.com/solardiz/status/882163531176697857 :-)

So, my analysis:

We have a sector that uses 96-bit randomly generated nonce used for IV,
if we used birthday paradox, we should expect collision after 2^48 (half of 2^96) generated nonces.

The nonce is generated for every sector write, so simple multiplication gives us
128 PB for 512-byte sectors or 1024 PB for 4k-sectors.

Unfortunately, for GCM mode, NIST (in SP 800-38D) limits total number of IV invocations for the same
key to 2^32. This means (according to SP above) we should have problem after writing of 2 TB of data
for 512-bytes sector or 16 TB with 4k-sector. This is pretty bad.

For Chacha20-poly1305 it internally uses also 96bit nonce (we use it in RFC7539 mode).
I do not have more formal analysis here, it should not be worse though.

(The attack above expects attacker can store all sector changes including auth. tags.)

So, my plan is to switch to more secure authenticated modes in future, and actually we have
already very nice progress - Ondra Mosnacek implemented AEGIS and MORUS ciphers from
CAESAR competition and specifically for AEGIS the performance in dm-crypt looks very good.
But the CAESAR is not yet finished and tweaks are expected...

If you are interested, read his master thesis, it is not yet defended, but the text should
be already public here https://is.muni.cz/th/409879/fi_m/masters-thesis.pdf
(or from here https://is.muni.cz/th/409879/fi_m?lang=en )
The text also compares existing modes (like GCM).

Using of these modes should solve the problem for real, because with at least 128bit nonces
and kind-of nonce reuse resistance we should not have the problem above.


More information about the dm-crypt mailing list