Several questions about encrypted filesystem

Several questions about encrypted filesystem

[Zhao, Forrest]

[-- Attachment #1: Type: text/plain, Size: 495 bytes --]

Hi,

 

I'm a new comer to Reiserfs list and have several questions about
encrypted filesystem:

 

1 From the mail list, I know that Reiserfs can encrypt and compress
individual file and directory. I'd like to know Does Reiserfs support
encrypting the entire partition and even the whole root fs?

 

2 what's the difference between the encryption mechanism behind Reiserfs
and other loopback device-based encryption implementation?

 

Thanks in advance

 

Forrest

Re: Several questions about encrypted filesystem

[Edward Shushkin]

"Zhao, Forrest" wrote:
> 
> Hi,
> 
> 
> 
> I'm a new comer to Reiserfs list and have several questions about
> encrypted filesystem:
> 
> 
> 
> 1 From the mail list, I know that Reiserfs can encrypt and compress
> individual file and directory. I'd like to know Does Reiserfs support
> encrypting the entire partition and even the whole root fs?

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.   

> 
> 
> 
> 2 what's the difference between the encryption mechanism behind Reiserfs
> and other loopback device-based encryption implementation?

file system can perform encryption on suitable layer (in flush-and-commit
time), it means an advantage.

Thanks, 
Edward.

> 
> 
> 
> Thanks in advance
> 
> 
> 
> Forrest

Re: Several questions about encrypted filesystem

[Hans Reiser]

V4 performs individual file encryption and compression, and it performs 
it at flush to disk time rather than at every write for performance reasons.

We are going to move reiserfs gradually more and more towards encryption 
based security, it is especially important for distributed file systems.

How we integrate into the PKI is still being designed, right now we are 
working on making encryption and compression work in the lower layers, 
and later we will look at how processes should inherit keys from each 
other, etc.

-- 
Hans

Re: Several questions about encrypted filesystem

[Heinz-Josef Claes]

Am Die, 2003-06-17 um 18.02 schrieb Hans Reiser:
> V4 performs individual file encryption and compression, and it performs 
> it at flush to disk time rather than at every write for performance reasons.
> 
> We are going to move reiserfs gradually more and more towards encryption 
> based security, it is especially important for distributed file systems.
> 
> How we integrate into the PKI is still being designed, right now we are 
> working on making encryption and compression work in the lower layers, 
> and later we will look at how processes should inherit keys from each 
> other, etc.

I'm really not a specialist in encryption. If it should be really useful
in a "normal" office evironment it should be possible to handle the
following on the lokal and on the remote filesystem:
- mounting different filesystems via NFS
- mounting different filesystems via SMB (Samba) from Windows
- sharing group filesystems between different users
- combination with unix permissions and ACLs (I don't know if this makes
sense)

Pershaps this is possible with kerberos or something like this!?
*But* all of the above does encrypt on the network.

I've heard about (commercial) software which does all of this on the
client side (on windows).
Do you have any ideas how to solve or integrate these problems in the
(lokal?) solution or is this behind your focus?

Regards,
Heinz-Josef Claes

Re: Several questions about encrypted filesystem

[Edward Shushkin]

Heinz-Josef Claes wrote:
> 
> Am Die, 2003-06-17 um 18.02 schrieb Hans Reiser:
> > V4 performs individual file encryption and compression, and it performs
> > it at flush to disk time rather than at every write for performance reasons.
> >
> > We are going to move reiserfs gradually more and more towards encryption
> > based security, it is especially important for distributed file systems.
> >
> > How we integrate into the PKI is still being designed, right now we are
> > working on making encryption and compression work in the lower layers,
> > and later we will look at how processes should inherit keys from each
> > other, etc.
> 
> I'm really not a specialist in encryption. If it should be really useful
> in a "normal" office evironment it should be possible to handle the
> following on the lokal and on the remote filesystem:
> - mounting different filesystems via NFS
> - mounting different filesystems via SMB (Samba) from Windows
> - sharing group filesystems between different users
> - combination with unix permissions and ACLs (I don't know if this makes
> sense)
> 
> Pershaps this is possible with kerberos or something like this!?
> *But* all of the above does encrypt on the network.

Actually kerberos is to detect transfer errors of big packets (it uses
a special chaining mode which smears a whole packet during decryption
if error occurs). This feature is incompatible with file system purpose
(to be precisely, with the purpose of its default plugins) which is
required to not spend a lot of resources when you ask to read 2 bytes
from any offset. However we'll support chaining, but it should going
on in very restricted volumes (< 32-128K). For other special plugins 
everything is possible (for instance large crypto-logs where chaining
is going per whole file: each string is encrypted by its own key generated
from previous one by special rules, etc..)

Edward.


> 
> I've heard about (commercial) software which does all of this on the
> client side (on windows).
> Do you have any ideas how to solve or integrate these problems in the
> (lokal?) solution or is this behind your focus?
> 
> Regards,
> Heinz-Josef Claes

Re: Several questions about encrypted filesystem

[Heinz-Josef Claes]

Am Mit, 2003-06-18 um 17.20 schrieb Edward Shushkin:
> Heinz-Josef Claes wrote:
> > 
> > Am Die, 2003-06-17 um 18.02 schrieb Hans Reiser:
> > > V4 performs individual file encryption and compression, and it performs
> > > it at flush to disk time rather than at every write for performance reasons.
> > >
> > > We are going to move reiserfs gradually more and more towards encryption
> > > based security, it is especially important for distributed file systems.
> > >
> > > How we integrate into the PKI is still being designed, right now we are
> > > working on making encryption and compression work in the lower layers,
> > > and later we will look at how processes should inherit keys from each
> > > other, etc.
> > 
> > I'm really not a specialist in encryption. If it should be really useful
> > in a "normal" office evironment it should be possible to handle the
> > following on the lokal and on the remote filesystem:
> > - mounting different filesystems via NFS
> > - mounting different filesystems via SMB (Samba) from Windows
> > - sharing group filesystems between different users
> > - combination with unix permissions and ACLs (I don't know if this makes
> > sense)
> > 
> > Pershaps this is possible with kerberos or something like this!?
> > *But* all of the above does encrypt on the network.
Sorry, my intention naturally was:
But all of the above does *not* encrypt on the network.
> 
> Actually kerberos is to detect transfer errors of big packets (it uses
> a special chaining mode which smears a whole packet during decryption
> if error occurs). This feature is incompatible with file system purpose
> (to be precisely, with the purpose of its default plugins) which is
> required to not spend a lot of resources when you ask to read 2 bytes
> from any offset. However we'll support chaining, but it should going
> on in very restricted volumes (< 32-128K). For other special plugins 
> everything is possible (for instance large crypto-logs where chaining
> is going per whole file: each string is encrypted by its own key generated
> from previous one by special rules, etc..)
> 
> Edward.
> 
My idea with something like kerberos _to_authentificate_ to a remote
file system is:
- single authentification on the network
- kerberos is an existing system for authentification in linux and other
OS'es.
(But as I wrote in the beginning, I'm a bloody amateur in encryption :-)
> 
> > 
> > I've heard about (commercial) software which does all of this on the
> > client side (on windows).
> > Do you have any ideas how to solve or integrate these problems in the
> > (lokal?) solution or is this behind your focus?
> > 
> > Regards,
> > Heinz-Josef Claes
> 

Re: Several questions about encrypted filesystem

[Timothy Webster]

Hi,
The first question in my mind is always key
management. By that I mean, where are the keys stored,
how are does key rotation occurr, who holds the keys
for shared files, (by this I mean serveral authers
contributed to a file).

1) Shared files, and file parts.
In order to address this situation. Access needs to be
broken into parts, authenication, authorization,
encryption/decryption. These can be though as an
"signed authenication module", "trusted authorization
database server", "signed encryption/decryption
module". By signed and trusted, I mean the local
authenication and encryption modules care out a secure
hand shake with the authorization server. The
authenitcation module must prove that its code trust
worthy to the authorization server. And the
authorization server must prove to the authenication
module that it is "the" authorization server the
authenication module was designed to trust. And
similarly for the encryption/decryption module.
Why all this work? So that each can be run by
different users perhaps on different hosts, such as
"SAN".

2) Key rotation and backups
Over time the number of keys quickly become
prohibitive. You need to in stead store the "seed key
and the dimension" of multi-dimension key space. The
multi-dimension key space is actually several key
spaces combined to make a higher dimensional key
space. 
The key space is created by sequencal encryption of
the seed key inserted into dimension space controlled
by a "secure" psedo-random walk. When a new key is
required it is taken form the mult-dimensional key
space as the next index number. Keys don't need to use
all the deminsion in its index number. Which allows
transition to new key spaces as old ones get filled.
Or Remote sites which will ofcourse have different key
spaces.

At some point in the future a particular key is
required, it is retrived by first regenating the key
space, then using the key in the key space specified
my the "particular" key's index number. There is no
reason that the key's index number and key space
"number" can not be stored in the clear, lets say in
the file header.

Using this method there is basically unlimited keys
available, and they can be stored and retrived
efficently.


This is brief and incomplete.
-tim
 

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: Several questions about encrypted filesystem

[Edward Shushkin]

Timothy Webster wrote:
> 
> Hi,
> The first question in my mind is always key
> management. By that I mean, where are the keys stored,
> how are does key rotation occurr, who holds the keys
> for shared files, (by this I mean serveral authers
> contributed to a file).
> 
> 1) Shared files, and file parts.
> In order to address this situation. Access needs to be
> broken into parts, authenication, authorization,
> encryption/decryption. These can be though as an
> "signed authenication module", "trusted authorization
> database server", "signed encryption/decryption
> module". By signed and trusted, I mean the local
> authenication and encryption modules care out a secure
> hand shake with the authorization server. The
> authenitcation module must prove that its code trust
> worthy to the authorization server. And the
> authorization server must prove to the authenication
> module that it is "the" authorization server the
> authenication module was designed to trust. And
> similarly for the encryption/decryption module.
> Why all this work? So that each can be run by
> different users perhaps on different hosts, such as
> "SAN".
> 
> 2) Key rotation and backups
> Over time the number of keys quickly become
> prohibitive. You need to in stead store the "seed key
> and the dimension" of multi-dimension key space. The
> multi-dimension key space is actually several key
> spaces combined to make a higher dimensional key
> space.
> The key space is created by sequencal encryption of
> the seed key inserted into dimension space controlled
> by a "secure" psedo-random walk. When a new key is
> required it is taken form the mult-dimensional key
> space as the next index number. Keys don't need to use
> all the deminsion in its index number.

