On Fri, 21 Apr 2006, Henne Vogelsang wrote: > Hi, > > On Friday, April 21, 2006 at 18:17:55, Oliver Tennert wrote: > > > It is clear. So, in your opinion switching to cryptoloop in SLES _now_ > > (yes, I have learnt now that SUSE 9.2 already had it too) is > > preparing you (and your enterprise clients) for the future? > > Ive already told you a couple of times (so did others) that we are not > switching now. We already switched a long time ago. >
I conceded this in the parentheses, didn't I? Switching to cryptoloop in SUSE 9.2 was the right thing then. It is nonsense to do so now in SLES 10. > Im sorry but i really dont see what your point is (except that you want > us to switch to dm-crypt __now__). > OK, for the n-th and last time, this is my point: There are reasons to consider dropping cryptoloop and switching to dm-crypt. Why? Because: - cryptoloop is dead, unmaintained and threatened to be thrown out of the vanilla kernel since years. Please read http://kerneltrap.org/node/3521. The only objection to not do that is given by people who have problems updating their tolls, as I already mentioned. - cryptoloop can only do plain IV which is totally insecure - cryptoloop is bad code, it cannot encrypt swap partitions, it needs a separate API for itself - the cryptoloop kernel help text says it is unsafe to use it with journaled file systems, as I also quoted before On the other hand: - dm-crypt can be used in a cryptoloop-compatible way, which is good for those users who already have cryptoloop-encrypted volumes - for all the others who do not need compatibility (i.e. for all new volumes), dm-crypt offers ESSIV which is very much more secure than plain IV - dm-crypt uses the device mapper and does not need a separate user space API like "losetup -e" - dm-crypt is swap safe and therefore offers swap encryption - dm-crypt is the basis for LUKS which offers a superior ondisk layout even with multi-user capability (which is optional of course and need not be used now) - every other one is using dm-crypt, too, why not SUSE? These are my arguments. Yet you speak of future-orientation and therefore in favor of cryptoloop, while waiting for an ultimate future solution that does not exist yet. 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]
