[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: cgd(4) ciphers
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
(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,
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 ;)
Main Index |
Thread Index |