Ok, this requires additional identification (key, seed).
So if you export a key created 10 years ago, then there 
will be only one key in the appropriate multi-dimension
key space, right? ;)

Edward. 

 Which allows
> transition to new key spaces as old ones get filled.
> Or Remote sites which will ofcourse have different key
> spaces.
> 
> At some point in the future a particular key is
> required, it is retrived by first regenating the key
> space, then using the key in the key space specified
> my the "particular" key's index number. There is no
> reason that the key's index number and key space
> "number" can not be stored in the clear, lets say in
> the file header.
> 
> Using this method there is basically unlimited keys
> available, and they can be stored and retrived
> efficently.
> 
> This is brief and incomplete.
> -tim
> 
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com

Re: Several questions about encrypted filesystem

[Timothy Webster]

--- Edward Shushkin <edward@namesys.com> wrote:
> Timothy Webster wrote:
> > 2) Key rotation and backups
> > Over time the number of keys quickly become
> > prohibitive. You need to in stead store the "seed
key
> > and the dimension" of multi-dimension key space.
The
> > multi-dimension key space is actually several key
> > spaces combined to make a higher dimensional key
> > space.
> > The key space is created by sequencal encryption
of
> > the seed key inserted into dimension space
controlled
> > by a "secure" psedo-random walk. When a new key is
> > required it is taken form the mult-dimensional key
> > space as the next index number. Keys don't need to
use
> > all the deminsion in its index number.
> 
> Ok, this requires additional identification (key,
seed).
> So if you export a key created 10 years ago, then
there 
> will be only one key in the appropriate
multi-dimension
> key space, right? ;)
> 
> Edward. 

>  Which allows

You are quite right, in order to recover the key you 
need the (key seed, pseudo-random walk, and the 
deminsions) of each key space of the multi-deminision 
key space. You may also wish store the pseudo-random 
walk seed. I recommend you do, otherwise it may be
possible for an attacker to some how gather a few 
key points and knowing the pseudo-random walk, 
regenerate their own key space. Which means you 
need to "securely store" key space number, key seed, 
pseudo-random walk seed, "sets".To recover a 
specific key created 10 years ago, you need its
index number and its multi-dimensional key space 
number. To use the dimensions of the multi-dimension
key space, there are few approaches. First is to
combine the key components; 
- using the same technequies by which incremential 
hashes are combinded,
- or a selection, (this of course) is equivalent 
to onlyusing one key space of the multi-deminsional 
key space.

By the way you can do some really kool interesting 
stuffbased on how you construct the combined keys.
You can set up an error correcting code such that 
to reconstruct the key you need at least x parts 
from component group A and y parts from component 
group B andso on to as many component groups you
want. This is handy if you are going to allow 
multiple users to retrive a file created 10 years 
ago. Doing the combined key at this level gets 
around the problem that a "key server" own by 
company / country "C" does not want this 
information recovered. And you don't wish to give 
them veto power.Or if you lost one (key space number) 
set.

Forgive me it has been over 5 years since I thought 
of about this. So a lot of this is just coming off 
the top of my head. :)


-tim.

The the need for speed brings of the next issue 
incrementalfile part hashes and encryptions. The 
incremental parts can be combined using discrete 
log or nap sack type combining. XORing allows a 
sub problem attact. It is also handy to keep in 
mind that also knowing the file or file part size
greatly reduces the chance of collision.


> > transition to new key spaces as old ones get
filled.
> > Or Remote sites which will ofcourse have different
key
> > spaces.
> > 
> > At some point in the future a particular key is
> > required, it is retrived by first regenating the
key
> > space, then using the key in the key space
specified
> > my the "particular" key's index number. There is
no
> > reason that the key's index number and key space
> > "number" can not be stored in the clear, lets say
in
> > the file header.
> > 
> > Using this method there is basically unlimited
keys
> > available, and they can be stored and retrived
> > efficently.
> > 
> > This is brief and incomplete.
> > -tim
> > > 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: Several questions about encrypted filesystem

[Hans Reiser]

Timothy Webster wrote:

>Hi,
>The first question in my mind is always key
>management. By that I mean, where are the keys stored,
>how are does key rotation occurr, who holds the keys
>for shared files, (by this I mean serveral authers
>contributed to a file).
>
>1) Shared files, and file parts.
>In order to address this situation. Access needs to be
>broken into parts, authenication, authorization,
>encryption/decryption. These can be though as an
>"signed authenication module", "trusted authorization
>database server", "signed encryption/decryption
>module". By signed and trusted, I mean the local
>authenication and encryption modules care out a secure
>hand shake with the authorization server. The
>authenitcation module must prove that its code trust
>worthy to the authorization server. And the
>authorization server must prove to the authenication
>module that it is "the" authorization server the
>authenication module was designed to trust. And
>similarly for the encryption/decryption module.
>Why all this work? So that each can be run by
>different users perhaps on different hosts, such as
>"SAN".
>
>2) Key rotation and backups
>Over time the number of keys quickly become
>prohibitive. 
>
Why? One key per user or group or file body. user and group keys unlock 
the file body key which is stored in the file metadata.

>You need to in stead store the "seed key
>and the dimension" of multi-dimension key space. The
>multi-dimension key space is actually several key
>spaces combined to make a higher dimensional key
>space. 
>The key space is created by sequencal encryption of
>the seed key inserted into dimension space controlled
>by a "secure" psedo-random walk. When a new key is
>required it is taken form the mult-dimensional key
>space as the next index number. Keys don't need to use
>all the deminsion in its index number. Which allows
>transition to new key spaces as old ones get filled.
>Or Remote sites which will ofcourse have different key
>spaces.
>
>At some point in the future a particular key is
>required, it is retrived by first regenating the key
>space, then using the key in the key space specified
>my the "particular" key's index number. There is no
>reason that the key's index number and key space
>"number" can not be stored in the clear, lets say in
>the file header.
>
>Using this method there is basically unlimited keys
>available, and they can be stored and retrived
>efficently.
>
>
>This is brief and incomplete.
>-tim
> 
>
>__________________________________
>Do you Yahoo!?
>SBC Yahoo! DSL - Now only $29.95 per month!
>http://sbc.yahoo.com
>
>
>  
>


-- 
Hans

Re: Several questions about encrypted filesystem

[Timothy Webster]

--- Hans Reiser <reiser@namesys.com> wrote:
> Timothy Webster wrote:
> 
> >2) Key rotation and backups
> >Over time the number of keys quickly become
> >prohibitive. 
> >
> Why? One key per user or group or file body. user
> and group keys unlock 
> the file body key which is stored in the file
> metadata.

This additional level of abstraction is a good
one and greatly reduces the total number of 
keys required. The key space is for user, 
group, master, acl "keys" which in turn unlock 
individual file body keys encrypted in the file 
metadata. The file body keys are session keys,
which may would change foreach encrypting writing
process. Or is this not what you had in mind?
Anyway, the user, group, master, acl "keys" need
to change quite often, perhaps once a day. The
idea is to keep handing out new keys as needed.
Or is your idea to retrive semi-perminate 
metadata keys from a PKI. Which ever approach
you take being able to construct a combined
key is very useful. See my other mail
"kool stuff". The number of key components
starts adding up very quickly even if you don't
change the metadata keys frequently.
10 yrs later with all these key combinations 
on lets say a mail server, you have far too 
many keys to individually remember. And thus 
the key space approach. 

-tim


> 
> >You need to in stead store the "seed key
> >and the dimension" of multi-dimension key space.
> The
> >multi-dimension key space is actually several key
> >spaces combined to make a higher dimensional key
> >space. 
> >The key space is created by sequencal encryption of
> >the seed key inserted into dimension space
> controlled
> >by a "secure" psedo-random walk. When a new key is
> >required it is taken form the mult-dimensional key
> >space as the next index number. Keys don't need to
> use
> >all the deminsion in its index number. Which allows
> >transition to new key spaces as old ones get
> filled.
> >Or Remote sites which will ofcourse have different
> key
> >spaces.
> >
> >At some point in the future a particular key is
> >required, it is retrived by first regenating the
> key
> >space, then using the key in the key space
> specified
> >my the "particular" key's index number. There is no
> >reason that the key's index number and key space
> >"number" can not be stored in the clear, lets say
> in
> >the file header.
> >
> >Using this method there is basically unlimited keys
> >available, and they can be stored and retrived
> >efficently.
> >


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: Several questions about encrypted filesystem

[Hans Reiser]

Timothy Webster wrote:

>--- Hans Reiser <reiser@namesys.com> wrote:
>  
>
>>Timothy Webster wrote:
>>
>>    
>>
>>>2) Key rotation and backups
>>>Over time the number of keys quickly become
>>>prohibitive. 
>>>
>>>      
>>>
>>Why? One key per user or group or file body. user
>>and group keys unlock 
>>the file body key which is stored in the file
>>metadata.
>>    
>>
>
>This additional level of abstraction is a good
>one and greatly reduces the total number of 
>keys required. The key space is for user, 
>group, master, acl "keys" which in turn unlock 
>individual file body keys encrypted in the file 
>metadata. The file body keys are session keys,
>which may would change foreach encrypting writing
>process. Or is this not what you had in mind?
>

By default, no.  There was someone who proposed granting write only 
permissions using a scheme in which keys change such that if you know 
the first key you can compute the later ones but the later ones don't 
allow you to compute the first ones, but this would not be the default 
encryption plugin.

>Anyway, the user, group, master, acl "keys" need
>to change quite often, perhaps once a day.
>
Why? 

> The
>idea is to keep handing out new keys as needed.
>Or is your idea to retrive semi-perminate 
>metadata keys from a PKI. Which ever approach
>you take being able to construct a combined
>key is very useful. See my other mail
>"kool stuff". The number of key components
>starts adding up very quickly even if you don't
>change the metadata keys frequently.
>10 yrs later with all these key combinations 
>on lets say a mail server, you have far too 
>many keys to individually remember. And thus 
>the key space approach. 
>
>-tim
>
>
>  
>
>>>You need to in stead store the "seed key
>>>and the dimension" of multi-dimension key space.
>>>      
>>>
>>The
>>    
>>
>>>multi-dimension key space is actually several key
>>>spaces combined to make a higher dimensional key
>>>space. 
>>>The key space is created by sequencal encryption of
>>>the seed key inserted into dimension space
>>>      
>>>
>>controlled
>>    
>>
>>>by a "secure" psedo-random walk. When a new key is
>>>required it is taken form the mult-dimensional key
>>>space as the next index number. Keys don't need to
>>>      
>>>
>>use
>>    
>>
>>>all the deminsion in its index number. Which allows
>>>transition to new key spaces as old ones get
>>>      
>>>
>>filled.
>>    
>>
>>>Or Remote sites which will ofcourse have different
>>>      
>>>
>>key
>>    
>>
>>>spaces.
>>>
>>>At some point in the future a particular key is
>>>required, it is retrived by first regenating the
>>>      
>>>
>>key
>>    
>>
>>>space, then using the key in the key space
>>>      
>>>
>>specified
>>    
>>
>>>my the "particular" key's index number. There is no
>>>reason that the key's index number and key space
>>>"number" can not be stored in the clear, lets say
>>>      
>>>
>>in
>>    
>>
>>>the file header.
>>>
>>>Using this method there is basically unlimited keys
>>>available, and they can be stored and retrived
>>>efficently.
>>>
>>>      
>>>
>
>
>__________________________________
>Do you Yahoo!?
>SBC Yahoo! DSL - Now only $29.95 per month!
>http://sbc.yahoo.com
>
>
>  
>


