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
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/
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:"[email protected]">[email protected]</a>
On 2002-10-30T14:34:17,
"Matthew J. Fanto" <[email protected]> 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 <[email protected]>
--
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
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 http://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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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
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
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 http://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
"Matthew J. Fanto" <[email protected]> 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 [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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
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.