From: Milan Broz <mbroz@redhat.com>
To: octane indice <octane@alinto.com>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] using a salt for encrypting blocks
Date: Tue, 28 Dec 2010 20:49:02 +0100 [thread overview]
Message-ID: <4D1A3F2E.8040505@redhat.com> (raw)
In-Reply-To: <1293545117.4d19ee9d718e5@www.inmano.com>
On 12/28/2010 03:05 PM, octane indice wrote:
>> If an attacker has such access nothing will help you.
>> The chain is weaker somewhere else here.
>>
> I hope I took care all of these problems.
Good luck. Do you know how easy is to use hw keylogger for example?
How do you detect that attacker installed such hw device when
he has repeated access to the system?
TPM will not help here.
(Btw read what truecrypt developers say about TPM - see FAQ there.)
>> Then use encryption on filesystem level (e.g. with CTR mode,
>> iow stream mode) and not sector level block device encryption.
>>
> I'm not sure I understand (??) A stream mode would help? With filesystem
> level encryption? But maybe it's not the right mailing list if the talk goes
> that way.
That was just an example - why do you want to invent something new?
I meant if you want to reencrypt everything why not do that
(either use using stream mode with some salt or with completely new key)
on the file level directly?
You cannot fix block level encryption to not leak info which block changed
without completely destroying performance.
The block device must be transparent to the system and also you do not
want to kill cache and hw acceleration here.
What is possible is to provide on-the-fly master key change and simply
reencrypt the whole device on-fly when needed.
You can implement is such way, that it will survive even unexpected power fail.
LVM has similar concept for pvmove - moved (here reencrypted) area is mirrored,
when mirror is synchronised, it will switch to final destination.
For encryption here you then need some temporary area and after switch
to destination area add wipe of old area with random data.
If power fails, it will simple start resyncing again (so for some
time both keys are active). Of course this also handle all IO requests
to the storage during reencryption.
So if this is what you want - yes, I would like to see some such functionality,
but this is work for LVM, not dmcrypt.
Milan
next prev parent reply other threads:[~2010-12-28 19:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-27 16:10 [dm-crypt] using a salt for encrypting blocks octane indice
2010-12-27 21:52 ` Arno Wagner
2010-12-28 8:29 ` octane indice
2010-12-28 11:03 ` Milan Broz
2010-12-28 14:05 ` octane indice
2010-12-28 19:49 ` Milan Broz [this message]
2010-12-30 10:11 ` octane indice
2010-12-30 12:27 ` Arno Wagner
2010-12-28 13:32 ` Arno Wagner
2010-12-28 14:23 ` octane indice
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=4D1A3F2E.8040505@redhat.com \
--to=mbroz@redhat.com \
--cc=dm-crypt@saout.de \
--cc=octane@alinto.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.