public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dale Amon <amon@vnl.com>
To: "David L. Nicol" <david@kasey.umkc.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Idea: Encryption plugin architecture for file-systems
Date: Tue, 24 Apr 2001 17:08:12 +0100	[thread overview]
Message-ID: <20010424170812.B28404@vnl.com> (raw)
In-Reply-To: <NFBBIDPOFIIFCBDDFGLEGEMICCAA.nagytam@rerecognition.com> <01042121404701.08246@antares> <20010423211237.I26083@vnl.com> <3AE4EAEA.26F37BEB@kasey.umkc.edu>
In-Reply-To: <3AE4EAEA.26F37BEB@kasey.umkc.edu>; from david@kasey.umkc.edu on Mon, Apr 23, 2001 at 09:54:34PM -0500

On Mon, Apr 23, 2001 at 09:54:34PM -0500, David L. Nicol wrote:
> why not port one of the twenty or thirty preexisting tools
> that let you mount a filesystem from an encrypted file instead
> of making a generic layer?  That way you could have inter-os 
> portability.  The steganographic ones make really impressive
> claims.  

I'm doing an 18GB raid file system. The standard loopback is
working fine. What I am unsure of is the bobustness against lost
blocks when running "on the metal" vs interposing another file
system layer.

I suspect the answer is that each block is individually encrypted,
so that the worst case data loss is the same; that an ext2 on
top of an encrypted partition would be no worse off than the 
same file system without the interposed layer. Both would find
a bad block and do their best.

But my knowledge of how the loopbacks are structured is not
good enough for me to say this with confidence. That's why 
I'm asking here: in hopes that someone who really does know
can say something about the worst case data loses.

-- 
------------------------------------------------------
Use Linux: A computer        Dale Amon, CEO/MD
is a terrible thing          Village Networking Ltd
to waste.                    Belfast, Northern Ireland
------------------------------------------------------

      reply	other threads:[~2001-04-24 16:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-21 18:52 Idea: Encryption plugin architecture for file-systems Tamas Nagy
2001-04-21 19:10 ` Ian Stirling
2001-04-21 19:11 ` Alistair Riddell
2001-04-21 19:13 ` Bart Trojanowski
2001-04-21 19:21 ` Peter Makholm
2001-04-21 19:37   ` Andi Kleen
2001-04-21 20:26     ` Herbert Valerio Riedel
2001-04-21 22:50     ` Dan Hollis
2001-04-21 22:49   ` Dan Hollis
2001-04-22  9:42     ` Olaf Titz
2001-04-21 19:40 ` Stefan Jaschke
2001-04-23 20:12   ` Dale Amon
2001-04-24  2:54     ` David L. Nicol
2001-04-24 16:08       ` Dale Amon [this message]

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=20010424170812.B28404@vnl.com \
    --to=amon@vnl.com \
    --cc=david@kasey.umkc.edu \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox