Re: Proposal for keying encrypted filesystem

[Edward Shushkin <edward@namesys.com>]

Hendrik Visage wrote:
> 
> On Mon, Mar 31, 2003 at 05:58:04PM +0400, Edward Shushkin wrote:
> > I didn't invent something new..
> > I don't understand what should withstand scrutiny from crypto gurus.. md5? SHA?
> 
> The keying implementation as proposed.

I agree, but keying implementation is not ready, just in discussion process, so there is 
nothing that should withstand scrutiny for a while.. I want to clear up some order in 
addition to the design document I have posted.
  First we would like to specify the minimal crypto interface that kernel should know about.
Our policy is that it should be exactly *minimal*, so kernel shouldn't worry about key
management. When user tries to open a crypto file by special reiser4_open() system call,
kernel calls appropriate method which checks if the key passed by user is valid. I have 
described the identification mechanism earlier, it uses disk key ID calculated by share or
private key during creation (when kernel creates, or opens a crypto file, it doesn't need to
distinguish, if the key is share or private). With a big probability (which is provided by
using of crypto-stable hash function) kernel makes a right conclusion if the key is valid or
invalid. If passed key is valid, kernel load this key into its own memory, and installs the
pointer to the inode. It means that user has got an access to this file i.e. he can read and
write file's data using this key. At the end of session reiser4_close() method zeroes and frees
the memory allocated for the key. All read(), write() internals I have described earlier. 
 There is an opinion that is *all* what kernel should know about crypto-files. Although one
more thing that kernel also should do (in order to support public-private interface) is
distinguish what key should be used for reading, and what one should be used for writing.
The current list of parameters which should be passed to the kernel via reiser4_open syscall
(including compression info) is:

crypto_id crypto;            / id of the reiser4 crypto-plugin /
crypto_hash_id hash;         / id of the reiser4 crypto-hash plugin /
compression_id compression;  / id of the reiser4 compression plugin /
__u8 *pr_key;                / pointer to the private(share) key /
__u16 pr_key_size;           / private(share) key size /
__u8 *pub_key;               / pointer to the public key /
__u16 pub_key_size;          / public key size /
__u8 *keyid_string;          / pointer to the identification string (secret string randomly
                               generated by appropriate key generation routine) /
__u8  keyid_length ;         / the length of identification string /
__u8  cluster_shift;         / cluster parameter /

Key ID size is defined by crypto-hash plugin (it is just an output size of appropriate hash
function). All other needed information is contained in specified crypto-plugin (if used
crypto-algorithm is symmetric or asymmetric, how to install keys to the inode, etc..)
So we would like to see the following:
   
1) Any opinions whether this crypto-file interface is full enough to implement public-private
keing (or maybe I have missed something that will be needed for some useful features), etc..

2) Any remarks about possible security holes in the reiser4 internals of main system calls I
have described. I don't think this is the only crypto guru who can do this.

3) Any proposals about crypto-directory plugin implementation. Obviously, encryption of directory
entries (which is so desirable by everyone) should be implemented as a new directory plugin. 
This is the main directory plugin methods (->create_child() and ->lookup() responsible for 
new entry creation and name resolution) who will call crypto-plugin (I hope we don't need
to compress file names). Perhaps, it is possible to implement the scheme when all directory entries
and appropriate files are encrypted by the same key which is loaded once for all these files, and
the appropriate key ID is verified once and saved once in directory disk stat-data instead of 
its saving in disk stat-data of each file.

4) Proposals about integrating with a PKI infrastructure.

5) Proposals about user level support.

As I understand, currently we need 1), 2) and 5). Other will be need in future.	
Anyway thanks for all your posts, although some of them I can not comment since the topic is beyond
the scope of DARPA contract.

Edward.