Re: Advice on encrypted filesystem
On Fri 26 Jun 2020 at 11:47:34 (-0400), Michael Stone wrote:
> On Fri, Jun 26, 2020 at 08:25:49AM -0500, David Wright wrote:
> > If encrypting an entire disk, scramble the disk first, then partition.
> > If only encrypting a partition, partition the disk first.
> > Alignments should be at least 2M (4096 x 512B sectors).
> > Scramble any sensitive pre-existing contents:
> >
> > # dd bs=1M if=/dev/urandom of=/dev/sdz[9]
>
> I personally wouldn't do this. It's slow and doesn't gain much.
As I posted in https://lists.debian.org/debian-user/2020/06/msg01109.html
I get about 75% speed from /dev/urandom compared with /dev/zero (as
suggested by your good self, except that I'm writing directly to
/dev/sdXN, not to an encrypted device, which would itself be slower).
> I
> definitely wouldn't do it on an SSD.
Agreed. But I wouldn't be writing any sensitive information to an SSD
in the first place without encrypting it. (Not that I own any yet.)
> > # cryptsetup --align-payload 2048 luksFormat /dev/sdz9
>
> I also would not add this align-payload option. (If you don't,
> cryptsetup will query the kernel for optimal parameters.)
You're right, but the problem comes when the kernel feeds LUKS a value
that it isn't designed to handle correctly. As elsewhere on my systems,
I tend to gravitate towards recipes/solutions that I can use across
all of them, rather than having to deal with lots of exceptions.
In this case, it's the "Optimal transfer size" which catches it out,
when the commonly occurring value of 33553920 bytes is received.
In plain speaking, that's 512*(2**16-1); which might be fine for
the kernel transferring over USB with 32MB buffers, but unfortunately
isn't actually divisible by 2048.
Cheers,
David.
Reply to: