On 2006-04-21 14:59:27 +0200, Pascal Bleser wrote:

http://en.opensuse.org/Category:SDB

BTW, the layout of the last link above is really weird here (ffox 1.5.0.1, same with konqueror and opera9)

known. will be fixed with the next update. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org

I am very interested though I must say that I am even more interested in not only integrating dm-crypt (which is more or less trivial) but also LUKS as THE default encrypted volume format as well.

Moreover, the most non-trivial part is integrationg LUKS in a way to encrypt the root fs, too, which needs patching the initrd.

I have not managed to get LUKS to work, but then, I didn't try very hard. My setup is also not usable for the root partition, it currently mounts from boot.local rather than boot.d; I wasn't able to create a working script for boot.d.

Am Freitag, 21. April 2006 15:23 schrieb Carl-Daniel Hailfinger:

And back at the time it was said that dm-crypt had the same problems. Maybe these problems have been solved, maybe not.

There are two kinds of problems: a) problems regarding the cryptoloop implementation b) problems regarding the encryption mode a) is solved because there is dm-crypt which may be used on-disk compatible with cryptoloop, but has the advantage that is actively maintained and using the device-mapper infrastructure. as of b) when dm-crypt is used with plain IV mode, the encryption weakness still remain of course. The point is that it offers enhanced security (not PERFECT security of course!) because it offers other IV generation schemes, too.

At the time SUSE switched to cryptoloop, dm-crypt was still broken. So exchanging an out-of-tree disk encryption solution with an in-tree solution that worked was the best option back then.

dm-crypt is as intree as cryptoloop is. The difference is: cryptoloop is not maintained any more, whereas dm-crypt is. Moreover, have a look at the kernel cryptoloop help text: "WARNING: This device is not safe for journaled file systems like ext3 or Reiserfs. Please use the Device Mapper crypto module instead, which can be configured to be on-disk compatible with the cryptoloop device."

Since you refered to a quote from Jari Ruusu about the insecurity of cryptoloop, please try to find a quote from Rari Ruusu where he praises LUKS or dm-crypt. You won't find any. Instead you will find some quotes from Jari Ruusu where he criticizes them, too.

Maybe Jari Ruusi is not praising dm-crypt. But to be honest, Jari Ruusu has always been developing a competing project (loop-AES), so he may be biased. The insecurity of cryptoloop is not founded on his statements alone, although his arguments are right by themselves. I may be allowed to refer you again to Clemens Frühwirth's homepage which is full of documentation about the weaknesses of plain IV scheme. I may also refer to the one of the forthcoming issues of the German ct magazine where the subject is dwelt upon, too.

So according to your own arguments, SUSE should NOT ship LUKS or dm-crypt.

I cannot follow this logic. According to you, as dm-crypt is not proven to be secure, one should switch to something which is proven to be certainly be insecure and unmaintained? Best regards Oliver -- Going to church does not make a person religious, nor does going to school make a person educated, any more than going to a garage makes a person a car. -- __ ________________________________________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

On Fri, Apr 21, 2006 at 03:00:28PM +0200, Oliver Tennert wrote:

Am Freitag, 21. April 2006 14:43 schrieb Lars Hecking:

...

...

Now, obviously SUSE ist going to switch from an absolutely not widespread solution to an obsolete solution, and furthermore announces this as a novelty for the next-generation enterprise distro. What is this? Every other Distro (Fedora, RedHat, Debian, Ubuntu et al.) is using dm-crypt and even going to

gentoo :)

...

integrate LUKS, only SUSE does not!

I really do NOT understand that in any way. Does anybody else?

I certainly don't - cryptoloop is not only obsolete, but has serious problems. Which is why I hacked dm-crypt support into 9.2, and I'm pretty sure it transfers to 10.0/10.1. Email me if you're interested in scripts and instructions, I meant to publish it all on ILUG but didn't find the time yet.

I am very interested though I must say that I am even more interested in not only integrating dm-crypt (which is more or less trivial) but also LUKS as THE default encrypted volume format as well.

Moreover, the most non-trivial part is integrationg LUKS in a way to encrypt the root fs, too, which needs patching the initrd.

Now, what I do not understand is: how come such a transition decision is made? It has nothing to do with (software) evolution, nor is it intelligent design. Therefore, it must be a MANAGEMENT DECISION.

We did so for SUSE Linux 9.3. At this time dm-crypt was not ready. Exchanging the crypto system, with all problems of backwards compatibility, is very difficult and error prone. We would have to throw a lot resources at it to get it right, but did not have them in the 10.1 timeframe now. We have to address this in the future, but for 10.1 its too late. Ciao, Marcus

Am Freitag, 21. April 2006 15:35 schrieb Henne Vogelsang:

...

I understand that (Open)SUSE 10.1 ist going to be the test arena for SLES 10, or am I wrong?

You do. They are from the same codebase yes but SUSE Linux is no testbed for SUSE Linux Enterprise 10!

OK, I put it another way: the experience you get from SUSE 10.1 surely influences SLES development.

dm-crypt is far away from being the standard for encrypted filesystems.

If you define "standard" to be the most deployed solution, then yes it is. cryptoloop surely is completely out.

It has the same problem with weak IV generation as cryptoloop. And ESSIV is not very well analyzed yet (the things someone like David Wagner says about it do not help either). It does not bring any significant advantages over cryptoloop that justify the main problem we have with making a switch. You have to provide an upgrade path. And with enterprise products you have to provide an upgrade path for several years (read 7). This means that the more often you switch the implementation the more scenarios you have to cover in your upgrade path and the likelier you will fail to provide one. [1]

I do not understand that: surely you need an upgrade path when you break compatibility. But if you don't then the upgrade path is as trivial as it is when switching to cryptoloop. The advantage you get however if you switch to dm-crypt is: actively maintained code plus additional features and enhanced security.

On a sidenote: Everything you need to use dm-crypt is included since several versions. Its just not default in YaST.

Yes, I know. So: why not use it?

Please als note: All the current cryptofs implementations are far from being complete (and good in a cryptographic sense). For instance they dont provide fundamental cryptographic needs like providing integrity (prevent corruption, reverting, swapping attacks) or prevention against watermarking.

The ESSIV generation scheme is _the_ protection against simple watermarking attacks. This is one of the reasons it has been developed.

So in short, simply because its new and everybody else uses it its not better in any way.

First: dm-crypt is not new, but intree since 2.6.4. Second: switching to something obsolete and unmaintained surely is wrong. Best regards Oliver -- You first have to decide whether to use the short or the long form. The short form is what the Internal Revenue Service calls "simplified", which means it is designed for people who need the help of a Sears tax-preparation expert to distinguish between their first and last names. Here's the complete text: "(1) How much did you make? (AMOUNT) "(2) How much did we here at the government take out? (AMOUNT) "(3) Hey! Sounds like we took too much! So we're going to send an official government check for (ONE-FIFTEENTH OF THE AMOUNT WE TOOK) directly to the (YOUR LAST NAME) household at (YOUR ADDRESS), for you to spend in any way you please! Which just goes to show you, (YOUR FIRST NAME), that it pays to file the short form!" The IRS wants you to use this form because it gets to keep most of your money. So unless you have pond silt for brains, you want the long form. -- Dave Barry, "Sweating Out Taxes" -- __ ________________________________________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

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

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

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

On Fri, 21 Apr 2006, Carl-Daniel Hailfinger wrote:

SLES 10 is exactly SUSE Linux 10.1 with better and longer support.

Please read the sentence above again.

Please try to understand that fact.

Now you can see that there is no switch happening right now. It happened years ago.

Alright, now I got another point, sorry for not grasping that fact at once. I was misled by the conception that whereas in the consumer series cryptoloop has been uswed since 9.2, in the enterprise series this is only the case in the forthcoming release. Sorry about that misunderstanding. Sorry Carl-Daniel, sorry Henne. Nevertheless what I said about the technical side regarding cryptoloop vs. dm-crypt remains the same, and SUSE may reconsider bringing the announcement in question in the release notes of SLES 10. And SUSE should consider evaluating dm-crypt as soon as possible, in my opinion. 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

On Fri, 21 Apr 2006, Henne Vogelsang wrote:

Hi,

On Friday, April 21, 2006 at 20:24:30, Oliver Tennert wrote:

...

And SUSE should consider evaluating dm-crypt as soon as possible, in my opinion.

As you are obviously very familiar with that stuff would you care to help? Maybe we can start by creating a wiki page gathering information about the current state of everything. I have a lot of information in a document i made two years ago but im not sure if all that is still valid.

I would certainly like to have a look at it. And Wiki sounds always good.

We definately need to do something _for_ the future and we need to keep up to changes in that area.

Would you care to take on the title "openSUSE cryptofs officer"? :)

Would that be equivalent to a senior solutions engineer rubber title or below? :) I also certainly wouldn't say no if you are asking me to review concepts, submit patches to scripts and so on. I certainly have no vacancies left to take over any sort of maintainership, unfortunately. And I'm not a cryptographer either, so hardcore crypto review is outside my capabilities, as are in-depth kernel implementation issues. I neither may not be the best man to write YasT plugins and the like, as it would mean learning a lot of stuff concerning the python (?) backend to YasT. Furthermore, some of SUSE's administrative interfaces seem to change from time to time, to put it mildly:) 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

On Fri, 21 Apr 2006, Carl-Daniel Hailfinger wrote:

Not correct. Last change in drivers/block/cryptoloop.c happended 2005-09-02 by Herbert Xu. That one however was not crypto related.

Correct.

On the other hand, the last change in drivers/md/dm-crypt.c happened 2006-03-27 by Andrew Morton.

Which says that dm-crypt IS being maintained, all right?

Much more notable is that dm-crypt always leaked its key, a bug that was only fixed in January 2006. Such a bug is obviously not a sign of quality.

Come on. This key leaking issue is not part of the concept. Such things are called bugs, and removing them is called debugging, which IS a sign of quality because it shows that the code is being constantly object to review and testing. Would you say the absence of such patches in cryptoloop.c is a sign of superior quality than this?

And I wouldn't describe "always leaking the key" as enhanced security either. But it surely is an additionaly feature from the attacker's point of view.

I take this as a humorous side, if you don't mind:) 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