Idea: Encryption plugin architecture for file-systems

Idea: Encryption plugin architecture for file-systems

[Tamas Nagy]

Hello,

Lot of people would like to know their data in secure place, and the
frequent usage of compression softwares could be time-consuming and boring
sometime.

Idea:
extend the current file-system with an optional plug-in system, which allows
for file-system level encryption instead of file-level. This could be used
transparently for applications or even for file-system drivers.  This
doesn't mean an encrypted file-system, but a transparent encryption of a
media instead.

Advantages:
#1: optional security level for every data, without user interaction.
#2: if this idea is used e.g. for portable media (like cdrom), your backup
could be in safe also.
#3: (almost;)) everybody could create own security plugin for their data,
and not have to trust on the designers of a secure file systems.

I suspect that this idea may appeared in the past:(, but I haven't heard
about it;).

So, what do you think about this? Is Linux kernel enough flexible to do
this? What changes are necessary to do such a thing? Is there any other way,
to have own security for file-systems or portable medias? Is this
implementation could be used in the US?

Best regards,
Tamas Nagy

Re: Idea: Encryption plugin architecture for file-systems

[Ian Stirling]

> 
> Hello,
ftp://www.kerneli.org/pub/linux/kerneli/

For idea encryption, you just use
losetup -e idea /dev/loop0 /filesystem
Password: whatever

mke2fs /dev/loop0 
mount /dev/loop0

Re: Idea: Encryption plugin architecture for file-systems

[Alistair Riddell]

Have you tried:

man losetup

losetup /dev/loop0 /dev/hdxx -e DES
mke2fs /dev/loop0
mount /dev/loop0 /mnt/


On Sat, 21 Apr 2001, Tamas Nagy wrote:

> Hello,
> 
> Lot of people would like to know their data in secure place, and the
> frequent usage of compression softwares could be time-consuming and boring
> sometime.
> 
> Idea:
> extend the current file-system with an optional plug-in system, which allows
> for file-system level encryption instead of file-level. This could be used
> transparently for applications or even for file-system drivers.  This
> doesn't mean an encrypted file-system, but a transparent encryption of a
> media instead.
> 
> Advantages:
> #1: optional security level for every data, without user interaction.
> #2: if this idea is used e.g. for portable media (like cdrom), your backup
> could be in safe also.
> #3: (almost;)) everybody could create own security plugin for their data,
> and not have to trust on the designers of a secure file systems.
> 
> I suspect that this idea may appeared in the past:(, but I haven't heard
> about it;).
> 
> So, what do you think about this? Is Linux kernel enough flexible to do
> this? What changes are necessary to do such a thing? Is there any other way,
> to have own security for file-systems or portable medias? Is this
> implementation could be used in the US?
> 
> Best regards,
> Tamas Nagy
> 
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
Alistair Riddell - BOFH
IT Support Department, George Watson's College, Edinburgh
Tel: +44 131 447 7931 Ext 176       Fax: +44 131 452 8594
Microsoft - because god hates us

Re: Idea: Encryption plugin architecture for file-systems

[Bart Trojanowski]

On Sat, 21 Apr 2001, Tamas Nagy wrote:

> extend the current file-system with an optional plug-in system, which allows
> for file-system level encryption instead of file-level. This could be used
> transparently for applications or even for file-system drivers.  This
> doesn't mean an encrypted file-system, but a transparent encryption of a
> media instead.

Tamas,
  you may want to read this:

    http://encryptionhowto.sourceforge.net/Encryption-HOWTO-4.html

  the international kernel patch (www.kerneli.org) has had this
implemented for some time.  There is lot more info on crypto in Linux at:

  http://encryptionhowto.sourceforge.net/

> Advantages:
> #1: optional security level for every data, without user interaction.
> #2: if this idea is used e.g. for portable media (like cdrom), your backup
> could be in safe also.
> #3: (almost;)) everybody could create own security plugin for their data,
> and not have to trust on the designers of a secure file systems.

I don't think it's that involved but you can certainly apply a cipher to a
mounted partition.

> So, what do you think about this? Is Linux kernel enough flexible to do
> this? What changes are necessary to do such a thing? Is there any other way,
> to have own security for file-systems or portable medias? Is this
> implementation could be used in the US?

You can use it in the states but you cannot develop for it within the
states - well, the regulations changes but I am not sure if the kerneli
guys will trust that... that's a totally different debate in itself.

Bart.

-- 
	WebSig: http://www.jukie.net/~bart/sig/

Re: Idea: Encryption plugin architecture for file-systems

[Peter Makholm]

nagytam@rerecognition.com ("Tamas Nagy") writes:

> Idea:
> extend the current file-system with an optional plug-in system, which allows
> for file-system level encryption instead of file-level.

That's is one of the things the loop device offers. For better
encryption than XOR you need the patches from kerneli.org.

(Remember the problems whith crypto code in the US is mainly with
exporting it neither importing or using it.)

-- 
hash-bang-slash-bin-slash-bash

Re: Idea: Encryption plugin architecture for file-systems

[Andi Kleen]

On Sat, Apr 21, 2001 at 09:21:44PM +0200, Peter Makholm wrote:
> nagytam@rerecognition.com ("Tamas Nagy") writes:
> 
> > Idea:
> > extend the current file-system with an optional plug-in system, which allows
> > for file-system level encryption instead of file-level.
> 
> That's is one of the things the loop device offers. For better
> encryption than XOR you need the patches from kerneli.org.

No, you don't. The standard kernel loop device supports loading of external 
crypto filters just fine; no patching at all required.


-Andi

Re: Idea: Encryption plugin architecture for file-systems

[Herbert Valerio Riedel]

On Sat, 21 Apr 2001, Andi Kleen wrote:
> On Sat, Apr 21, 2001 at 09:21:44PM +0200, Peter Makholm wrote:
> > nagytam@rerecognition.com ("Tamas Nagy") writes:
> > > Idea:
> > > extend the current file-system with an optional plug-in system, which allows
> > > for file-system level encryption instead of file-level.
> >
> > That's is one of the things the loop device offers. For better
> > encryption than XOR you need the patches from kerneli.org.
> No, you don't. The standard kernel loop device supports loading of external
> crypto filters just fine; no patching at all required.

you're right, by using...

int loop_register_transfer(struct loop_func_table *funcs);
int loop_unregister_transfer(int number);

...one can register new transfer functions, but they rely on 'magic
numbers' for identifying the given crypto cipher, some of which are
defined in linux/loop.h; with the highest magic number being MAX_LO_CRYPT
(so patching is required nevertheless, if you want to have more than 20
ciphers by that scheme...)

#define LO_CRYPT_NONE     0
#define LO_CRYPT_XOR      1
#define LO_CRYPT_DES      2
#define LO_CRYPT_FISH2    3    /* Brand new Twofish encryption */
#define LO_CRYPT_BLOW     4
#define LO_CRYPT_CAST128  5
#define LO_CRYPT_IDEA     6
#define LO_CRYPT_DUMMY    9
#define LO_CRYPT_SKIPJACK 10
#define MAX_LO_CRYPT    20

well.... the only thing I don't really like about this is, that its a
static allocation of cipher id's, instead of a dynamic lookup by name
and I'm not sure how well module autoloading works by this scheme...
(the international crypto api offers string lookup for ciphers, and
registers itself as one of those numeric cipher ids as far as loop
device usage is concerned)

btw, there's still an issue with with the IV value being calculated on
varying blocksizes, which I pointed out some time ago (instead of being
calculated on 512 byte sectors, which I assume to be the smallest possible
blocksize settable on a device)

greetings,
-- 
Herbert Valerio Riedel      /     Finger hvr@gnu.org for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F 4142

Re: Idea: Encryption plugin architecture for file-systems

[Dan Hollis]

On Sat, 21 Apr 2001, Andi Kleen wrote:
> On Sat, Apr 21, 2001 at 09:21:44PM +0200, Peter Makholm wrote:
> > nagytam@rerecognition.com ("Tamas Nagy") writes:
> > > Idea:
> > > extend the current file-system with an optional plug-in system, which allows
> > > for file-system level encryption instead of file-level.
> > That's is one of the things the loop device offers. For better
> > encryption than XOR you need the patches from kerneli.org.
> No, you don't. The standard kernel loop device supports loading of external
> crypto filters just fine; no patching at all required.

But it is a definite performance killer. A direct plugin to filesystems
would be far more efficient.

-Dan

Re: Idea: Encryption plugin architecture for file-systems

[Dan Hollis]

On 21 Apr 2001, Peter Makholm wrote:
> nagytam@rerecognition.com ("Tamas Nagy") writes:
> > Idea:
> > extend the current file-system with an optional plug-in system, which allows
> > for file-system level encryption instead of file-level.
> That's is one of the things the loop device offers. For better
> encryption than XOR you need the patches from kerneli.org.

I think he wants to avoid the *!!SEVERE!!* performance problems in
loopback crypto. A crypto plugin directly to filesystems would certainly
avoid most of it.

-Dan

Re: Idea: Encryption plugin architecture for file-systems

[Olaf Titz]

> I think he wants to avoid the *!!SEVERE!!* performance problems in
> loopback crypto. A crypto plugin directly to filesystems would certainly
> avoid most of it.

I'm currently in the situation where I need to mount an encrypted file
system over NFS (on a slow link), and the performance considerations
pretty much rule out the loop approach. (Currently I'm using CFS
because I found no other choice[1], but it is another loop approach -
stacking one NFS on top of another NFS - and that makes it painfully
slow too.)

The theoretically best solution is TCFS (www.tcfs.it), which builds
encryption into the NFS client alone, but it is not available for
anything newer than Linux 2.2.16.

