mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Grzegorz Kulewski <kangur@polcom.net>
To: "Guillaume Lacôte" <Guillaume@Lacote.name>
Cc: "Paulo Marques" <pmarques@grupopie.com>,
	"Jörn Engel" <joern@wohnheim.fh-wedel.de>,
	linux-kernel@vger.kernel.org, Linux@glacote.com
Subject: Re: Using compression before encryption in device-mapper
Date: Wed, 14 Apr 2004 16:39:42 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.58.0404141612250.16891@alpha.polcom.net> (raw)
In-Reply-To: <200404141602.43695.Guillaume@Lacote.name>

I think that not only compression should be moved to fs layer but 
possibly encryption also.

How?
In Reiser4 there are plugins.
In other fses (as far as I remember e2compr and maybe other posts on 
this list) there is only one bigger problem with compression and only if 
we want to support mmap (I do not remember more details about the problem) 
and the problem is somewhere between current mm and vfs implementation. I 
think that (probably) Linus said once that this problem can be solved by 
changing these implementations. The same probably goes for encryption.
In order to protect guessing the key from decrypting possibly-well-known 
values in superblock and other metadata (cuch as fs size and signature) we 
could probably place random numbers before them and xor each 4 bytes with 
last 4 bytes before encryption (or use any other hash function).

Why?
Because in dm approach you are encrypting entire blocks at once and in fs 
approach you are encrypting only needed parts. This can even bring more 
security because if fs is merging small files into one block and if it is 
patched to move begining of not full block data into random position in 
that block attacker must crack all fs and its metadata structures to know 
where your data actually is and what key is used to encrypt them (we can 
have several different keys for different parts of fs to make things 
harder). So we can have situation that in one block there is 2 or 3 or 
maybe more files (or parts) encrypted using different keys and hashes and 
that these files reside at different offsets in that block. I think that 
this is easier to implement and protects better.

What do you think?


Grzegorz Kulewski


  reply	other threads:[~2004-04-14 14:40 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-13 15:44 Guillaume Lacôte
2004-04-13 16:57 ` Timothy Miller
2004-04-14  6:48   ` Guillaume Lacôte
2004-04-13 17:45 ` Jörn Engel
2004-04-13 19:42   ` Ville Herva
2004-04-14  6:54   ` Guillaume Lacôte
2004-04-14  9:43     ` Jörn Engel
2004-04-14 10:02       ` Guillaume Lacôte
2004-04-14 11:25         ` Jörn Engel
2004-04-14 12:44         ` Paulo Marques
2004-04-14 13:34           ` Jörn Engel
2004-04-14 13:58           ` maccorin
2004-04-14 14:02           ` Guillaume Lacôte
2004-04-14 14:39             ` Grzegorz Kulewski [this message]
2004-04-14 15:07               ` Guillaume Lacôte
2004-04-14 16:14                 ` Grzegorz Kulewski
2004-04-14 15:23             ` Paulo Marques
2004-04-14 15:32               ` Guillaume Lacôte
2004-04-14 17:25           ` Bill Davidsen
2004-04-15  9:28 ` Jörn Engel
2004-04-22  7:59   ` Guillaume Lacôte
2004-04-22  9:18     ` Jörn Engel
2004-04-22 10:20       ` Guillaume Lacôte
2004-04-22 12:15         ` Jörn Engel
2004-04-22 13:06           ` Guillaume Lacôte
2004-04-22 16:00             ` Jörn Engel
2004-04-23 15:16               ` Guillaume Lacôte
2004-04-23 16:57                 ` Jörn Engel
     [not found] <1KykU-4VD-17@gated-at.bofh.it>
     [not found] ` <1KPvh-26S-7@gated-at.bofh.it>
     [not found]   ` <1KSMw-4P1-13@gated-at.bofh.it>
     [not found]     ` <1KTfJ-5gK-25@gated-at.bofh.it>
2004-04-14 15:02       ` Pascal Schmidt
2004-04-14 15:25         ` Guillaume Lacôte
2004-04-14 19:29           ` Pascal Schmidt

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=Pine.LNX.4.58.0404141612250.16891@alpha.polcom.net \
    --to=kangur@polcom.net \
    --cc=Guillaume@Lacote.name \
    --cc=Linux@glacote.com \
    --cc=joern@wohnheim.fh-wedel.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmarques@grupopie.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®