Mailinglist Archive: opensuse (3337 mails)

< Previous Next >
Re: [opensuse] cryptoloop
  • From: Henne Vogelsang <hvogel@xxxxxxxxxxxx>
  • Date: Fri, 21 Apr 2006 17:44:54 +0200
  • Message-id: <20060421154454.GR15857@xxxxxxxxxxxx>

On Friday, April 21, 2006 at 17:07:01, Oliver Tennert wrote:
> 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?

Ive never stated that cryptoloop is better than dm-crypt. I stated that
dm-crypt is not the best working solution that exists.

> > 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.
> 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.

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).

> > > 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.

The only thing that happend in dm-crypt.c since 2003 is the
implementation of essiv. Nothing else.

> 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;)

I wont repeat again that its not only that i did so several times in the
last mails even in this one...

> > 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.

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?

> 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).

> 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).

Please keep in mind this does not mean that we will never change the
cryptofs implementation again!!! It just means that while we made that
switch it made more sense for us to wait than to switch to dm-crypt.


Henne Vogelsang, Core Services
"Rules change. The Game remains the same."
- Omar (The Wire)

< Previous Next >
Follow Ups