Olaf

[1] Esp. if the requirement is that it can survive a kernel upgrade.

Re: Idea: Encryption plugin architecture for file-systems

[Stefan Jaschke]

On Saturday 21 April 2001 20:52, Tamas Nagy wrote:
> extend the current file-system with an optional plug-in system, which
> allows for file-system level encryption instead of file-level. This could
> be used transparently for applications or even for file-system drivers. 
> This doesn't mean an encrypted file-system, but a transparent encryption of
> a media instead.
> I suspect that this idea may appeared in the past:(, but I haven't heard
> about it;).
Not sure what you have in mind exactly, but there are related
projects:
 - the crypto modules in the international linux kernel
   (see http://encryptionhowto.sourceforge.net/Encryption-HOWTO.html)
 - Erik Zadok's FIST (http://www.cs.columbia.edu/~ezk/research/fist/)
 - the Transparent Cryptographic File System (http://www.tcfs.it/)
 - Stefan Ludwig's Fairly Secure File System 
  (http://osg.informatik.tu-chemnitz.de/publikat/da/00/Ludwig00.pdf,
   diploma thesis, in German)
 - Allan Latham's practical privacy disc (device) driver
   (http://linux01.gwdg.de/~alatham/ppdd.html)
 - Matt Blaze's CFS seems to be discontinued/unsupported
   (http://koeln.ccc.de/~drt/crypto/cfs-linux-HOWTO.txt)
Maybe you clarify what exactly you want to achieve/improve compared
to the existing projects.

Stefan J.

Re: Idea: Encryption plugin architecture for file-systems

[Dale Amon]

Talk about syncronicity... I had just last week asked
about the pro's and con's on this on the crypto list and
have heard nothing at all back. So I'll drop the body
of that message in here:

--
I've got a crypto loopback running directly on a /dev/md0
partition and then the file system on top of that. I'm
interested in what the feelings of others are on the
trade offs of doing it this way.

Is there something to be gained by adding a file system
layer between the /dev/md0 and the loopback file as far
as error recovery is concerned?

Do I actually gain performance (as I am guessing currently
that I do) by eliminating one layer?

It's just a plaything right now, but I'd be interested
in some feedback on the wisdom of it before I actually
use this on something important. So just to reiterated:

                               fs
          fs                c. loopback
        c. loopback  vs        fs
         raid1                raid1
        disk disk           disk disk

where fs = ext2 until this evening when I replace it
with reiserfs.
--

And update by saying I've got reiserfs working on top
of it with no problems. But I'm still just that wee
bit nervous about the approach even though it works.

What happens if I get one bad disk sector in a partition?
What is the difference in data loss between encrypting
on the bare partition versus having say, a reiserfs
under you?

(Obviously RAID doesn't save you. It will just merrily
reproduce the bad sector on the mirror disk)

-- 
------------------------------------------------------
Use Linux: A computer        Dale Amon, CEO/MD
is a terrible thing          Village Networking Ltd
to waste.                    Belfast, Northern Ireland
------------------------------------------------------

Re: Idea: Encryption plugin architecture for file-systems

[David L. Nicol]

Dale Amon wrote:
> 
> Talk about syncronicity... I had just last week asked
> about the pro's and con's on this on the crypto list and
> have heard nothing at all back. So I'll drop the body
> of that message in here:


why not port one of the twenty or thirty preexisting tools
that let you mount a filesystem from an encrypted file instead
of making a generic layer?  That way you could have inter-os 
portability.  The steganographic ones make really impressive
claims.  

Does linux have a truly generic plug-in file system module yet,
or are people still hacking around fake nfs servers? 




-- 
                      David Nicol 816.235.1187 dnicol@cstp.umkc.edu
                                    "Described as awesome by users"

Re: Idea: Encryption plugin architecture for file-systems

[Dale Amon]

On Mon, Apr 23, 2001 at 09:54:34PM -0500, David L. Nicol wrote:
> why not port one of the twenty or thirty preexisting tools
> that let you mount a filesystem from an encrypted file instead
> of making a generic layer?  That way you could have inter-os 
> portability.  The steganographic ones make really impressive
> claims.  

I'm doing an 18GB raid file system. The standard loopback is
working fine. What I am unsure of is the bobustness against lost
blocks when running "on the metal" vs interposing another file
system layer.

I suspect the answer is that each block is individually encrypted,
so that the worst case data loss is the same; that an ext2 on
top of an encrypted partition would be no worse off than the 
same file system without the interposed layer. Both would find
a bad block and do their best.

But my knowledge of how the loopbacks are structured is not
good enough for me to say this with confidence. That's why 
I'm asking here: in hopes that someone who really does know
can say something about the worst case data loses.

-- 
------------------------------------------------------
Use Linux: A computer        Dale Amon, CEO/MD
is a terrible thing          Village Networking Ltd
to waste.                    Belfast, Northern Ireland
------------------------------------------------------