On Fri, 21 Apr 2006, Henne Vogelsang wrote:
> I define standard to be the best working solution that exists.
Well, then define what "best solution" means. As the functionality in
dm-crypt is enhanced plus the security problems are surely not greater
than with
cryptoloop, but most probably (to understate a bit) less, then dm-crypt is
the better one, isn't it?
> The switch to cryptoloop in 9.2 was far from being trivial as i noted.
> The same happens if we migrate now to dm-crypt and what comes after
> dm-crypt? There are already other implementations "in the pipe"
> (CryptFS, NCryptFS, Reiserfs4 with crypto module, acrypto, etc.). As i
> pointed out this is something we have to seriously consider given the
> timeframes of an enterprise product.
Well, now you mustn't just lump them all together: if you look at the
development of encrypted fs solutions for Linux (and even for Windows)
then there is a clear tendency towards volume-based encryption, which can
easily be proven to you. This does not mean, however, that there aren't
any file- or file-system based solutions, too, which are being actively
developed.
But the advantaged of volume-based encryption are simply too obvious to
be discussed upon: swap space can be
encrypted, metadata are, raw devices can etc etc. So it surely makes
sense to decide in favour of it.
And to be honest: how far is Reiser4 from being included in the vanilla
kernel? How tested are all the solutions you mentioned? I estimate: none
of them is even superficially, so they are no viable alternatives at the
moment.
>
> > The advantage you get however if you switch to dm-crypt is: actively
> > maintained code plus additional features and enhanced security.
>
> In reality dm-crypt is as maintained as cryptoloop
Is it? I just have a look at cryptoloop.c and see the latest changes are
dated 2003. As I already mentioned the previous maintainer Clemens
Fruehwirth, practically left the code rot or to be devoured by the
vultures, because he is now favouring LUKS on top of dm-crypt (as every
other distro community is, too).
Andrew Morton and some other people try again and again to get completely
rid of the cryptoloop module, were it not for the arguments of many that
for "compatibility reasons" it must stay. And I think this really means
people simply do not want ro rewrite their startup scripts;)
>and the enhanced
> security is not very well analyzed.
Right, but the old one is: it is a complete disaster. So, you do not lose
anything by switching to dm-crypt, even if you use plain IV generation
mode.
> Hm maybe we weren clear on this. The switch already happend with SUSE
> Linux 9.2 (and afair also in some SLES9 service pack). It is not
> happening now. Its mentioned in the release notes of SLES10 because
> thats the first SLES version since SLES9 that uses cryptoloop as
> default. Switching in CODE10 products (SL10, SLES10) would mean another
> switch.
I see, so I have misunderstood that. Nevertheless: the point is: you do
not lose anything by dropping cryptoloop and using dm-crypt, even when
retaining the old-fashioned plain IV mode. You just have to rewrite your
startup scripts a bit, that's it. The compatibility is there, no
non-trivial upgrade path is necessary.
Then you are halfway to a future solution which is completely based on
LUKS or any other format with a secure IV generation mode, i.e. half way
into the right direction.
But cryptoloop is full-way into the wrong direction.
Best regards
Oliver
__
________________________________________creating IT solutions
Dr. Oliver Tennert
Senior Solutions Engineer
CAx Professional Services
science + computing ag
phone +49(0)7071 9457-598 Hagellocher Weg 71-75
fax +49(0)7071 9457-411 D-72070 Tuebingen, Germany
[EMAIL PROTECTED] www.science-computing.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
