DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Milan Broz <mbroz@redhat.com>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.4.0-rc1 (test release candidate)
Date: Mon, 10 Oct 2011 22:22:37 +0200	[thread overview]
Message-ID: <4E93540D.3000608@redhat.com> (raw)
In-Reply-To: <20111010200327.GA7357@tansi.org>

On 10/10/2011 10:03 PM, Arno Wagner wrote:
>> * If device is not rotational disk, cryptsetup no longer tries
>>   to wipe keyslot with Gutmann algorithm for magnetic media erase
>>   but simply rewrites area once by random data.
> 
> Hmm. How do you determine that? Not that I see any fundamental
> problem,

Through kernel sysfs, rotational flag:
/sys/dev/block/<major>:<minor>/queue/rotational

If not available, then it is expected that device is rotational.

(This flag should be authoritative, e.g. filesystems like btrfs uses it
as well to determine allocation strategies.)

>>    WARNING: There is no possible check that specified ciphertext device
>>             matches detached on-disk header. Use with care, it can destroy
>>             your data in case of a mistake.
> 
> It should refuse to mount though, just like a plain dm-crypt
> device if you enter the wrong passphrase.

yes. I just want to say that by separating header user is responsible
to proper pair header and ciphertext device.
 
>>    WARNING: Storing LUKS header in a file means that anti-forensic splitter
>>             cannot properly work (there is filesystem allocation layer between
>>             header and disk).
> 
> You mean the splitted data may end up all over the disk making
> wiping problematic, especially if the filesystem does "overwrites" 
> to different places?

You cannot be sure how is the file represented on disk, it can be fragmented
etc. (AF has perhaps problems with SSD wear-leveling so it is nothing new.
We should analyse AF with new storage types anyway...)

Anyway, header in file is exactly as the same situation as header backup to file.

In fact, I forgot to mention that header backup can be directly used
in --header parameter.

>> * Enhance check of device size before writing LUKS header.
> 
> To prevent problems if the device is smaller than the header?

Old code did not checked if header + all keyslots fit on device 
(but device activation was not possible because payload offset
exceeded device size then).

But now with separate header it is needed - header write is refused
if device is too small.

Milan

      reply	other threads:[~2011-10-10 20:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-10 19:25 [dm-crypt] [ANNOUNCE] cryptsetup 1.4.0-rc1 (test release candidate) Milan Broz
2011-10-10 20:03 ` Arno Wagner
2011-10-10 20:22   ` Milan Broz [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=4E93540D.3000608@redhat.com \
    --to=mbroz@redhat.com \
    --cc=dm-crypt@saout.de \
    /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