Basic interface for key management in reiser4 (DRAFT)

Basic interface for key management in reiser4 (DRAFT)

[Edward Shishkin]

  Hello everyone.

  Here is a description of a simple optional interface to import and 
propagate
cipher keys. This interface will be available via compile-time option
ENABLE_COMMON_CRYPTO_STAT which adds some fields to in-memory structures 
reiser4
superblock and reiser4-specific part of inode.
  The common idea is to make possible to attach a key to any object 
(directory,
regular file, etc..) that is supposed to work with (there is a special 
pointer
in reiser4-specific part of inode when this option is on), and propagate 
it down
(root is up) through the semantic tree via its inheriting from parent 
objects).
In spite of its simplicity there can be various obscured issues, so all 
comments
are welcome.

NOTE: This interface is over linux crypto-api.

  I should remind that encryption and compression in reiser4 are 
performed in
flush time for a special kind of reiser4 regular files (cryptcompress 
files).
Currently only directories and cryptcompress regular files interact with
cipher keys.


                        I. Object cipher keyid


  Each regular cryptcompress file should have a keyid (32-bit or greater 
word)
which is created by reiser4 digest plugin and supposed to be stored in disk
stat-data. The keyid exists because of 2 reasons:
1. It is used for key identification: even if cipher key is not loaded, user
   can check the object keyid (for example by using a pseudo-file 
interface) and
   use it to find an appropriate cipher key (which is located in mind or
   somewhere on removable area).
2. It is used to not allow users load wrong keys, because writing to a 
file with
   wrong key loaded leads to data corruption (it is harmfully not for the
   filesystem, but for user)

  Keyid is created by the pair "key-passphrase", where "key" is a string 
which
is required by cipher algorithm and participates in cipher transforms, and
"passphrase" is any private string. Both key and passphrase should be 
specified
by user). Keyid is created by the following steps:

1. encrypting the passphrase by the key;
2. creating a big digest of the result by stable hash function (sha256, 
etc..)
3. having first N bits of the big digest as resulted keyid.

Q: Is it safe to use only 32 bit for keyid?
A: Having a 32-keyid does not allow to reveal a cipher key as the big digest
   was created by safe operations. If you want to avoid collisions in key
   identification add a new digest plugin that will create a greater keyid.


                     II. Importing a cipher key


  First of all a cipher key should be imported to the kernel and uploaded to
some object. We will use to say that key is attached to the object A 
meaning this
initial importing and uploading to A.

  One of the possible ways to attach a cipher key to an object is to 
implement
it via a ->write() method of special new keyload pseudo file 
(PSEUDO_KEYLOAD_ID)
of this object. It means accepting and parsing a pair "key-passphrase", then
allocating and filling the following structure:

typedef struct crypto_stat {
       __u8 *keyid;          /* keyid */
         int keyid_size;     /* keyid size */
       ...
       __u32 *key;           /* cipher key wrapped by
                                struct crypto_tfm 
(include/linux/crypto.h) */
       ...
       int keyload_count;
} crypto_stat_t;


        III. Packing/extracting crypto stat-data of the object

  The crypto-stat of directory inode is not saved on disk.
When writing inode of (cryptcompress) regular file, keysize and keyid 
are saved
on disk in special reiser4 CRYPTO_STAT stat-data extension.
When reading inode of regular file the ->present() method of this stat-data
allocates and fills the crypto-stat, but without cipher key loaded 
(there are
only keysize and keyid). Such incomplete crypto-stat can be used only to
observe crypto-specific attributes of the file (for example by ->read() 
method
of its keyload pseudo-file).


                   IV. Propagating a cipher key


Some definitions:

To load a specified crypto-stat to the object means to keep a pointer to 
this
structure in reiser4-specific part of inode and increment a keyload_count.

To unload a crypto-stat of the object means to decrement keyload_count 
and free
the structure if this count became zero.

NOTE: All load/unload operations are protected by special per-superblock
semaphore.

Propagating a cipher key is going as inheriting the crypto-stat from 
parent to
child via special methods of reiser4 file plugin:

1. Inheriting during open()   is implemented via ->open();
2. Inheriting during create() is implemented via ->adjust_to_parent();
3. Inheriting during lookup() is implemented via ->bind().

  All those methods try to inherit crypto-stat from parent. If 
inheritance is
possible, the old crypto-stat of the object is unloaded (if any) and new one
is loaded. If the child is a directory, the inheritance is always possible.
If the child is a cryptcomperss file inheritance is possible only if 
this child
does not have a crypto-stat (file just created) or its keyid and other
attributes (except a cipher key) coincide with the attributes of parent
directory.
  So if you wanna open/create a file one should attach a key to any existing
member of its pathname. For example, in order to create 
"/mnt/mydir/myfile" one
may attach a key either to "/mnt", or to "/mnt/mydir". In the first case 
it is
possible that "/mnt/mydir" is in the cache already, so it is necessary 
also to
open it for carrying out the key. Key can be attached to existing
(cryptcompress) regular file if it does not have a cipher key loaded 
(also it
should have in its plugin_set non-trivial cipher transform plugin 
installed).


                    V. Eliminating a cipher key


Eliminating is possible only as a result of unloading a crypto-stat that 
is used
by nobody (keyload_count became zero). Eliminating can occur when
1. inheriting a crypto-stat (old crypto-stat is unloaded);
2. evicting from memory unused inode (its crypto stat is unloaded by
   ->destroy_inode() method of file plugin).


                  VI. Opening a cryptcompress file


plugin->open() tries to inherit a crypto-stat from parent, then 
evaluates the
expression (crypto_stat loaded => cipher key loaded). If it is not true, 
EINVAL
will be returned.


                 VII. An example of possible scenario (DRAFT):

#pwd
/mnt
#mkdir mydir
#echo -e "crc\0" > mydir/..../plugin/regular
#cat mydir/..../plugin/regular
1 cryptcompress Cryptcompress regular plugin
#cat mydir/..../plugin/compression
0 lzo1 lzo1 compression transform
#cat mydir/..../plugin/digest
1 sha256-32 sha256-32 digest transform
#cat mydir/..../plugin/crypto
0 none absence of crypto transform
#echo -e "blowfish\0" > mydir/..../plugin/crypto

#touch mydir/myfile
Unable to create file
#cat mydir/..../keyload
No key loaded

#echo -e "08e19c2d91bbc14f06af9ec61e68\0" > mydir/..../keyload
          ^^----------------^^^^^^^^^^
       keysize     key      passphrase

#cat mydir/..../keyload
keyid32: f56ef868
loaded 8-byte key for Blowfish cipher algo

#echo "Hello World" > mydir/myfile
#cd /
#umount /mnt
#mount /dev/hdb5 /mnt
#cat /mnt/mydir/myfile
Unable to open file
#cat /mnt/mydir/myfile/..../keyload
keyid32: f56ef868
No key loaded

#echo -e "08e19c2d91bbc14f06af9ec61e68\0" > /mnt/mydir/..../keyload
#cat /mnt/mydir/myfile
Hello World


                       VIII. Thats all


Thanks,
Edward.

Re: Basic interface for key management in reiser4 (DRAFT)

[Hans Reiser]

How much of this is implemented at this time?

Your english has improved a lot.

Edward Shishkin wrote:

>  Hello everyone.
>
>  Here is a description of a simple optional interface to import and
> propagate
> cipher keys. This interface will be available via 

a

> compile-time option
> ENABLE_COMMON_CRYPTO_STAT which adds some fields to 

some

> in-memory structures

: the

> reiser4
> superblock and 

the

> reiser4-specific part of

the

> inode.
>  The common idea is to make possible to attach a key to any object
> (directory,
> regular file, etc..) that is supposed to work with 

with what?  encryption?

> (there is a special pointer
> in reiser4-specific part of inode when this option is on), and
> propagate it down
> (root is up) through the semantic tree via its inheriting from parent
> objects).
> In spite of its simplicity there can be various obscured issues, so
> all comments
> are welcome.
>
> NOTE: This interface is over linux crypto-api.

URL please

>
>  I should remind that encryption and compression in reiser4 are
> performed in
> flush time for a special kind of reiser4 regular files (cryptcompress
> files).
> Currently only directories and cryptcompress regular files interact with
> cipher keys.
>
>
>                        I. Object cipher keyid
>
>
>  Each regular cryptcompress file should have a keyid (32-bit or
> greater word)
> which is created by reiser4 digest plugin and supposed to be stored in
> disk
> stat-data. The keyid exists because of 2 reasons:
> 1. It is used for key identification: even if cipher key is not
> loaded, user
>   can check the object keyid (for example by using a pseudo-file
> interface) and
>   use it to find an appropriate cipher key (which is located in mind or
>   somewhere on removable area).
> 2. It is used to not allow users load wrong keys, because writing to a
> file with
>   wrong key loaded leads to data corruption (it is harmfully

^harmfully^harmful

> not for the
>   filesystem, but for user)
>
>  Keyid is created by the pair "key-passphrase", where "key" is a
> string which
> is required by cipher algorithm and participates in cipher transforms,
> and
> "passphrase" is any private string. Both key and passphrase should be
> specified
> by user). Keyid is created by the following steps:
>
> 1. encrypting the passphrase by the key;
> 2. creating a big digest of the result by stable hash function
> (sha256, etc..)
> 3. having first N bits of the big digest as resulted keyid.
>

> Q: Is it safe to use only 32 bit for keyid?
> A: Having a 32-keyid does not allow to reveal a cipher key as the big
> digest
>   was created by safe operations. If you want to avoid collisions in key
>   identification add a new digest plugin that will create a greater
> keyid.

This assumes the use of a non-trivial passphrase.

>
>
>                     II. Importing a cipher key
>
>
>  First of all a cipher key should be imported to the kernel and
> uploaded to
> some object. We will use to say that key is attached to the object A
> meaning this
> initial importing and uploading to A.
>
>  One of the possible ways to attach a cipher key to an object is to
> implement
> it via a ->write() method of special new keyload pseudo file
> (PSEUDO_KEYLOAD_ID)
> of this object. It means accepting and parsing a pair
> "key-passphrase", then
> allocating and filling the following structure:
>
> typedef struct crypto_stat {
>       __u8 *keyid;          /* keyid */
>         int keyid_size;     /* keyid size */
>       ...
>       __u32 *key;           /* cipher key wrapped by
>                                struct crypto_tfm
> (include/linux/crypto.h) */
>       ...
>       int keyload_count;
> } crypto_stat_t;

How is it attached?   The below suggests it is part of the inode.... if
so say so here.

>
>
>        III. Packing/extracting crypto stat-data of the object
>
>  The crypto-stat of directory inode is not saved on disk.
> When writing inode of (cryptcompress) regular file, keysize and keyid
> are saved
> on disk in special reiser4 CRYPTO_STAT stat-data extension.
> When reading inode of regular file the ->present() method of this
> stat-data
> allocates and fills the crypto-stat, but without cipher key loaded
> (there are
> only keysize and keyid). Such incomplete crypto-stat can be used only to
> observe crypto-specific attributes of the file (for example by
> ->read() method
> of its keyload pseudo-file).
>
>
>                   IV. Propagating a cipher key
>
>
> Some definitions:
>
> To load a specified crypto-stat to the object means to keep a pointer
> to this
> structure in reiser4-specific part of inode and increment a
> keyload_count.
>
> To unload a crypto-stat of the object means to decrement keyload_count
> and free
> the structure if this count became zero.
>
> NOTE: All load/unload operations are protected by special per-superblock
> semaphore.
>
> Propagating a cipher key is going as

^going as^done by

> inheriting the crypto-stat from parent to
> child via special methods of reiser4 file plugin:
>
> 1. Inheriting during open()   is implemented via ->open();
> 2. Inheriting during create() is implemented via ->adjust_to_parent();
> 3. Inheriting during lookup() is implemented via ->bind().

Tell me more about inheriting via bind and open (why both, for example).

>
>  All those methods try to inherit crypto-stat from parent. If
> inheritance is
> possible, the old crypto-stat of the object is unloaded (if any) and
> new one
> is loaded. If the child is a directory, the inheritance is always
> possible.
> If the child is a cryptcomperss file inheritance is possible only if
> this child
> does not have a crypto-stat (file just created) or its keyid and other
> attributes (except a cipher key) coincide with the attributes of parent
> directory.
>  So if you wanna

wanna is informal english, use want to

> open/create a file one

One should use either one or you consistently, lest you confuse the
reader.;-)

> should attach a key to any existing
> member of its pathname. For example, in order to create
> "/mnt/mydir/myfile" one
> may attach a key either to "/mnt", or to "/mnt/mydir". In the first
> case it is
> possible that "/mnt/mydir" is in the cache already, so it is necessary
> also to
> open it for carrying out the key. Key can be attached to existing
> (cryptcompress) regular file if it does not have a cipher key loaded
> (also it
> should have in its plugin_set non-trivial cipher transform plugin
> installed).
>
>
>                    V. Eliminating a cipher key
>
>
> Eliminating is possible only as a result of unloading a crypto-stat
> that is used
> by nobody (keyload_count became zero). Eliminating can occur when
> 1. inheriting a crypto-stat (old crypto-stat is unloaded);
> 2. evicting from memory unused inode (its crypto stat is unloaded by
>   ->destroy_inode() method of file plugin).
>
>
>                  VI. Opening a cryptcompress file
>
>
> plugin->open() tries to inherit a crypto-stat from parent, then
> evaluates the
> expression (crypto_stat loaded => cipher key loaded). If it is not
> true, EINVAL
> will be returned.
>
>
>                 VII. An example of possible scenario (DRAFT):
>
> #pwd
> /mnt
> #mkdir mydir
> #echo -e "crc\0" > mydir/..../plugin/regular

Why the \0 ?  Can it be eliminated?  I don't need it when I use /proc.....

Do you think "crc" is user friendly?   What is a "plugin/regular"?  Why
not "plugin/file"?

> #cat mydir/..../plugin/regular
> 1 cryptcompress Cryptcompress regular plugin

The above is cryptic to me.

> #cat mydir/..../plugin/compression
> 0 lzo1 lzo1 compression transform

The above is cryptic to me.  Is it a list of the allowed values for
compression algorithm?  What is the 0?

> #cat mydir/..../plugin/digest
> 1 sha256-32 sha256-32 digest transform
> #cat mydir/..../plugin/crypto
> 0 none absence of crypto transform
> #echo -e "blowfish\0" > mydir/..../plugin/crypto
>
> #touch mydir/myfile
> Unable to create file
> #cat mydir/..../keyload
> No key loaded
>
> #echo -e "08e19c2d91bbc14f06af9ec61e68\0" > mydir/..../keyload
>          ^^----------------^^^^^^^^^^
>       keysize     key      passphrase
>
> #cat mydir/..../keyload
> keyid32: f56ef868
> loaded 8-byte key for Blowfish cipher algo
>
> #echo "Hello World" > mydir/myfile
> #cd /
> #umount /mnt
> #mount /dev/hdb5 /mnt
> #cat /mnt/mydir/myfile
> Unable to open file
> #cat /mnt/mydir/myfile/..../keyload
> keyid32: f56ef868
> No key loaded
>
> #echo -e "08e19c2d91bbc14f06af9ec61e68\0" > /mnt/mydir/..../keyload
> #cat /mnt/mydir/myfile
> Hello World

When you load a key, who can access the file?  Only the person who
loaded it, yes or?

>
>
>                       VIII. Thats all
>
>
> Thanks,
> Edward.
>
>

Re: Basic interface for key management in reiser4 (DRAFT)

[Edward Shishkin]

Hans Reiser wrote:

>How much of this is implemented at this time?
>  
>

~50%

>Your english has improved a lot.
>
>Edward Shishkin wrote:
>
>  
>
>> Hello everyone.
>>
>> Here is a description of a simple optional interface to import and
>>propagate
>>cipher keys. This interface will be available via 
>>    
>>
>
>a
>
>  
>
>>compile-time option
>>ENABLE_COMMON_CRYPTO_STAT which adds some fields to 
>>    
>>
>
>some
>
>  
>
>>in-memory structures
>>    
>>
>
>: the
>
>  
>
>>reiser4
>>superblock and 
>>    
>>
>
>the
>
>  
>
>>reiser4-specific part of
>>    
>>
>
>the
>
>  
>
>>inode.
>> The common idea is to make possible to attach a key to any object
>>(directory,
>>regular file, etc..) that is supposed to work with 
>>    
>>
>
>with what?  encryption?
>  
>

I meant to attach it to the objects that are supposed to work with this key.
Currently it is directories and cryptcompress files

>  
>
>>(there is a special pointer
>>in reiser4-specific part of inode when this option is on), and
>>propagate it down
>>(root is up) through the semantic tree via its inheriting from parent
>>objects).
>>In spite of its simplicity there can be various obscured issues, so
>>all comments
>>are welcome.
>>
>>NOTE: This interface is over linux crypto-api.
>>    
>>
>
>URL please
>  
>

there is no URL. Only a source of testing module linux/crypto/tcrypt.c
which shows how to use it

