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
prev parent 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 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.