I am beginning to sigh myself... On Fri, 21 Apr 2006, Henne Vogelsang wrote:
Ive never stated that cryptoloop is better than dm-crypt. I stated that dm-crypt is not the best working solution that exists.
It is better than cryptoloop, that is for sure and suffices within the domain of this discussion.
Again *sigh* :) we are not talking about today. We are talking about the future. We cant manoeuvre ourself in a position where providing an upgrade path is impossible (its getting more and more likely with each implementation change).
Come on. Don't only sigh. Try not to contradict yourself. If you plan to be future-oriented, it is complete nonsense to NOW switch to cryptoloop in SLES, instead of e.g. switch to dm-crypt in SUSE 10.1 and let SLES 10 be the same as SLES 9 with regard to encrypted volumes. Your argument is perverse: Switching to cryptoloop may manoeuvre yourself in a position where providing an upgrade path is impossible, not switching to dm-crypt. Let us talk about it: What is the issue about upgrade paths? It is not about startup scripts, it is about the ondisk layout of the encrypted volumes. That's the issue. With cryptoloop-compatible solutions, a change of encryption types or layout means copying away all the data, recreating a new volume, and then copying all the data back. This is painsome to the clients. dm-crypt offers you compatibility and therefore it is at first unnecessary to provide the above-sketched upgrade paths. On the other hand, it has a cleaner code and allows you to also encrypt swap space. What else do you want?
The only thing that happend in dm-crypt.c since 2003 is the implementation of essiv. Nothing else.
Sorry, now it is beginning to really become ridiculous: using dm-crypt allows you e.g. to safely encrypt swap partitions, due to the use of memory pools. The implementation of ESSIV alone would be reason to switch to dm-crypt. You get a plethora of advantages and retain compatibility. What is your scepticism about?
Ok the maybe you dont understand what i mean by upgrade path's fully. Upgrade paths are not only about getting someone from the "past" to the "now" but also getting from the "now" _and_ the "past" to the "future". Is that more clear?
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?
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.
If dm-crypt will be the solution of the future yes. We are very unsure about that. If it is not this move a full way into "some" direction. This means we not only have to provide an upgrade path from 3 different implementation but from 5 different implementations (and 3*5 previous upgrade scenarios).
Surely nobody knows what will be the ultimate solution in 10 years.This is irrelevant because a software solution mostly is a solution for about 3-5 years then something else comes. This has always been the case and will continue to be so. At present, however, every other distro (name one relevant which isn't) is using dm-crypt and most of them are trying to integrate even LUKS. Do you think is is for no good reason? So, what kind of development in the market of volume encryption are you waiting for? A final solution will never exist.
But cryptoloop is full-way into the wrong direction.
Its not. Its a full stop (which we pulled with 9.2 after we analysed the state of the cryptofs implementations back then).
No, sorry. It is reverse gear, full speed. And certainly it is not future-directed as you wish. You will be proved when SLES 10 is going to be reviewed by the community and the press and prone to ridicule if that item in the release notes will be read. 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