The Ext3sj Filesystem

The Ext3sj Filesystem

[Matthew J. Fanto]

I am annoucing the development of the ext3sj filesystem. Ext3sj is a new 
encrypted filesystem based off ext3. Ext3sj is an improvement over the 
current loopback solution because we do not in fact require a loopback 
device. Encryption/decryption is transparent to the user, so the only thing 
they will need to know is their key, and how to mount a device. We do not 
encrypt the entire volume under the same key as some solutions do (this can 
not only aid in a known-plaintext attack, but it gives the users less 
options). Instead, every file is encrypted seperately under the key of the 
users choice. We are also adding support for reading keys off floppies, 
cdroms, and USB keychain drives. Currently, ext3sj supports the following 
algorithms: AES, 3DES, Twofish, Serpent, RC6, RC5, RC2, Blowfish, CAST-256, 
XTea, Safer+, SHA1, SHA256, SHA384, SHA512, MD5, with more to come. 
If anyone has any comments, questions, or would like to request an algorithm 
be added, please let me know. 

-Matthew J. Fanto

Re: The Ext3sj Filesystem

[Andreas Dilger]

On Oct 30, 2002  14:34 -0500, Matthew J. Fanto wrote:
> I am annoucing the development of the ext3sj filesystem. Ext3sj is a new 
> encrypted filesystem based off ext3. Ext3sj is an improvement over the 
> current loopback solution because we do not in fact require a loopback 
> device. Encryption/decryption is transparent to the user, so the only thing 
> they will need to know is their key, and how to mount a device. We do not 
> encrypt the entire volume under the same key as some solutions do (this can 
> not only aid in a known-plaintext attack, but it gives the users less 
> options). Instead, every file is encrypted seperately under the key of the 
> users choice. We are also adding support for reading keys off floppies, 
> cdroms, and USB keychain drives. Currently, ext3sj supports the following 
> algorithms: AES, 3DES, Twofish, Serpent, RC6, RC5, RC2, Blowfish, CAST-256, 
> XTea, Safer+, SHA1, SHA256, SHA384, SHA512, MD5, with more to come. 
> If anyone has any comments, questions, or would like to request an algorithm 
> be added, please let me know. 

Some notes:
1) having so many encryption algorithms is a huge pain in the ass, and
   it will never be accepted into the kernel like that.  Pick some
   "good" encryption algorithms (like those that will be supported as
   part of IPSec and/or the encrypted loop devices: 3DES, AES, RC5 or
   whatever) and then there can be some re-use with other parts of the kernel.
2) "not requiring a loopback device" is in itself only a marginal
   benefit at best
3) It would probably be beneficial to add this as part of the ext2compr
   code, since it already handles per-file munging, and it is very common to
   do compression as a pre-processing step to encryption to reduce the
   redundancy in the input data

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Re: The Ext3sj Filesystem

[Rik van Riel]

On Wed, 30 Oct 2002, Matthew J. Fanto wrote:

> I am annoucing the development of the ext3sj filesystem. Ext3sj is a new
> encrypted filesystem based off ext3. Ext3sj is an improvement over the
> current loopback solution because we do not in fact require a loopback
> device.  [snip]  Instead, every file is encrypted seperately

Very nice, for exactly the reasons you outlined ;)

> Currently, ext3sj supports the following algorithms: AES, 3DES, Twofish,
> Serpent, RC6, RC5, RC2, Blowfish, CAST-256, XTea, Safer+, SHA1, SHA256,
> SHA384, SHA512, MD5, with more to come.  If anyone has any comments,

How about using the algorithms that are already in the kernel
via the crypto API so all of the kernel can share the same
crypto algorithms ?

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://distro.conectiva.com/
Current spamtrap:  <a href=mailto:"october@surriel.com">october@surriel.com</a>

Re: The Ext3sj Filesystem

[Lars Marowsky-Bree]

On 2002-10-30T14:34:17,
   "Matthew J. Fanto" <mattf@mattjf.com> said:

> Encryption/decryption is transparent to the user, so the only thing 
> they will need to know is their key, and how to mount a device. We do not 
> encrypt the entire volume under the same key as some solutions do (this can 
> not only aid in a known-plaintext attack, but it gives the users less 
> options). Instead, every file is encrypted seperately under the key of the 
> users choice.

Do you encrypt before the data has hit the data journal or after? Does that
work for mmap etc?

> We are also adding support for reading keys off floppies, 
> cdroms, and USB keychain drives. Currently, ext3sj supports the following 
> algorithms: AES, 3DES, Twofish, Serpent, RC6, RC5, RC2, Blowfish, CAST-256, 
> XTea, Safer+, SHA1, SHA256, SHA384, SHA512, MD5, with more to come. 