>  
>
>> I should remind that encryption and compression in reiser4 are
>>performed in
>>flush time for a special kind of reiser4 regular files (cryptcompress
>>files).
>>Currently only directories and cryptcompress regular files interact with
>>cipher keys.
>>
>>
>>                       I. Object cipher keyid
>>
>>
>> Each regular cryptcompress file should have a keyid (32-bit or
>>greater word)
>>which is created by reiser4 digest plugin and supposed to be stored in
>>disk
>>stat-data. The keyid exists because of 2 reasons:
>>1. It is used for key identification: even if cipher key is not
>>loaded, user
>>  can check the object keyid (for example by using a pseudo-file
>>interface) and
>>  use it to find an appropriate cipher key (which is located in mind or
>>  somewhere on removable area).
>>2. It is used to not allow users load wrong keys, because writing to a
>>file with
>>  wrong key loaded leads to data corruption (it is harmfully
>>    
>>
>
>^harmfully^harmful
>
>  
>
>>not for the
>>  filesystem, but for user)
>>
>> Keyid is created by the pair "key-passphrase", where "key" is a
>>string which
>>is required by cipher algorithm and participates in cipher transforms,
>>and
>>"passphrase" is any private string. Both key and passphrase should be
>>specified
>>by user). Keyid is created by the following steps:
>>
>>1. encrypting the passphrase by the key;
>>2. creating a big digest of the result by stable hash function
>>(sha256, etc..)
>>3. having first N bits of the big digest as resulted keyid.
>>
>>    
>>
>
>  
>
>>Q: Is it safe to use only 32 bit for keyid?
>>A: Having a 32-keyid does not allow to reveal a cipher key as the big
>>digest
>>  was created by safe operations. If you want to avoid collisions in key
>>  identification add a new digest plugin that will create a greater
>>keyid.
>>    
>>
>
>This assumes the use of a non-trivial passphrase.
>
>  
>
>>                    II. Importing a cipher key
>>
>>
>> First of all a cipher key should be imported to the kernel and
>>uploaded to
>>some object. We will use to say that key is attached to the object A
>>meaning this
>>initial importing and uploading to A.
>>
>> One of the possible ways to attach a cipher key to an object is to
>>implement
>>it via a ->write() method of special new keyload pseudo file
>>(PSEUDO_KEYLOAD_ID)
>>of this object. It means accepting and parsing a pair
>>"key-passphrase", then
>>allocating and filling the following structure:
>>
>>typedef struct crypto_stat {
>>      __u8 *keyid;          /* keyid */
>>        int keyid_size;     /* keyid size */
>>      ...
>>      __u32 *key;           /* cipher key wrapped by
>>                               struct crypto_tfm
>>(include/linux/crypto.h) */
>>      ...
>>      int keyload_count;
>>} crypto_stat_t;
>>    
>>
>
>How is it attached?   
>

via load operation described below in IV. (I have missed a reference here)

>The below suggests it is part of the inode.... if
>so say so here.
>
>  
>
>  
>
>>       III. Packing/extracting crypto stat-data of the object
>>
>> The crypto-stat of directory inode is not saved on disk.
>>When writing inode of (cryptcompress) regular file, keysize and keyid
>>are saved
>>on disk in special reiser4 CRYPTO_STAT stat-data extension.
>>When reading inode of regular file the ->present() method of this
>>stat-data
>>allocates and fills the crypto-stat, but without cipher key loaded
>>(there are
>>only keysize and keyid). Such incomplete crypto-stat can be used only to
>>observe crypto-specific attributes of the file (for example by
>>->read() method
>>of its keyload pseudo-file).
>>
>>
>>                  IV. Propagating a cipher key
>>
>>
>>Some definitions:
>>
>>To load a specified crypto-stat to the object means to keep a pointer
>>to this
>>structure in reiser4-specific part of inode and increment a
>>keyload_count.
>>
>>To unload a crypto-stat of the object means to decrement keyload_count
>>and free
>>the structure if this count became zero.
>>
>>NOTE: All load/unload operations are protected by special per-superblock
>>semaphore.
>>
>>Propagating a cipher key is going as
>>    
>>
>
>^going as^done by
>
>  
>
>>inheriting the crypto-stat from parent to
>>child via special methods of reiser4 file plugin:
>>
>>1. Inheriting during open()   is implemented via ->open();
>>2. Inheriting during create() is implemented via ->adjust_to_parent();
>>3. Inheriting during lookup() is implemented via ->bind().
>>    
>>
>
>Tell me more about inheriting via bind and open (why both, for example).
>  
>

The inode operation reiser4_lookup() calls plugin->bind() in the case 
when a new object
was looked up. But if the object is already present in the cache without 
cipher key loaded,
it will be convenient to have an additional way to inherit it (this is a 
hook in plugin->open()).
We may consider another approach when inheriting occurs at each 
reiser4_lookup (not only
for new objects which were not present in the cache). In this approach 
we do not need
to inherit a key during ->open(), but inheriting a cipher key at each 
lookup looks too
aggressive..

>  
>
>> All those methods try to inherit crypto-stat from parent. If
>>inheritance is
>>possible, the old crypto-stat of the object is unloaded (if any) and
>>new one
>>is loaded. If the child is a directory, the inheritance is always
>>possible.
>>If the child is a cryptcomperss file inheritance is possible only if
>>this child
>>does not have a crypto-stat (file just created) or its keyid and other
>>attributes (except a cipher key) coincide with the attributes of parent
>>directory.
>> So if you wanna
>>    
>>
>
>wanna is informal english, use want to
>
>  
>
>>open/create a file one
>>    
>>
>
>One should use either one or you consistently, lest you confuse the
>reader.;-)
>
>  
>
>>should attach a key to any existing
>>member of its pathname. For example, in order to create
>>"/mnt/mydir/myfile" one
>>may attach a key either to "/mnt", or to "/mnt/mydir". In the first
>>case it is
>>possible that "/mnt/mydir" is in the cache already, so it is necessary
>>also to
>>open it for carrying out the key. Key can be attached to existing
>>(cryptcompress) regular file if it does not have a cipher key loaded
>>(also it
>>should have in its plugin_set non-trivial cipher transform plugin
>>installed).
>>
>>
>>                   V. Eliminating a cipher key
>>
>>
>>Eliminating is possible only as a result of unloading a crypto-stat
>>that is used
>>by nobody (keyload_count became zero). Eliminating can occur when
>>1. inheriting a crypto-stat (old crypto-stat is unloaded);
>>2. evicting from memory unused inode (its crypto stat is unloaded by
>>  ->destroy_inode() method of file plugin).
>>
>>
>>                 VI. Opening a cryptcompress file
>>
>>
>>plugin->open() tries to inherit a crypto-stat from parent, then
>>evaluates the
>>expression (crypto_stat loaded => cipher key loaded). If it is not
>>true, EINVAL
>>will be returned.
>>
>>
>>                VII. An example of possible scenario (DRAFT):
>>
>>#pwd
>>/mnt
>>#mkdir mydir
>>#echo -e "crc\0" > mydir/..../plugin/regular
>>    
>>
>
>Why the \0 ?  Can it be eliminated?  I don't need it when I use /proc.....
>

