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 O.Tennert@science-computing.de www.science-computing.de