[cgl_discussion] about PoC of "Support for encrypted file systems"

Fleischer, Julie N julie.n.fleischer at intel.com
Wed Jun 18 08:40:50 PDT 2003


Forrest -
Thanks for this useful information!  I've added it to the spreadsheet as noted below.

> From: Zhao, Forrest 
> I have some update for PoC of "Support for encrypted file systems"
>  
> 1 Loop-AES :
> After adding the utility patch, Loop-AES can support many 
> more ciphers, such as Twofish, serpent, MARS, RC6, DFC, 
> Blowfish, IDEA, 3DES, RC5. It can encrypt a whole partition, 
> root fs or use a file as encrypted file system

Added this information to the spreadsheet and stated that Loop-AES plus utility patch does implement the full requirement.

> 2 ReiserFS: 
>      Reiserfs (version 3) doesn't support neither compression 
> nor encryption. It is supposed to be implemented in reiser4 
> for individual files (and maybe directories). Perhaps      
> we'll develop a scenario when file system looks for a secret 
> key in the key token of the process, inherited from its parent.   
>      The above paragraph is from the maillist of reiserfs, so 
> I don't think ReiserFS is suited for our requirement. It can 
> just encrypt individual files can not encrypt the partition. 
> What's your opinion?

My interpretation of the requirement is that if all files in a file system could be encrypted, this is satisfied.  Made a note on the spreadsheet that ReiserFS encrypts at the file level.

> 3 StegFS
> The information hiding comes at a price. To ensure the 
> security StegFS has to allow data in the file system to be 
> accidently overwritten. To
> avoid losing files StegFS, therefore, writes several copies 
> of each file block and inode so that, if some are 
> overwritten, others can hopefully be recovered. This 
> replication obviously requires more disk space for a given 
> file. There is also a performance penalty due to the need to 
> write several copies of everything. There is also the risk 
> that all copies of a given block will be overwritten, in 
> which case its contents are lost.
>      The above paragraph is from StegFS FAQ, so I think the 
> performance penalty is a big problem for its application in CGL.

I'll note that there are performance and space limitations in the gap analysis.
 
> In summary, I believe that ReiserFS and StegFS don't cater to 
> the CGL requirement and should be erased for PoC. Loop-AES is 
> a good candidate.
>  
> Any comments?
>  
> Forrest
>  
> **These views are not necessarily those of my employer.**

**These views are not necessarily those of my employer.**




More information about the cgl_discussion mailing list