I will check if we can avoid this

>Do you think "crc" is user friendly?
>

sorry, I was wrong: "crc" does not work. One should do
#echo -e "cryptcompress\0" > mydir/..../plugin/regular

>   What is a "plugin/regular"?  Why
>not "plugin/file"?
>

first, we have the following:
#cat mydir/..../plugin/file
1 dir directory

second, because the pseudo-file ..../plugin/file is readonly: it is 
impossible
to change a file plugin of existing object in reiser4, whereas we want to
have a pseudo-file to specify file plugins of children to create.
Vitaly also suggested to rename "regular" to "creat" that sounds like 
creat (2)

>
>  
>
>>#cat mydir/..../plugin/regular
>>1 cryptcompress Cryptcompress regular plugin
>>    
>>
>
>The above is cryptic to me.
>
>  
>
>>#cat mydir/..../plugin/compression
>>0 lzo1 lzo1 compression transform
>>    
>>
>
>The above is cryptic to me.
>

0 lzo1 lzo1 compression transform

^     ^     ^^^^^^^^^^^^^^^^^^^^^^^^^^
|   plugin label    plugin description
plugin id


>  Is it a list of the allowed values for
>compression algorithm?  What is the 0?
>
>  
>
>>#cat mydir/..../plugin/digest
>>1 sha256-32 sha256-32 digest transform
>>#cat mydir/..../plugin/crypto
>>0 none absence of crypto transform
>>#echo -e "blowfish\0" > mydir/..../plugin/crypto
>>
>>#touch mydir/myfile
>>Unable to create file
>>#cat mydir/..../keyload
>>No key loaded
>>
>>#echo -e "08e19c2d91bbc14f06af9ec61e68\0" > mydir/..../keyload
>>         ^^----------------^^^^^^^^^^
>>      keysize     key      passphrase
>>
>>#cat mydir/..../keyload
>>keyid32: f56ef868
>>loaded 8-byte key for Blowfish cipher algo
>>
>>#echo "Hello World" > mydir/myfile
>>#cd /
>>#umount /mnt
>>#mount /dev/hdb5 /mnt
>>#cat /mnt/mydir/myfile
>>Unable to open file
>>#cat /mnt/mydir/myfile/..../keyload
>>keyid32: f56ef868
>>No key loaded
>>
>>#echo -e "08e19c2d91bbc14f06af9ec61e68\0" > /mnt/mydir/..../keyload
>>#cat /mnt/mydir/myfile
>>Hello World
>>    
>>
>
>When you load a key, who can access the file?  Only the person who
>loaded it, yes or?
>

Currently standard unix permissions work here.

Edward.

Re: Basic interface for key management in reiser4 (DRAFT)

[Hans Reiser]

Edward Shishkin wrote:

>>
>
>>   What is a "plugin/regular"?  Why
>> not "plugin/file"?
>>
>
> first, we have the following:
> #cat mydir/..../plugin/file
> 1 dir directory
>
> second, because the pseudo-file ..../plugin/file is readonly

you can change that, but perhaps better would be to cat "crypt_compress"
> mydir/..../children_inherit/plugin

> : it is impossible
> to change a file plugin of existing object in reiser4, whereas we want to
> have a pseudo-file to specify file plugins of children to create.
> Vitaly also suggested to rename "regular" to "creat" that sounds like
> creat (2)
>
>>
>>  
>>
>>> #cat mydir/..../plugin/regular
>>> 1 cryptcompress Cryptcompress regular plugin
>>>   
>>
>>
>> The above is cryptic to me.
>>
>>  
>>
>>> #cat mydir/..../plugin/compression
>>> 0 lzo1 lzo1 compression transform
>>>   
>>
>>
>> The above is cryptic to me.
>>
>
> 0 lzo1 lzo1 compression transform
>
> ^     ^     ^^^^^^^^^^^^^^^^^^^^^^^^^^
> |   plugin label    plugin description
> plugin id

Why not a separate file for each of these fields?

>
>
>>  Is it a list of the allowed values for
>> compression algorithm?  What is the 0?
>>
>>  
>>
>>> #cat mydir/..../plugin/digest
>>> 1 sha256-32 sha256-32 digest transform
>>> #cat mydir/..../plugin/crypto
>>> 0 none absence of crypto transform
>>> #echo -e "blowfish\0" > mydir/..../plugin/crypto
>>>
>>> #touch mydir/myfile
>>> Unable to create file
>>> #cat mydir/..../keyload
>>> No key loaded
>>>
>>> #echo -e "08e19c2d91bbc14f06af9ec61e68\0" > mydir/..../keyload
>>>         ^^----------------^^^^^^^^^^
>>>      keysize     key      passphrase
>>>
>>> #cat mydir/..../keyload
>>> keyid32: f56ef868
>>> loaded 8-byte key for Blowfish cipher algo
>>>
>>> #echo "Hello World" > mydir/myfile
>>> #cd /
>>> #umount /mnt
>>> #mount /dev/hdb5 /mnt
>>> #cat /mnt/mydir/myfile
>>> Unable to open file
>>> #cat /mnt/mydir/myfile/..../keyload
>>> keyid32: f56ef868
>>> No key loaded
>>>
>>> #echo -e "08e19c2d91bbc14f06af9ec61e68\0" > /mnt/mydir/..../keyload
>>> #cat /mnt/mydir/myfile
>>> Hello World
>>>   
>>
>>
>> When you load a key, who can access the file?  Only the person who
>> loaded it, yes or?
>>
>
> Currently standard unix permissions work here.

but the idea is to use keys instead of standard unix permissions....

I think you need to store keys in a per process place, and allow
specifying whether children of a process inherit the keys somehow.

>
> Edward.
>
>
>

Re: Basic interface for key management in reiser4 (DRAFT)

[Gregory Maxwell]

