Re: using a salt for encrypting blocks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux