Re: cgd(4) ciphers

(I reordered your paragraphs to put related parts together.)

   Date: Tue, 01 Oct 2013 00:14:17 +0200
   From: Jean-Yves Migeon <[email protected]>

   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.

   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.

   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.

   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.  But I meant to focus on
Threefish, with the older Serpent as a more conservative fallback.