On 8/18/05, Hans Reiser <reiser@namesys.com> wrote:
> but the idea is to use keys instead of standard unix permissions....
> 
> I think you need to store keys in a per process place, and allow
> specifying whether children of a process inherit the keys somehow.

Oh, slick!

I did not previously catch what the advantage would be to using crypto
in the FS rather than just a crypted block device... minus some non
critical niceties (like being able to use a random & per file IV is
good from a security perspective.).

Now I see what is possible, and I'm really excited.

It will be interesting to see how a system with many keys performs..
most fast implementations of most crypto algs need a computationally
expensive key setup which produces a fairly large working set of
constants for encryption/decryption.

With a per process structure there should be a way to revoke all
instances of a key from all the other running processes that carry
it.. or at least all processes of a specific user. Otherwise it will
be too easy to accidental leave keys laying around.

This per process crypto in the FS fits very nicely with a lot of the
other recent security advances in the Linux world.

Thanks for something new and exciting to talk about with my Linux
using friends! :)

Re: Basic interface for key management in reiser4 (DRAFT)

[Hans Reiser]

I think it would make sense to put the keys as files in /proc:

e.g.
touch  /proc/1/keys/private/"0893410984328098094321"
would give init (aka process with id of 1) a new key that its children
would not inherit

touch  /proc/1/keys/inheritable/"1893410984328098094321"
would give init a new key that is children WOULD inherit.

Not sure what the permissions on that keys directory would be, I guess 700.

Hans

Gregory Maxwell wrote:

>On 8/18/05, Hans Reiser <reiser@namesys.com> wrote:
>  
>
>>but the idea is to use keys instead of standard unix permissions....
>>
>>I think you need to store keys in a per process place, and allow
>>specifying whether children of a process inherit the keys somehow.
>>    
>>
>
>Oh, slick!
>
>I did not previously catch what the advantage would be to using crypto
>in the FS rather than just a crypted block device... minus some non
>critical niceties (like being able to use a random & per file IV is
>good from a security perspective.).
>
>Now I see what is possible, and I'm really excited.
>
>It will be interesting to see how a system with many keys performs..
>most fast implementations of most crypto algs need a computationally
>expensive key setup which produces a fairly large working set of
>constants for encryption/decryption.
>
>With a per process structure there should be a way to revoke all
>instances of a key from all the other running processes that carry
>it.. or at least all processes of a specific user. Otherwise it will
>be too easy to accidental leave keys laying around.
>
>This per process crypto in the FS fits very nicely with a lot of the
>other recent security advances in the Linux world.
>
>Thanks for something new and exciting to talk about with my Linux
>using friends! :)
>
>
>  
>

Re: Basic interface for key management in reiser4 (DRAFT)

[Gregory Maxwell]

On 8/19/05, Hans Reiser <reiser@namesys.com> wrote:
> I think it would make sense to put the keys as files in /proc:
> e.g.
> touch  /proc/1/keys/private/"0893410984328098094321"
> would give init (aka process with id of 1) a new key that its children
> would not inherit
> touch  /proc/1/keys/inheritable/"1893410984328098094321"
> would give init a new key that is children WOULD inherit.
> 
> Not sure what the permissions on that keys directory would be, I guess 700.

Eh, that would make leaks of key information easy..  Since most
applications don't assume that something visable in a file name could
be highly confidential information. :)

Better to have the file in proc be an abbriviated keyid (some kind of
smaller lossy hash of the key). To add you might echo "label:real key
data" > /proc/1/keys/private/keys, and a file would appear named
/proc/1/keys/private/label-123abcd which is a user defined label and
the hash.

Under no condition should a process be able to actually read the key
data.. they can get the ID.. delete keys based on IDs.. etc. But they
can't get the data.. otherwise a process could steal keys. If I take
away a processes key from proc, there should be no way for it to get
any further access to those files.. no chance that it could have
hidden away a copy of that key.

On 8/19/05, Hans Reiser <reiser@namesys.com> wrote:
> I think it would make sense to put the keys as files in /proc:
> 
> e.g.
> touch  /proc/1/keys/private/"0893410984328098094321"
> would give init (aka process with id of 1) a new key that its children
> would not inherit
> 
> touch  /proc/1/keys/inheritable/"1893410984328098094321"
> would give init a new key that is children WOULD inherit.
> 
> Not sure what the permissions on that keys directory would be, I guess 700.
> 
> Hans
> 
> Gregory Maxwell wrote:
> 
> >On 8/18/05, Hans Reiser <reiser@namesys.com> wrote:
> >
> >
> >>but the idea is to use keys instead of standard unix permissions....
> >>
> >>I think you need to store keys in a per process place, and allow
> >>specifying whether children of a process inherit the keys somehow.
> >>
> >>
> >
> >Oh, slick!
> >
> >I did not previously catch what the advantage would be to using crypto
> >in the FS rather than just a crypted block device... minus some non
> >critical niceties (like being able to use a random & per file IV is
> >good from a security perspective.).
> >
> >Now I see what is possible, and I'm really excited.
> >
> >It will be interesting to see how a system with many keys performs..
> >most fast implementations of most crypto algs need a computationally
> >expensive key setup which produces a fairly large working set of
> >constants for encryption/decryption.
> >
> >With a per process structure there should be a way to revoke all
> >instances of a key from all the other running processes that carry
> >it.. or at least all processes of a specific user. Otherwise it will
> >be too easy to accidental leave keys laying around.
> >
> >This per process crypto in the FS fits very nicely with a lot of the
> >other recent security advances in the Linux world.
> >
> >Thanks for something new and exciting to talk about with my Linux
> >using friends! :)
> >
> >
> >
> >
> 
>

Re: Basic interface for key management in reiser4 (DRAFT)

[Edward Shishkin]

Gregory Maxwell wrote:

