Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #224077

Re: Advice on encrypted filesystem

From David Wright <deblis@lionunicorn.co.uk>
Newsgroups linux.debian.user
Subject Re: Advice on encrypted filesystem
Date 2020-06-27 03:30 +0200
Message-ID <Am7Pj-4K4-1@gated-at.bofh.it> (permalink)
References (2 earlier) <Alyyd-8qd-5@gated-at.bofh.it> <AlWAx-6p8-5@gated-at.bofh.it> <AlYM2-7Eu-11@gated-at.bofh.it> <Am1TA-1h3-5@gated-at.bofh.it> <Am2wh-1tR-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri 26 Jun 2020 at 15:45:09 (-0400), Michael Stone wrote:
> On Fri, Jun 26, 2020 at 02:06:57PM -0500, David Wright wrote:
> > 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.)
> 
> SSDs are more common than not in new computers so it's probably best
> to assume that people reading stuff like this might be trying to apply
> it to an SSD.

Fair enough. No doubt when I acquire one, it'll enter my notes if need
be. There's still the problem of what one does about sensitive data if
one has been rash enough to write it unencrypted onto an SSD. Would
shred -n 1   be preferable? Not really, because that doesn't hit the
ex-file areas. What then?

> > > > # 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.
> 
> Well, the problem is that magic numbers get cargo culted without
> knowing why they are there or whether they're the right number, and
> eventually they aren't.
> 
> Per the manual:
> WARNING: This option is DEPRECATED and has often unexpected impact to
> the data offset and keyslot area size (for LUKS2) due to the complex
> rounding.
> 
> The best option IMO (especially for crypto related stuff) is to stick
> with the defaults and deal with exceptions if they come up rather than
> blindly carry forward things that were once necessary on some
> configuration sometime. If you want to be complete you might reference
> a past issue so someone can deal with it if it arises, but it
> shouldn't be the starting point.

Ironically, 2048 is neither cargo cult nor magic, but *is* the default
used by LUKS when the kernel does not supply one, as documented two
paragraphs earlier. Are you suggesting a 1MB alignment might be
insufficient? If one were to specify NxMB, LUKS will still use 1MB
(again as documented).

I don't know about completeness: I wrote that my post was taken "from
my notes". As for a starting point, I left 24 hours after the OP
posted clarifications for others to respond with their own recipes.
I haven't noticed any yet.¹

> > 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.
> 
> In this case, the kernel was updated to ignore transfer sizes which
> aren't a multiple of the drive's physical sector size because some
> drives were reporting seemingly bogus values. Hardcoding a workaround
> for older kernels means not taking advantage of the fix on newer
> kernels.

Apologies for not asking the OP which kernel version they were running
in their jessie. The 3.16 kernel on my one remaining jessie system
doesn't have this patch (sd_validate_opt_xfer_size).

¹BTW when I first posted the symptoms caused by this problem, there
were no responses in five months.

Cheers,
David.

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Advice on encrypted filesystem rhkramer@gmail.com - 2020-06-25 03:30 +0200
  Re: Advice on encrypted filesystem Roberto C. Sánchez <roberto@debian.org> - 2020-06-25 03:40 +0200
    Re: Advice on encrypted filesystem David Christensen <dpchrist@holgerdanske.com> - 2020-06-25 04:20 +0200
    Re: Advice on encrypted filesystem john doe <johndoe65534@mail.com> - 2020-06-25 09:50 +0200
    Re: Advice on encrypted filesystem rhkramer@gmail.com - 2020-06-25 13:40 +0200
      Re: Advice on encrypted filesystem David <bouncingcats@gmail.com> - 2020-06-25 15:30 +0200
        Re: Advice on encrypted filesystem Nicolas George <george@nsup.org> - 2020-06-25 15:40 +0200
          Sound in Jitsi/BBB [was: dvice on encrypted filesystem] <tomas@tuxteam.de> - 2020-06-25 16:00 +0200
            Re: Sound in Jitsi/BBB [was: dvice on encrypted filesystem] Nicolas George <george@nsup.org> - 2020-06-25 16:00 +0200
              Re: Sound in Jitsi/BBB [was: dvice on encrypted filesystem] <tomas@tuxteam.de> - 2020-06-25 16:10 +0200
        Zoom client for Linux (was: Re: Advice on encrypted filesystem) rhkramer@gmail.com - 2020-06-25 16:20 +0200
      Re: Advice on encrypted filesystem rhkramer@gmail.com - 2020-06-25 16:30 +0200
  Re: Advice on encrypted filesystem David Wright <deblis@lionunicorn.co.uk> - 2020-06-25 04:30 +0200
    Re: Advice on encrypted filesystem rhkramer@gmail.com - 2020-06-25 13:50 +0200
      Re: Advice on encrypted filesystem David Wright <deblis@lionunicorn.co.uk> - 2020-06-26 15:30 +0200
        Re: Advice on encrypted filesystem rhkramer@gmail.com - 2020-06-26 16:40 +0200
        Re: Advice on encrypted filesystem Michael Stone <mstone@debian.org> - 2020-06-26 17:50 +0200
          Re: Advice on encrypted filesystem David Wright <deblis@lionunicorn.co.uk> - 2020-06-26 21:10 +0200
            Re: Advice on encrypted filesystem Michael Stone <mstone@debian.org> - 2020-06-26 21:50 +0200
              Re: Advice on encrypted filesystem David Wright <deblis@lionunicorn.co.uk> - 2020-06-27 03:30 +0200
                Re: Advice on encrypted filesystem David Christensen <dpchrist@holgerdanske.com> - 2020-06-27 06:10 +0200
                Re: Advice on encrypted filesystem David Christensen <dpchrist@holgerdanske.com> - 2020-06-27 09:10 +0200
                Re: Advice on encrypted filesystem Admin4 <admin4@dwaves.de> - 2020-06-27 10:10 +0200
                Re: Advice on encrypted filesystem David Christensen <dpchrist@holgerdanske.com> - 2020-06-27 21:50 +0200
                Re: Advice on encrypted filesystem David Christensen <dpchrist@holgerdanske.com> - 2020-06-27 22:20 +0200
                Re: Advice on encrypted filesystem Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-27 10:50 +0200
                Re: Advice on encrypted filesystem David Christensen <dpchrist@holgerdanske.com> - 2020-06-27 23:30 +0200

csiph-web