From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: Re: Several questions about encrypted filesystem Date: Wed, 18 Jun 2003 12:26:59 +0400 Message-ID: <3EF02253.2070903@namesys.com> References: <20030617161725.17287.qmail@web80507.mail.yahoo.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <20030617161725.17287.qmail@web80507.mail.yahoo.com> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: tdwebste2@yahoo.com Cc: Edward Shushkin , "Zhao, Forrest" , reiserfs-list@namesys.com 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