The Ext3sj Filesystem
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
Quoted 6 lines · 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
Quoted 8 lines
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/
Quoted 6 lines · Andreas Dilger
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
Quoted 2 lines · Matthew J. Fanto
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
Signature · 5 lines
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
Quoted 6 lines · Andreas Dilger
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.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 4 lines · 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. [snip] Instead, every file is encrypted seperately
Very nice, for exactly the reasons you outlined ;)
Quoted 3 lines
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
Signature · 3 lines
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>
Quoted 9 lines · Rik van Riel
Quoted 4 lines · 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. [snip] Instead, every file is encrypted seperately
Very nice, for exactly the reasons you outlined ;)
Quoted 7 lines
Quoted 3 lines
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
Quoted 6 lines · Matthew J. Fanto
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?
Quoted 4 lines
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]>
Signature · 5 lines
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
Quoted 2 lines · Lars Marowsky-Bree
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.
Quoted 4 lines
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.
Quoted 2 lines
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
Quoted 15 lines · 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.
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.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 4 lines · Bill Davidsen
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
Quoted 7 lines · 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.
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
Quoted 2 lines · Theodore Ts'o
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.
Quoted 7 lines
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.
Quoted 3 lines
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.