Le 30/09/13 09:22, Taylor R Campbell a écrit :
The set of ciphers supported by cgd is showing its age. It would be nice if cgd supported a block cipher that (a) has high public confidence, (b) can be easily implemented without timing side channels; (c) has 256-bit blocks, so we don't need to worry about birthday bounds for 128-bit block ciphers on multi-terabyte disks; and (d) is fast in software without hardware acceleration, because cgd can't take advantage of AES-NI at the moment and not all the world is a modern high-end x86 system. [snip] The best two candidates that come to mind are Serpent, which fails only (c) and (d), and Threefish, which seems like a good candidate. Both were designed to avoid using data-dependent branches and memory references. Both have been subjected to thorough scrutiny and were finalists in NIST competitions.
Cipher is just one part of the equation, available modes also play a role as wll as IV generation.
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@.
Thoughts?
Regarding point 'b': birthday attacks do increase with volume size, however you could circumvent this by having multiple partitions and concatenate them. Not as practical as a cipher suite that support multi-TiB partitions, but still doable.
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.
(Thinking out loud) With LVM now in the place, perhaps a dm-crypt-lookalike seems better?
Modern alternatives to CBC-ESSIV (like XTS-PLAIN) also suffer from the augmentation of disk sizes. Having warnings when someone is trying to encrypt a 500GiB/1TiB partitions can be a short, temporary fix (in the sense of: "you can shoot yourself in the foot, but you have been warned").
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? -- Jean-Yves Migeon