This sounds like something you might want to abstract into a generic
architecture to be shared with the loop device code, or anything which might
need encryption in the kernel. Otherwise it is a PITA to maintain.

And I thought some of those algorithms were strictly signature / hash
algorithms, but you never stop learning ;-)


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
Principal Squirrel 
SuSE Labs - Research & Development, SuSE Linux AG
  
"If anything can go wrong, it will." "Chance favors the prepared (mind)."
  -- Capt. Edward A. Murphy            -- Louis Pasteur

Re: The Ext3sj Filesystem

[Matthew J. Fanto]

On Wednesday 30 October 2002 03:56 pm, Lars Marowsky-Bree wrote:

> Do you encrypt before the data has hit the data journal or after? Does that
> work for mmap etc?

I have not finished journaling support yet, but it will encrypt before it hits 
the journal. Yes, there should be no problem with mmap.

>
> This sounds like something you might want to abstract into a generic
> architecture to be shared with the loop device code, or anything which
> might need encryption in the kernel. Otherwise it is a PITA to maintain.

I will be going over the cryptoAPI code tonight and seeing if I can change the 
crypto routines to use the cryptoAPI, as it would be much easier to maintain. 

> And I thought some of those algorithms were strictly signature / hash
> algorithms, but you never stop learning ;-)

The SHA algorithms, as well as MD5 are used for message digests (hashing). 
This is used to transform the key prior to passing the key off to the 
specific algorithms key setup functions. I have also thought about, albeit 
not too much, about using message digests/signatures as a file integreity 
mechanism. 

I should also mention that deletion of files on ext3sj will use DoD standards 
for secure file deletion by overwriting the data with all 0's, all 1's, and 
then random data. So, before you delete a file, make sure you really want to 
delete it, because there won't be a way to recover it. 

-Matthew J. Fanto

Re: The Ext3sj Filesystem

[Matthew J. Fanto]

On Wednesday 30 October 2002 03:00 pm, Andreas Dilger wrote:

> 1) having so many encryption algorithms is a huge pain in the ass, and
>    it will never be accepted into the kernel like that.  Pick some
>    "good" encryption algorithms (like those that will be supported as
>    part of IPSec and/or the encrypted loop devices: 3DES, AES, RC5 or
>    whatever) and then there can be some re-use with other parts of the
> kernel. 

I don't believe having so many algorithms is such a pain. It gives users more 
choices. I've spoke to people who will not trust AES, 3DES, SHA, and even 
the AES finalists because they believe NIST/NSA only picked weak algorithms. 
Obviously there will be a default algorithm (probably AES and SHA1), so I 
don't think having more algorithms will cause users problems. Only problem I 
see is maintaining all of them.

-Matthew J. Fanto

Re: The Ext3sj Filesystem

[Bill Davidsen]

On Wed, 30 Oct 2002, Matthew J. Fanto wrote:

> 
> I am annoucing the development of the ext3sj filesystem. Ext3sj is a new 
> encrypted filesystem based off ext3. Ext3sj is an improvement over the 
> current loopback solution because we do not in fact require a loopback 
> device. Encryption/decryption is transparent to the user, so the only thing 
> they will need to know is their key, and how to mount a device. We do not 
> encrypt the entire volume under the same key as some solutions do (this can 
> not only aid in a known-plaintext attack, but it gives the users less 
> options). Instead, every file is encrypted seperately under the key of the 
> users choice. We are also adding support for reading keys off floppies, 
> cdroms, and USB keychain drives. Currently, ext3sj supports the following 
> algorithms: AES, 3DES, Twofish, Serpent, RC6, RC5, RC2, Blowfish, CAST-256, 
> XTea, Safer+, SHA1, SHA256, SHA384, SHA512, MD5, with more to come. 
> If anyone has any comments, questions, or would like to request an algorithm 
> be added, please let me know. 

Is this just an announcement of an interesting idea, or does the code
exist? I looked at www.mattjf.com found a buch of "not on this server"
links, and a bunch of useful doc files, but no mention of extsj.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: The Ext3sj Filesystem

[Matthew J. Fanto]

On Wednesday 30 October 2002 04:34 pm, Bill Davidsen wrote:

>
> Is this just an announcement of an interesting idea, or does the code
> exist? I looked at www.mattjf.com found a buch of "not on this server"
> links, and a bunch of useful doc files, but no mention of extsj.

The code does exist, but not in stable form yet. I thought with the recent 
announcement of the cryptoapi merge, I would annouce ext3sj and get peoples 
opinions/suggestions.

-Matthew J. Fanto

Re: The Ext3sj Filesystem

[Henning P. Schmiedehausen]

"Matthew J. Fanto" <mattf@mattjf.com> writes:

>choices. I've spoke to people who will not trust AES, 3DES, SHA, and even 
>the AES finalists because they believe NIST/NSA only picked weak algorithms. 