>On 8/19/05, Hans Reiser <reiser@namesys.com> wrote:
>  
>
>>I think it would make sense to put the keys as files in /proc:
>>e.g.
>>touch  /proc/1/keys/private/"0893410984328098094321"
>>would give init (aka process with id of 1) a new key that its children
>>would not inherit
>>touch  /proc/1/keys/inheritable/"1893410984328098094321"
>>would give init a new key that is children WOULD inherit.
>>
>>Not sure what the permissions on that keys directory would be, I guess 700.
>>    
>>
>
>Eh, that would make leaks of key information easy..  Since most
>applications don't assume that something visable in a file name could
>be highly confidential information. :)
>
>Better to have the file in proc be an abbriviated keyid (some kind of
>smaller lossy hash of the key). To add you might echo "label:real key
>data" > /proc/1/keys/private/keys, and a file would appear named
>/proc/1/keys/private/label-123abcd which is a user defined label and
>the hash.
>
>Under no condition should a process be able to actually read the key
>data.. they can get the ID.. delete keys based on IDs.. etc. But they
>can't get the data.. otherwise a process could steal keys. If I take
>away a processes key from proc, there should be no way for it to get
>any further access to those files.. no chance that it could have
>hidden away a copy of that key.
>  
>

There is some interface in the latest mm-kernels (not sure about others).
I can consider its using for reiser4, if we want to attach keys per process:

config KEYS
    bool "Enable access key retention support"
    help
      This option provides support for retaining authentication tokens and
      access keys in the kernel.

      It also includes provision of methods by which such keys might be
      associated with a process so that network filesystems, encryption
      support and the like can find them.

      Furthermore, a special type of key is available that acts as keyring:
      a searchable sequence of keys. Each process is equipped with access
      to five standard keyrings: UID-specific, GID-specific, session,
      process and thread.

      If you are unsure as to whether this is required, answer N.

More info in linux/Documentation/keys.txt

>On 8/19/05, Hans Reiser <reiser@namesys.com> wrote:
>  
>
>>I think it would make sense to put the keys as files in /proc:
>>
>>e.g.
>>touch  /proc/1/keys/private/"0893410984328098094321"
>>would give init (aka process with id of 1) a new key that its children
>>would not inherit
>>
>>touch  /proc/1/keys/inheritable/"1893410984328098094321"
>>would give init a new key that is children WOULD inherit.
>>
>>Not sure what the permissions on that keys directory would be, I guess 700.
>>
>>Hans
>>
>>Gregory Maxwell wrote:
>>
>>    
>>
>>>On 8/18/05, Hans Reiser <reiser@namesys.com> wrote:
>>>
>>>
>>>      
>>>
>>>>but the idea is to use keys instead of standard unix permissions....
>>>>
>>>>I think you need to store keys in a per process place, and allow
>>>>specifying whether children of a process inherit the keys somehow.
>>>>
>>>>
>>>>        
>>>>
>>>Oh, slick!
>>>
>>>I did not previously catch what the advantage would be to using crypto
>>>in the FS rather than just a crypted block device... minus some non
>>>critical niceties (like being able to use a random & per file IV is
>>>good from a security perspective.).
>>>
>>>Now I see what is possible, and I'm really excited.
>>>
>>>It will be interesting to see how a system with many keys performs..
>>>most fast implementations of most crypto algs need a computationally
>>>expensive key setup which produces a fairly large working set of
>>>constants for encryption/decryption.
>>>
>>>With a per process structure there should be a way to revoke all
>>>instances of a key from all the other running processes that carry
>>>it.. or at least all processes of a specific user. Otherwise it will
>>>be too easy to accidental leave keys laying around.
>>>
>>>This per process crypto in the FS fits very nicely with a lot of the
>>>other recent security advances in the Linux world.
>>>
>>>Thanks for something new and exciting to talk about with my Linux
>>>using friends! :)
>>>
>>>
>>>
>>>
>>>      
>>>
>>    
>>
>
>
>  
>

Re: Basic interface for key management in reiser4 (DRAFT)

[Edward Shishkin]

Gregory Maxwell wrote:

>On 8/18/05, Hans Reiser <reiser@namesys.com> wrote:
>  
>
>>but the idea is to use keys instead of standard unix permissions....
>>
>>I think you need to store keys in a per process place, and allow
>>specifying whether children of a process inherit the keys somehow.
>>    
>>
>
>Oh, slick!
>
>I did not previously catch what the advantage would be to using crypto
>in the FS rather than just a crypted block device... minus some non
>critical niceties (like being able to use a random & per file IV
>

Actually it is critical:
http://marc.theaimsgroup.com/?l=linux-kernel&m=107719798631935&w=2
But why random? It is slowly.. I would prefer object-id-based one..


>is
>good from a security perspective.).
>
>Now I see what is possible, and I'm really excited.
>
>It will be interesting to see how a system with many keys performs..
>most fast implementations of most crypto algs need a computationally
>expensive key setup which produces a fairly large working set of
>constants for encryption/decryption.
>
>With a per process structure there should be a way to revoke all
>instances of a key from all the other running processes that carry
>it.. or at least all processes of a specific user. Otherwise it will
>be too easy to accidental leave keys laying around.
>
>This per process crypto in the FS fits very nicely with a lot of the
>other recent security advances in the Linux world.
>
>Thanks for something new and exciting to talk about with my Linux
>using friends! :)
>
>
>  
>

Re: Basic interface for key management in reiser4 (DRAFT)

[Gregory Maxwell]

On 8/19/05, Edward Shishkin <edward@namesys.com> wrote:
> Actually it is critical:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=107719798631935&w=2
> But why random? It is slowly.. I would prefer object-id-based one..

The IV doesn't need to be random, but it should be different for every
instance of a file, different every time a file is deleted and
recreated, not increment in any predictable way between files, and be
impossible to control by a user. It should have a low possibility of
reuse.

Earlier linux DM crypt had a weakness where the IV incremented with
every block in the file system, this lead to some interesting
watermarking attacks. It was possible to form a stream of data with
changes that negated the XORs from the trivially incremented IV, and
thus the first block of each sector could be used to form an
electronic code book. This has since been corrected with a couple of
options (one is to use the cryptographic hash of the block number).

If the user has some way of trivially influencing differences in the
object ID, for example sequential files have sequential object id,
then the object ID should be passed through a hash function so that a
user must know the full object iD in order to predict even a single
bitflip.

