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