Huh, so they pick, other, less tested and verified algorithms than the ones
that have been thoroughly investigated by the crypto community? What a 
concept. Please tell these people to "keep away from my data". :-)
	
	Regards
		Henning
-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: The Ext3sj Filesystem

[Nicholas Wourms]

Rik van Riel wrote:

> On Wed, 30 Oct 2002, Matthew J. Fanto wrote:
> 
>> I am annoucing the development of the ext3sj filesystem. Ext3sj is a new
>> encrypted filesystem based off ext3. Ext3sj is an improvement over the
>> current loopback solution because we do not in fact require a loopback
>> device.  [snip]  Instead, every file is encrypted seperately
> 
> Very nice, for exactly the reasons you outlined ;)
> 
>> Currently, ext3sj supports the following algorithms: AES, 3DES, Twofish,
>> Serpent, RC6, RC5, RC2, Blowfish, CAST-256, XTea, Safer+, SHA1, SHA256,
>> SHA384, SHA512, MD5, with more to come.  If anyone has any comments,
> 
> How about using the algorithms that are already in the kernel
> via the crypto API so all of the kernel can share the same
> crypto algorithms ?

I agree, as this seems like the logical approach.  However, why not just add 
the missing algorithms in the list above to the CryptoAPI while your at it?  
That way, we really give users a choice over which algorithm they prefer to 
use, but also maintaining a centralized API for them.

Cheers,
Nicholas

Re: The Ext3sj Filesystem

[Bill Davidsen]

On Wed, 30 Oct 2002, Andreas Dilger wrote:

> Some notes:
> 1) having so many encryption algorithms is a huge pain in the ass, and
>    it will never be accepted into the kernel like that.  Pick some
>    "good" encryption algorithms (like those that will be supported as
>    part of IPSec and/or the encrypted loop devices: 3DES, AES, RC5 or
>    whatever) and then there can be some re-use with other parts of the kernel.

You are more trusting than I that these things can't be broken or in the
case of AES were not selected because they could. Your point is good, but
I think the way to do it is to define a crypto module API, such that user
could drop in his/her own, be it custom, something which pops up in a
year, or whatever.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: The Ext3sj Filesystem

[Theodore Ts'o]

On Wed, Oct 30, 2002 at 02:34:17PM -0500, Matthew J. Fanto wrote:
> 
> I am annoucing the development of the ext3sj filesystem. Ext3sj is a
> new encrypted filesystem based off ext3. Ext3sj is an improvement
> over the current loopback solution because we do not in fact require
> a loopback device. Encryption/decryption is transparent to the user,
> so the only thing they will need to know is their key, and how to
> mount a device.

Couple of points here.   

First of all, have you considered trying to do this as a stacking
filesystem?  Talk to the Intermezzo and Luster folks; they've gotten
quite good at stacking their value-added filesystem on top ext2/3.
This avoids code duplication, since now you don't have to track bug
fixes in the core ext2/3 code.  It also enforces functional
separation, and should your filesystem smaller and easier to maintain.
It also means that you can potentially use your code to provide crypto
services to other filesystems besides just ext3.

Secondly, the really critical question is key management.  What
happens if the user gets the key wrong?  Will he/she know?  Or will
they just get garbage if the read from the file, and be able to trash
the file if they write to the file with the incorrect key?  Using some
kind of key-ID and some way of validating that the key is correct
before the user does start accessing files would probably be a really
good idea.

Finally, if you do want to allocate some additional fields in the ext2
inode, superblock, etc., please coordinate with me, so we can avoid
conflicts as much as possible.  Thanks!!

					- Ted

Re: The Ext3sj Filesystem

[Matthew J. Fanto]

On Thursday 31 October 2002 11:41 pm, Theodore Ts'o wrote:

> First of all, have you considered trying to do this as a stacking
> filesystem?  

Yes, I spoke to Christoph Hellwig the other day and he suggested the same 
thing. I will be taking a look at a stacking filesystem tonight/tomorrow. 

> Secondly, the really critical question is key management.  What
> happens if the user gets the key wrong?  Will he/she know?  Or will
> they just get garbage if the read from the file, and be able to trash
> the file if they write to the file with the incorrect key?  Using some
> kind of key-ID and some way of validating that the key is correct
> before the user does start accessing files would probably be a really
> good idea.

It wouldn't be very hard to alert the user of an incorrect key using a message 
digest (SHA1). So far, I haven't implemented this feature, but I will if 
enough people want it.

> Finally, if you do want to allocate some additional fields in the ext2
> inode, superblock, etc., please coordinate with me, so we can avoid
> conflicts as much as possible.  Thanks!!

Yes, there will be a need for additional fields specifying things such as the 
algorithm to use.