Re: cgd(4) ciphers

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

Le 02/10/13 17:32, Taylor R Campbell a écrit :
> (I reordered your paragraphs to put related parts together.)
>
>     Date: Tue, 01 Oct 2013 00:14:17 +0200
>     From: Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>
>
>     More than another cipher suite though, I think that cgd(4) needs a good
>     overhaul. Currently I am more worried about separated /etc/cgd/ config
>     files (not that convenient to manipulate), and the relative difficulty
>     to provide full-disk encryption.
>
> I agree that we need to support full-disk encryption better.  We also
> need to support swap encryption better, with at most as little effort
> as a single sysctl knob to turn on, if we don't just do it by default.
> But I don't have time to implement those in a few hours, which is all
> a new cipher should take.  We can discuss those in another thread.

I pointed this out in case someone else read this thread later on. You 
are right, let's move on.

>     If we go for a cipher/mode/IV combo that no one else support, this can
>     become either a great success or a great failure. We have to be careful
>     there. I would discuss this with other *BSD instead of keeping it on
>     tech-sec@.
>     [...]
>     (Thinking out loud) With LVM now in the place, perhaps a
>     dm-crypt-lookalike seems better?
>
> cgd already uses a format that nobody else uses.  It may be worthwhile
> to support compatibility with Linux dm-crypt and luks or with FreeBSD
> geli, but that is separate from the goal of providing a high-quality
> disk encryption system for NetBSD.

As above.

>     Cipher is just one part of the equation, available modes also play a
>     role as wll as IV generation.
>     [...]
>     Modern alternatives to CBC-ESSIV (like XTS-PLAIN) also suffer from the
>     augmentation of disk sizes.
>
> I never understood why the NIST pushed XTS.  As far as I can tell, it
> is a needless complication of XEX.
>
> That aside, using any tweakable block cipher for disk encryption,
> whether it is natively tweakable like Threefish or built from a simple
> block cipher like XTS and XEX, leaks more information than CBC-ESSIV:
>
> - For a tweakable block cipher, two disk snapshots reveal which cipher
> blocks didn't change.
> - For cgd and CBC-ESSIV, two disk snapshots reveal which prefixes of
> disk sectors didn't change, in units of cipher blocks.
>
> We could perhaps do better: BitLocker applies a diffuser to each disk
> sector before encrypting it, and BEAR/LION/LIONESS effectively do so
> too as part of their constructions.  But more complexity, more code,
> &c.

That's the main reason behind bitlocker's elephant I guess.

>     It all boils down to what can be done: I have no idea how much time is
>     needed to get a new cipher implemented within cgd(4), but the first step
>     is to chose one. And that does not look very trivial to me.
>
>     What makes you think that Serpent fills that role better than AES/Rijndael?
>
> I thought I addressed this in my message.

Not really. Both have same block size, side channels are indeed a 
problem but is more a matter of implementation than algorithm. So I 
cannot see why implementing Serpent would be any more useful than using 
the actual AES (except that we lose hardware acceleration in some cases, 
as well as a more the testing and review from AES).

> But I meant to focus on
> Threefish, with the older Serpent as a more conservative fallback.

IMHO I would not bother with Serpent for that case then.

Threefish is not subject to (b) and (c), but will remain purely software 
(which means you will not get (d) easily with Threefish). At first 
glance I have no objection to it, and the people that worked on it 
(Skein team) have serious background ;)

--
Jean-Yves Migeon