-- 
Hans

Re: Several questions about encrypted filesystem

[Timothy Webster]

--- Hans Reiser <reiser@namesys.com> wrote:
> Timothy Webster wrote:
> 
> >--- Hans Reiser <reiser@namesys.com> wrote:
> >  
> >
> >>Timothy Webster wrote:
> >>
> >>    
> >>
> >>>2) Key rotation and backups
> >>>Over time the number of keys quickly become
> >>>prohibitive. 
> >>>
> >>>      
> >>>
> >>Why? One key per user or group or file body. user
> >>and group keys unlock 
> >>the file body key which is stored in the file
> >>metadata.
> >>    
> >>
> >
> >This additional level of abstraction is a good
> >one and greatly reduces the total number of 
> >keys required. The key space is for user, 
> >group, master, acl "keys" which in turn unlock 
> >individual file body keys encrypted in the file 
> >metadata. The file body keys are session keys,
> >which may would change foreach encrypting writing
> >process. Or is this not what you had in mind?
> >
> 
> By default, no.  There was someone who proposed
> granting write only 
> permissions using a scheme in which keys change such
> that if you know 
> the first key you can compute the later ones but the
> later ones don't 
> allow you to compute the first ones, but this would
> not be the default 
> encryption plugin.
> 
> >Anyway, the user, group, master, acl "keys" need
> >to change quite often, perhaps once a day.
> >
> Why?

A new key every time a user is issued a 
new kerberos, ticket. The get a new key as
needed. Since these tickets are used for
encryption of file information, we can 
not simple use create and forget.

> 
> > The
> >idea is to keep handing out new keys as needed.
> >Or is your idea to retrive semi-perminate 
> >metadata keys from a PKI. Which ever approach
> >you take being able to construct a combined
> >key is very useful. See my other mail
> >"kool stuff". The number of key components
> >starts adding up very quickly even if you don't
> >change the metadata keys frequently.
> >10 yrs later with all these key combinations 
> >on lets say a mail server, you have far too 
> >many keys to individually remember. And thus 
> >the key space approach. 
> >

Actually, I don't like my answer. So let me 
try again. I think it is more of a question 
how do you want to manage your keys.

Are your users careless with keys. They
like to use them and lose them. And they
use their keys in lots of conversations
with some not so close friends. It is
better not to keep using this key.
I like to think of the key space approach
as my stuff stored in bus lockers all over
the place and I trust the bus company.
By the time I want to retrieve my stuff 
from one of the bus lockers, I have 
forgotten my key so I read off the 
box number and depot number. After 
proving my identity to the key clerk 
(who is verified by the key office), 
the clerk checks up my authorization. 
The authorization rules are in sealed
envelope attached to the locker. And
key clerks are authorized to unlock
these envelops. Finally if I am 
approved to recover the stuff in
that box, she cuts me a new key. I grab 
my stuff and run, leaving my key on
the street. No big deal there are very
few boxes it can open.
In Key space approach the key index
number and key space number is printed 
on the file metadata. And I use the
described key clear method to unlock
the metadata. Of course I would probably
not just leave the key laying around,
but I might try it on other file 
metadata. This handles the problem
of how to hand over some of your
files to another party, without
handing over all of your files.
You had not planed to hand over
these files when you created them.
Perhaps you did not even know this 
party. 


Or are your users carefull with keys
and dont' trust athorities. Then
your users are probably best sharing 
keys directly with their fiends. Who 
knows the secret police might ask 
the key clerk for their bus locker 
key. 
Then key spaces are definitely
NOT for you. Your users are much 
better off managing their own keys,
as trusting groups or individually.
But perhaps key spaces might how
they manage their keys. Do you
care, NOPE, because they are doing
the key management task.
I still think even in this case
it is a good idea to have the 
authorization rules separately
sealed but attached to the
metadata.

-tim.

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: Several questions about encrypted filesystem

