[dm-devel] my encryption

[jon at kollegiegaarden.dk]

On Mon, Oct 13, 2003 at 02:43:31PM +0200, Christophe Saout wrote:
> Am Mo, den 13.10.2003 schrieb jon at kollegiegaarden.dk um 13:54:
> 
> > As far as i remember:
> > it can not change password without reencrypting the whole device
> 
> That's not correct. Doing this (without reencryption) is a pure
> userspace issue. I haven't released any userspace tools yet, but this
> isn't an issue with the in-kernel target.

please explain how you would do it then.


> > It doesnt shuffle the sectors arround
> > (the freebsd GDBE does this)
> 
> Yes, I've read the paper. It's somewhat impressive. I like the ideas.
> The current (cryptoloop compatible) way looks like a joke compared to
> GDBE. But what I dislike with GDBE is that the ciphers used are fixed
> and some things apparently can only be changed with recompiling it.

you cant even specify that at the commandline ?
So after a recompile it might, or might not be compatible with
your data ?


> I think there has to be a more flexible way.
> 
> > It's not cross-platform.
> 
> Huh? It's only a device-mapper target, how can that be cross-platform?
> It's tied to linux 2.6, yes.

during the debate on slashdot about GDBE i realized that there is a need
for an encrypted blockdevice readable by more than one OS. Since i know
linux, and i prefer GPL over the BSD license, i find it easier to
port/copy/clone/... GDBE to Linux, (or make a specification and implement
that).


> > naturally it can be changed, but untill someone actualy does this...
> 
> I'm still willing to do this. I'm currently in a "waiting position".
> I've read the GDBE papers and think we should go in that direction.
> Possibly extend it to be able to load certain "personalities" (e.g.
> cryptoloop compatible or GDBE like).

fine, go ahead then, i obviously cant compete with your code developing
speed, and i've got other ideas for projects i can do.


> Adding these features to the core target, like shuffling of sectors,
> automatically reading and caching these additional "encryption meta data
> sectors" would require much more complexity though.

i know, but i think it is worth it.


> I personally like clean and flexible solutions and I think that my
> cryptoloop compatible target is a clean one (compared to the cryptoloop
> implementation) and it also seems to perform quite reasonably. I don't
> like quick and dirty (no offence, I haven't seen your code yet) hacks.

well, it leaks memory, so i it must be rather ugly, though i dont think
it's that bad, but hey, i've gotta think that ;-P


> If you are finished with your "official" work I would like to see us
> cooperating. Working against each other seems like a waste of efforts,
> especially because I'm doing this for fun and in my free time.

Yeah me too, i was ... suprised, but i've come to accept that
others naturaly have the same ideas, and might be faster and
better implementing them.
The "official" work is finished 1. october, and the only procedings
i could think of would be to make GDBE. Else i'll do something else
in other parts of the kernel. But... somehow i doubt that it could
work mixing non-students work into the project, it would be a mess.
No, you go ahead and make a GDBE target. 

Of course i'll bug test it, and run it, but thats only because i like
strong blocklevel encryption.

I have some ideas of building encryption into the filesystem, and even
allowing sharing of encrypted files. I think that experimental work is
much better suited for study projects, it's not like we managed to
complete a useable target in 2 months, and we were 2 people.




JonB