From: Edward Shushkin <edward@namesys.com>
To: Heinz-Josef Claes <heinz-josef.claes@bundestag.de>
Cc: Hans Reiser <reiser@namesys.com>,
"Zhao, Forrest" <forrest.zhao@intel.com>,
reiserfs-list@namesys.com
Subject: Re: Several questions about encrypted filesystem
Date: Wed, 18 Jun 2003 19:20:29 +0400 [thread overview]
Message-ID: <3EF0833D.EF03FB90@namesys.com> (raw)
In-Reply-To: 1055921837.2026.25.camel@wusel.schnulli.de
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
next prev parent reply other threads:[~2003-06-18 15:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-17 2:14 Several questions about encrypted filesystem Zhao, Forrest
2003-06-17 11:41 ` Edward Shushkin
2003-06-17 16:02 ` Hans Reiser
2003-06-18 7:37 ` Heinz-Josef Claes
2003-06-18 15:20 ` Edward Shushkin [this message]
2003-06-19 6:01 ` Heinz-Josef Claes
2003-06-17 16:17 ` Timothy Webster
2003-06-17 17:22 ` Edward Shushkin
2003-06-18 2:06 ` Timothy Webster
2003-06-18 8:26 ` Hans Reiser
2003-06-18 9:44 ` Timothy Webster
2003-06-18 10:01 ` Hans Reiser
2003-06-18 15:12 ` Timothy Webster
2003-06-18 15:20 ` Timothy Webster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3EF0833D.EF03FB90@namesys.com \
--to=edward@namesys.com \
--cc=forrest.zhao@intel.com \
--cc=heinz-josef.claes@bundestag.de \
--cc=reiser@namesys.com \
--cc=reiserfs-list@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.