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
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 [email protected]
> 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
>
> Hello,
ftp://http://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
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 (http://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/
[email protected] ("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
On Sat, Apr 21, 2001 at 09:21:44PM +0200, Peter Makholm wrote:
> [email protected] ("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
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.
On Sat, 21 Apr 2001, Andi Kleen wrote:
> On Sat, Apr 21, 2001 at 09:21:44PM +0200, Peter Makholm wrote:
> > [email protected] ("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 [email protected] for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142
On Sat, 21 Apr 2001, Andi Kleen wrote:
> On Sat, Apr 21, 2001 at 09:21:44PM +0200, Peter Makholm wrote:
> > [email protected] ("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
On 21 Apr 2001, Peter Makholm wrote:
> [email protected] ("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
> 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 (http://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.
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
------------------------------------------------------
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 [email protected]
"Described as awesome by users"
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
------------------------------------------------------