[Timothy Webster]

Ops, the sealed authorization information
needs to be signed, but may not need to be
encrypted. This of course depends on the
security level encryption rules. 


--- Timothy Webster <tdwebste2@yahoo.com> wrote:
> 
> --- Hans Reiser <reiser@namesys.com> wrote:
> > Timothy Webster wrote:
> > 
> > >--- Hans Reiser <reiser@namesys.com> wrote:
> > >  
> > >
> > >>Timothy Webster wrote:
> > >>
> > >>    
> > >>
> > >>>2) Key rotation and backups
> > >>>Over time the number of keys quickly become
> > >>>prohibitive. 
> > >>>
> > >>>      
> > >>>
> > >>Why? One key per user or group or file body.
> user
> > >>and group keys unlock 
> > >>the file body key which is stored in the file
> > >>metadata.
> > >>    
> > >>
> > >
> > >This additional level of abstraction is a good
> > >one and greatly reduces the total number of 
> > >keys required. The key space is for user, 
> > >group, master, acl "keys" which in turn unlock 
> > >individual file body keys encrypted in the file 
> > >metadata. The file body keys are session keys,
> > >which may would change foreach encrypting writing
> > >process. Or is this not what you had in mind?
> > >
> > 
> > By default, no.  There was someone who proposed
> > granting write only 
> > permissions using a scheme in which keys change
> such
> > that if you know 
> > the first key you can compute the later ones but
> the
> > later ones don't 
> > allow you to compute the first ones, but this
> would
> > not be the default 
> > encryption plugin.
> > 
> > >Anyway, the user, group, master, acl "keys" need
> > >to change quite often, perhaps once a day.
> > >
> > Why?
> 
> A new key every time a user is issued a 
> new kerberos, ticket. The get a new key as
> needed. Since these tickets are used for
> encryption of file information, we can 
> not simple use create and forget.
> 
> > 
> > > The
> > >idea is to keep handing out new keys as needed.
> > >Or is your idea to retrive semi-perminate 
> > >metadata keys from a PKI. Which ever approach
> > >you take being able to construct a combined
> > >key is very useful. See my other mail
> > >"kool stuff". The number of key components
> > >starts adding up very quickly even if you don't
> > >change the metadata keys frequently.
> > >10 yrs later with all these key combinations 
> > >on lets say a mail server, you have far too 
> > >many keys to individually remember. And thus 
> > >the key space approach. 
> > >
> 
> Actually, I don't like my answer. So let me 
> try again. I think it is more of a question 
> how do you want to manage your keys.
> 
> Are your users careless with keys. They
> like to use them and lose them. And they
> use their keys in lots of conversations
> with some not so close friends. It is
> better not to keep using this key.
> I like to think of the key space approach
> as my stuff stored in bus lockers all over
> the place and I trust the bus company.
> By the time I want to retrieve my stuff 
> from one of the bus lockers, I have 
> forgotten my key so I read off the 
> box number and depot number. After 
> proving my identity to the key clerk 
> (who is verified by the key office), 
> the clerk checks up my authorization. 
> The authorization rules are in sealed
> envelope attached to the locker. And
> key clerks are authorized to unlock
> these envelops. Finally if I am 
> approved to recover the stuff in
> that box, she cuts me a new key. I grab 
> my stuff and run, leaving my key on
> the street. No big deal there are very
> few boxes it can open.
> In Key space approach the key index
> number and key space number is printed 
> on the file metadata. And I use the
> described key clear method to unlock
> the metadata. Of course I would probably
> not just leave the key laying around,
> but I might try it on other file 
> metadata. This handles the problem
> of how to hand over some of your
> files to another party, without
> handing over all of your files.
> You had not planed to hand over
> these files when you created them.
> Perhaps you did not even know this 
> party. 
> 
> 
> Or are your users carefull with keys
> and dont' trust athorities. Then
> your users are probably best sharing 
> keys directly with their fiends. Who 
> knows the secret police might ask 
> the key clerk for their bus locker 
> key. 
> Then key spaces are definitely
> NOT for you. Your users are much 
> better off managing their own keys,
> as trusting groups or individually.
> But perhaps key spaces might how
> they manage their keys. Do you
> care, NOPE, because they are doing
> the key management task.
> I still think even in this case
> it is a good idea to have the 
> authorization rules separately
> sealed but attached to the
> metadata.
> 
> -tim.
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com