Re: Basic interface for key management in reiser4 (DRAFT)

[Edward Shishkin]

Hans Reiser wrote:

>Edward Shishkin wrote:
>
>  
>
>>>  What is a "plugin/regular"?  Why
>>>not "plugin/file"?
>>>
>>>      
>>>
>>first, we have the following:
>>#cat mydir/..../plugin/file
>>1 dir directory
>>
>>second, because the pseudo-file ..../plugin/file is readonly
>>    
>>
>
>you can change that, but perhaps better would be to cat "crypt_compress"
>  
>
>>mydir/..../children_inherit/plugin
>>    
>>
>
>  
>
>>: it is impossible
>>to change a file plugin of existing object in reiser4, whereas we want to
>>have a pseudo-file to specify file plugins of children to create.
>>Vitaly also suggested to rename "regular" to "creat" that sounds like
>>creat (2)
>>
>>    
>>
>>> 
>>>
>>>      
>>>
>>>>#cat mydir/..../plugin/regular
>>>>1 cryptcompress Cryptcompress regular plugin
>>>>  
>>>>        
>>>>
>>>The above is cryptic to me.
>>>
>>> 
>>>
>>>      
>>>
>>>>#cat mydir/..../plugin/compression
>>>>0 lzo1 lzo1 compression transform
>>>>  
>>>>        
>>>>
>>>The above is cryptic to me.
>>>
>>>      
>>>
>>0 lzo1 lzo1 compression transform
>>
>>^     ^     ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>|   plugin label    plugin description
>>plugin id
>>    
>>
>
>Why not a separate file for each of these fields?
>
>  
>
>>    
>>
>>> Is it a list of the allowed values for
>>>compression algorithm?  What is the 0?
>>>
>>> 
>>>
>>>      
>>>
>>>>#cat mydir/..../plugin/digest
>>>>1 sha256-32 sha256-32 digest transform
>>>>#cat mydir/..../plugin/crypto
>>>>0 none absence of crypto transform
>>>>#echo -e "blowfish\0" > mydir/..../plugin/crypto
>>>>
>>>>#touch mydir/myfile
>>>>Unable to create file
>>>>#cat mydir/..../keyload
>>>>No key loaded
>>>>
>>>>#echo -e "08e19c2d91bbc14f06af9ec61e68\0" > mydir/..../keyload
>>>>        ^^----------------^^^^^^^^^^
>>>>     keysize     key      passphrase
>>>>
>>>>#cat mydir/..../keyload
>>>>keyid32: f56ef868
>>>>loaded 8-byte key for Blowfish cipher algo
>>>>
>>>>#echo "Hello World" > mydir/myfile
>>>>#cd /
>>>>#umount /mnt
>>>>#mount /dev/hdb5 /mnt
>>>>#cat /mnt/mydir/myfile
>>>>Unable to open file
>>>>#cat /mnt/mydir/myfile/..../keyload
>>>>keyid32: f56ef868
>>>>No key loaded
>>>>
>>>>#echo -e "08e19c2d91bbc14f06af9ec61e68\0" > /mnt/mydir/..../keyload
>>>>#cat /mnt/mydir/myfile
>>>>Hello World
>>>>  
>>>>        
>>>>
>>>When you load a key, who can access the file?  Only the person who
>>>loaded it, yes or?
>>>
>>>      
>>>
>>Currently standard unix permissions work here.
>>    
>>
>
>but the idea is to use keys instead of standard unix permissions....
>
>I think you need to store keys in a per process place, and allow
>specifying whether children of a process inherit the keys somehow.
>  
>

Do we need the semantic tree-based propagating:
Hans Reiser wrote:
#We would like to implement the functionality to allow the default
#plugin for a directory such as the home directory to be encrypted,
#and for everything else to not be encrypted for better performance.
#... we would like to make it possible for the descendents of this
#directory to share one key.
?

Edward.

Re: Basic interface for key management in reiser4 (DRAFT)

[Edward Shishkin]

Hans Reiser wrote:

>Edward Shishkin wrote:
>
>  
>
>>>
>>>When you load a key, who can access the file?  Only the person who
>>>loaded it, yes or?
>>>
>>>      
>>>
>>Currently standard unix permissions work here.
>>    
>>
>
>but the idea is to use keys instead of standard unix permissions....
>
>I think you need to store keys in a per process place, and allow
>specifying whether children of a process inherit the keys somehow.
>  
>

Unfortunately the encrypt-on-flush violates all this beauty: the flush,
which serves all the files, can not look for a key in the process
keyring (*), therefore besides the process keyrings, reiser4 should
create and manage its own keyring (accessible to the flush). It means
additional charges on searching, hashing, updating, etc..

(*) Because:
    1) the flush does not have needed task_struct;
    2) the flush can not return an error if someone killed the key in 
the process keyring.

Edward.

Re: Basic interface for key management in reiser4 (DRAFT)

[Hans Reiser]

Edward Shishkin wrote:

> Hans Reiser wrote:
>
>> Edward Shishkin wrote:
>>
>>  
>>
>>>>
>>>> When you load a key, who can access the file?  Only the person who
>>>> loaded it, yes or?
>>>>
>>>>     
>>>
>>> Currently standard unix permissions work here.
>>>   
>>
>>
>> but the idea is to use keys instead of standard unix permissions....
>>
>> I think you need to store keys in a per process place, and allow
>> specifying whether children of a process inherit the keys somehow.
>>  
>>
>
> Unfortunately the encrypt-on-flush violates all this beauty: the flush,
> which serves all the files, can not look for a key in the process
> keyring (*), therefore besides the process keyrings, reiser4 should
> create and manage its own keyring (accessible to the flush). It means
> additional charges on searching, hashing, updating, etc..
>
> (*) Because:
>    1) the flush does not have needed task_struct;
>    2) the flush can not return an error if someone killed the key in
> the process keyring.
>
> Edward.
>
>
per process is not the same as "in user space and under user control"

Also the key to encrypt a given file with should be specified to the fs
at open() or at  sys_reiser4() time, not at flush time.

Please consider these thoughts, and then revise and resend your opinion
on this.