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

Groups > linux.debian.user > #223973 > unrolled thread

Advice on encrypted filesystem

Back to article view | Back to linux.debian.user

Contents

  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

Page 1 of 2  [1] 2  Next page →

#223973 — Advice on encrypted filesystem

On my Wheezy system, I used cryptsetup to set up a LUKs  encrypted file system 
on a dedicated partition (actually, two filesystems).

It was a PITA learning how to do it, and it was 6 years ago, and it looks like 
I have to relearn it to do it again on Jessie and / or Buster (and on a backup 
device).  (I have my "stream of consciousness" notes from when I did it back 
then, but there were so many false starts / blind paths that the notes are 
very confusing.)

I'm wondering if cryptsetup is still something like "state of the art" or if 
there is anything more secure and simpler to learn to setup?

[toc] | [next] | [standalone]

#223974

On Wed, Jun 24, 2020 at 09:28:38PM -0400, rhkramer@gmail.com wrote:
> On my Wheezy system, I used cryptsetup to set up a LUKs  encrypted file system 
> on a dedicated partition (actually, two filesystems).
> 
> It was a PITA learning how to do it, and it was 6 years ago, and it looks like 
> I have to relearn it to do it again on Jessie and / or Buster (and on a backup 
> device).  (I have my "stream of consciousness" notes from when I did it back 
> then, but there were so many false starts / blind paths that the notes are 
> very confusing.)
> 
> I'm wondering if cryptsetup is still something like "state of the art" or if 
> there is anything more secure and simpler to learn to setup?
> 

Assuming you are considering a new installation, which you seem to have
implied, then you should probably just try the Debian Installer.  The
support for installing to an encrypted partition has improved
considerably with each installer release.  The last time I did it with a
Buster installer it was not even necessary to consult my notes.

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#223975

On 2020-06-24 18:34, Roberto C. Sánchez wrote:
> On Wed, Jun 24, 2020 at 09:28:38PM -0400, rhkramer@gmail.com wrote:
>> On my Wheezy system, I used cryptsetup to set up a LUKs  encrypted file system
>> on a dedicated partition (actually, two filesystems).
>>
>> It was a PITA learning how to do it, and it was 6 years ago, and it looks like
>> I have to relearn it to do it again on Jessie and / or Buster (and on a backup
>> device).  (I have my "stream of consciousness" notes from when I did it back
>> then, but there were so many false starts / blind paths that the notes are
>> very confusing.)
>>
>> I'm wondering if cryptsetup is still something like "state of the art" or if
>> there is anything more secure and simpler to learn to setup?
>>
> 
> Assuming you are considering a new installation, which you seem to have
> implied, then you should probably just try the Debian Installer.  The
> support for installing to an encrypted partition has improved
> considerably with each installer release.  The last time I did it with a
> Buster installer it was not even necessary to consult my notes.

+1


Running cryptsetup(8) by hand is not very hard.  The challenge is 
deciding how to fit encryption into everything else -- passphrases, 
keys, boot, devices, partitioning, md RAID, LVM, file systems, ZFS, 
etc..  Post your requirements and people can guide you.


David

[toc] | [prev] | [next] | [standalone]

#223988

On 6/25/2020 3:34 AM, Roberto C. Sánchez wrote:
> On Wed, Jun 24, 2020 at 09:28:38PM -0400, rhkramer@gmail.com wrote:
>> On my Wheezy system, I used cryptsetup to set up a LUKs  encrypted file system
>> on a dedicated partition (actually, two filesystems).
>>
>> It was a PITA learning how to do it, and it was 6 years ago, and it looks like
>> I have to relearn it to do it again on Jessie and / or Buster (and on a backup
>> device).  (I have my "stream of consciousness" notes from when I did it back
>> then, but there were so many false starts / blind paths that the notes are
>> very confusing.)
>>
>> I'm wondering if cryptsetup is still something like "state of the art" or if
>> there is anything more secure and simpler to learn to setup?
>>
>
> Assuming you are considering a new installation, which you seem to have
> implied, then you should probably just try the Debian Installer.  The
> support for installing to an encrypted partition has improved
> considerably with each installer release.  The last time I did it with a
> Buster installer it was not even necessary to consult my notes.
>

+1, encrypting the boot partition is not that dificult either.

--
John Doe

[toc] | [prev] | [next] | [standalone]

#224004

On Wednesday, June 24, 2020 09:34:00 PM Roberto C. Sánchez wrote:
> On Wed, Jun 24, 2020 at 09:28:38PM -0400, rhkramer@gmail.com wrote:
> > I'm wondering if cryptsetup is still something like "state of the art" or
> > if there is anything more secure and simpler to learn to setup?
> 
> Assuming you are considering a new installation, which you seem to have
> implied, 

Ahh, yes, I screwed up -- I certainly did imply that, but both the Jessie and 
the Buster system are already installed and being used, I would not want to 
reinstall the Jessie system, I might consider reinstalling the Buster system, 
I might even replace it with testing as, for some purposes, I need a Firefox 
more up-to-date than that in Buster.   

(I tried to join a Zoom meeting and could not get sound, I got a message that 
my Firefox was not new enough.)

At least for the Jessie system, I'd like to install some encrypted filesystems 
without reinstalling (or replacing) Jessie.



> then you should probably just try the Debian Installer.  The
> support for installing to an encrypted partition has improved
> considerably with each installer release.  The last time I did it with a
> Buster installer it was not even necessary to consult my notes.

[toc] | [prev] | [next] | [standalone]

#224009

On Thu, 25 Jun 2020 at 21:30, <rhkramer@gmail.com> wrote:

> I might consider reinstalling the Buster system,
> I might even replace it with testing as, for some purposes, I need a Firefox
> more up-to-date than that in Buster.
>
> (I tried to join a Zoom meeting and could not get sound, I got a message that
> my Firefox was not new enough.)

Hi, are you aware that Zoom has available a Linux-compatible
desktop client application that runs without a browser?

It works on Buster, apart from needing to be told which audio
device to use every time it is run.
Available here:
https://zoom.us/download#client_4meeting

[toc] | [prev] | [next] | [standalone]

#224011

[Multipart message — attachments visible in raw view] — view raw

David (12020-06-25):
> Hi, are you aware that Zoom has available a Linux-compatible
> desktop client application that runs without a browser?
> 
> It works on Buster, apart from needing to be told which audio
> device to use every time it is run.
> Available here:
> https://zoom.us/download#client_4meeting

Note that running untrustworthy proprietary software directly on your
own system is significantly more risky than running it in the sandbox of
a web browser.

Installing it as a package with root privileges is even riskier. This
one does not seem to sneakily alter sources.list to add its own
repository, which is even worse, but better use the generic tarball as a
separate user.

Anyway, I never used Zoom, but with Jitsi and Big Blue Button, I had no
sound either with Firefox, but it worked with Chromium.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#224013 — Sound in Jitsi/BBB [was: dvice on encrypted filesystem]

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jun 25, 2020 at 03:34:02PM +0200, Nicolas George wrote:
> David (12020-06-25):
> > Hi, are you aware that Zoom has available a Linux-compatible
> > desktop client application that runs without a browser?
> > 
> > It works on Buster, apart from needing to be told which audio
> > device to use every time it is run.
> > Available here:
> > https://zoom.us/download#client_4meeting
> 
> Note that running untrustworthy proprietary software directly on your
> own system is significantly more risky than running it in the sandbox of
> a web browser.

100% agree.

[...]

> Anyway, I never used Zoom, but with Jitsi and Big Blue Button, I had no
> sound either with Firefox, but it worked with Chromium.

You don't use Pulseaudio? Current Firefoxen have ALSA enabled for Debian,
but their ALSA support seems to have fallen prey to bitrot. I didn't
manage to get them working.

If you insist in not having Pulse (I do), there's apulse (the package
is named likewise, I think). It plays LD_PRELOAD tricks to trick FF
into believing it's talking to Pulseaudio. I had success with that.

Cheers
-- tomás

[toc] | [prev] | [next] | [standalone]

#224014 — Re: Sound in Jitsi/BBB [was: dvice on encrypted filesystem]

[Multipart message — attachments visible in raw view] — view raw

tomas@tuxteam.de (12020-06-25):
> You don't use Pulseaudio? Current Firefoxen have ALSA enabled for Debian,
> but their ALSA support seems to have fallen prey to bitrot. I didn't
> manage to get them working.
> 
> If you insist in not having Pulse (I do), there's apulse (the package
> is named likewise, I think). It plays LD_PRELOAD tricks to trick FF
> into believing it's talking to Pulseaudio. I had success with that.

I use apulse, and Firefox is capable of producing sound on some sites (I
do not know why I bother to get it working: I do NOT want my web browser
to produce sound!). The microphone is the issue.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#224015 — Re: Sound in Jitsi/BBB [was: dvice on encrypted filesystem]

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jun 25, 2020 at 03:57:53PM +0200, Nicolas George wrote:
> tomas@tuxteam.de (12020-06-25):
> > You don't use Pulseaudio? Current Firefoxen have ALSA enabled for Debian,
> > but their ALSA support seems to have fallen prey to bitrot. I didn't
> > manage to get them working.
> > 
> > If you insist in not having Pulse (I do), there's apulse (the package
> > is named likewise, I think). It plays LD_PRELOAD tricks to trick FF
> > into believing it's talking to Pulseaudio. I had success with that.
> 
> I use apulse, and Firefox is capable of producing sound on some sites (I
> do not know why I bother to get it working: I do NOT want my web browser
> to produce sound!). The microphone is the issue.

Sound wasn't the problem for me. Microphone was.

FWIW, I also detest the browser making noises -- but lockdown and things.
And seeing people swarming to Zoom gave me the rest.

I had both Jitsi and BBB, and micro worked (via apulse) with both. It
took me some fiddling with amixer/alsamixer, though.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#224016 — Zoom client for Linux (was: Re: Advice on encrypted filesystem)

On Thursday, June 25, 2020 09:25:06 AM David wrote:
> Hi, are you aware that Zoom has available a Linux-compatible
> desktop client application that runs without a browser?

Thanks, yes, that is one of the ways I tried to join the zoom meeting on my 
Jessie system -- the client says it requires / works with Debian 8.0 (i.e., 
Jessie) but I might also try it on Buster.

I do have a followup question after the aside.

(aside: long story slightly shortened>

I have a zoom client on my Wheezy system, some 3.nn version, but the meeting I 
tried to join said I needed version 5.nn, which apparently cannot be installed 
on Wheezy.

I tried joining the meeting with both the Linux client and Firefox, both gave 
me video but neither gave me sound.

At some point I'll try Chromium (I think zoom has a test meeting that I can 
join to try out)

(/aside: long story slightly shortened>

> It works on Buster, apart from needing to be told which audio
> device to use every time it is run.

Can you give me any clues about how you told it which audio device to use (and 
which you told it to use)?

> Available here:
> https://zoom.us/download#client_4meeting

[toc] | [prev] | [next] | [standalone]

#224017

On Thursday, June 25, 2020 07:29:53 AM rhkramer@gmail.com wrote:
> At least for the Jessie system, I'd like to install some encrypted
> filesystems without reinstalling (or replacing) Jessie.

Does anybody know what the DI (Debian Installer) installs by default for an 
encrypted filesystem on Jessie and Buster?

Is that / are those fairly easy to setup after the install?

[toc] | [prev] | [next] | [standalone]

#223976

On Wed 24 Jun 2020 at 21:28:38 (-0400), rhkramer@gmail.com wrote:
> On my Wheezy system, I used cryptsetup to set up a LUKs  encrypted file system 
> on a dedicated partition

What were the contents of this partition: the OS itself, or /home,
or an independent filesystem that you'd probably mount under /media?
Same this time around?

> (actually, two filesystems).

Do you mean you did this twice, or what?

> It was a PITA learning how to do it, and it was 6 years ago, and it looks like 
> I have to relearn it to do it again on Jessie and / or Buster (and on a backup 
> device).  (I have my "stream of consciousness" notes from when I did it back 
> then, but there were so many false starts / blind paths that the notes are 
> very confusing.)

Laptops? Do you use suspend? Desktops? Do you boot them remotely?

> I'm wondering if cryptsetup is still something like "state of the art" or if 
> there is anything more secure and simpler to learn to setup?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#224005

On Wednesday, June 24, 2020 10:20:55 PM David Wright wrote:
> On Wed 24 Jun 2020 at 21:28:38 (-0400), rhkramer@gmail.com wrote:
> > On my Wheezy system, I used cryptsetup to set up a LUKs  encrypted file
> > system on a dedicated partition
> 
> What were the contents of this partition: the OS itself, or /home,
> or an independent filesystem that you'd probably mount under /media?

an independent filesystem mounted as a top level directory

> Same this time around?

yes

> > (actually, two filesystems).
> 
> Do you mean you did this twice, or what?

Hm, I can elaborate a little: I have one filesystem / partition for my very 
sensitive private data, and a second to back that stuff up.

(I have some scripts to allow me to easily open (and close) those filesystems 
-- when they open, the unencrypted content is put on a ramdisk (with the 
intent if somebody gets physical possession of the device (which is a desktop, 
not a laptop), the enencrypted data disappears on power off.) 
 
> 
> Laptops? 

Well, the Buster system is a laptop, Jessie is a desktop.  I don't plan to put 
much, if any, sensitive data on the laptop.  (I don't really even intend to 
take the laptop out of the house, especially during this Covid thing -- I 
installed Buster on it because I needed GCC 7+ and couldn't (easily) do that 
on the Wheezy or Jessie systems.

> Do you use suspend? 

No.

> Desktops? 

See above.

> Do you boot them remotely?

No, but they do stay up 24/7 unless there is a (longer that 2 minute (power is 
UPS supported)) power outage, or a (very rare) reboot.

[toc] | [prev] | [next] | [standalone]

#224039

On Thu 25 Jun 2020 at 07:40:43 (-0400), rhkramer@gmail.com wrote:
> On Wednesday, June 24, 2020 10:20:55 PM David Wright wrote:
> > On Wed 24 Jun 2020 at 21:28:38 (-0400), rhkramer@gmail.com wrote:
> > > On my Wheezy system, I used cryptsetup to set up a LUKs  encrypted file
> > > system on a dedicated partition
> > 
> > What were the contents of this partition: the OS itself, or /home,
> > or an independent filesystem that you'd probably mount under /media?
> 
> an independent filesystem mounted as a top level directory

Then I can't see any point in involving the Debian installer.
Some of the details depend on what scripts you use to unlock
and mount. My own method for creating a filesystem is
(from my notes):

--✄----

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]

Partitioning is conventional.

# gdisk /dev/sdz

[… etc …]

Creating the encrypted partition.

# cryptsetup --align-payload 2048 luksFormat /dev/sdz9

WARNING!
========
This will overwrite data on /dev/sdb1 irrevocably.

[… etc …]

Add more passphrases:

# cryptsetup luksAddKey /dev/sdz9

[… etc …]

Create the filesystem:

# cryptsetup open --type luks /dev/sdz9 thename

# mkfs.ext4 -L name09 /dev/mapper/thename

[… etc …]

# e2label /dev/mapper/thename name09 (if forgotten above).

Finally:

# cryptsetup luksClose thename

--✄----

(I mangle the device names to make copy/paste less dangerous.)

> (I have some scripts to allow me to easily open (and close) those filesystems 
> -- when they open, the unencrypted content is put on a ramdisk (with the 
> intent if somebody gets physical possession of the device (which is a desktop, 
> not a laptop), the enencrypted data disappears on power off.) 

As I encrypt /home, it wouldn't make sense for me to copy it all.
I assume that nobody's going to freeze my PC when they steal it.

My scripts use LABELled filesystems (as seen above), so there's nothing
unusual about /etc/fstab; and I unlock with udisksctl, using the
/dev/disk/by-partlabel value, so there's no entry in /etc/crypttab.

> Well, the Buster system is a laptop, Jessie is a desktop.  I don't plan to put 
> much, if any, sensitive data on the laptop.  (I don't really even intend to 
> take the laptop out of the house, especially during this Covid thing -- I 
> installed Buster on it because I needed GCC 7+ and couldn't (easily) do that 
> on the Wheezy or Jessie systems.
> 
> > Do you use suspend? 
> 
> No.

Then you could encrypt swap with a random key. My method for that
is unusual, in that the swap partition is specified in fstab by
its (tiny) filesystem's LABEL. Its /etc/crypttab is thus fixed:

swap	LABEL=cryptswap	/dev/urandom	swap,offset=2048,cipher=aes-xts-plain64,size=512

> > Desktops? 
> 
> See above.
> 
> > Do you boot them remotely?
> 
> No, but they do stay up 24/7 unless there is a (longer that 2 minute (power is 
> UPS supported)) power outage, or a (very rare) reboot.

OK. This only really matters if you're encrypting /home (as I do)
or the system itself, as you then need a method of supplying the
passphrase before any users can login. (I use a pseudo-user whose
~ is in /var/local/home/ with a crafted .bash_profile.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#224042

Thanks -- very helpful!  I mayb have some more questions as I triy to digest 
this, but can't spend time on it today.

Nothing new below this line.

On Friday, June 26, 2020 09:25:49 AM David Wright wrote:
> On Thu 25 Jun 2020 at 07:40:43 (-0400), rhkramer@gmail.com wrote:
> > On Wednesday, June 24, 2020 10:20:55 PM David Wright wrote:
> > > On Wed 24 Jun 2020 at 21:28:38 (-0400), rhkramer@gmail.com wrote:
> > > > On my Wheezy system, I used cryptsetup to set up a LUKs  encrypted
> > > > file system on a dedicated partition
> > > 
> > > What were the contents of this partition: the OS itself, or /home,
> > > or an independent filesystem that you'd probably mount under /media?
> > 
> > an independent filesystem mounted as a top level directory
> 
> Then I can't see any point in involving the Debian installer.
> Some of the details depend on what scripts you use to unlock
> and mount. My own method for creating a filesystem is
> (from my notes):
> 
> --✄----
> 
> 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]
> 
> Partitioning is conventional.
> 
> # gdisk /dev/sdz
> 
> [… etc …]
> 
> Creating the encrypted partition.
> 
> # cryptsetup --align-payload 2048 luksFormat /dev/sdz9
> 
> WARNING!
> ========
> This will overwrite data on /dev/sdb1 irrevocably.
> 
> [… etc …]
> 
> Add more passphrases:
> 
> # cryptsetup luksAddKey /dev/sdz9
> 
> [… etc …]
> 
> Create the filesystem:
> 
> # cryptsetup open --type luks /dev/sdz9 thename
> 
> # mkfs.ext4 -L name09 /dev/mapper/thename
> 
> [… etc …]
> 
> # e2label /dev/mapper/thename name09 (if forgotten above).
> 
> Finally:
> 
> # cryptsetup luksClose thename
> 
> --✄----
> 
> (I mangle the device names to make copy/paste less dangerous.)
> 
> > (I have some scripts to allow me to easily open (and close) those
> > filesystems -- when they open, the unencrypted content is put on a
> > ramdisk (with the intent if somebody gets physical possession of the
> > device (which is a desktop, not a laptop), the enencrypted data
> > disappears on power off.)
> 
> As I encrypt /home, it wouldn't make sense for me to copy it all.
> I assume that nobody's going to freeze my PC when they steal it.
> 
> My scripts use LABELled filesystems (as seen above), so there's nothing
> unusual about /etc/fstab; and I unlock with udisksctl, using the
> /dev/disk/by-partlabel value, so there's no entry in /etc/crypttab.
> 
> > Well, the Buster system is a laptop, Jessie is a desktop.  I don't plan
> > to put much, if any, sensitive data on the laptop.  (I don't really even
> > intend to take the laptop out of the house, especially during this Covid
> > thing -- I installed Buster on it because I needed GCC 7+ and couldn't
> > (easily) do that on the Wheezy or Jessie systems.
> > 
> > > Do you use suspend?
> > 
> > No.
> 
> Then you could encrypt swap with a random key. My method for that
> is unusual, in that the swap partition is specified in fstab by
> its (tiny) filesystem's LABEL. Its /etc/crypttab is thus fixed:
> 
> swap	LABEL=cryptswap	/dev/urandom	swap,offset=2048,cipher=aes-xts-
plain64,s
> ize=512
> 
> > > Desktops?
> > 
> > See above.
> > 
> > > Do you boot them remotely?
> > 
> > No, but they do stay up 24/7 unless there is a (longer that 2 minute
> > (power is UPS supported)) power outage, or a (very rare) reboot.
> 
> OK. This only really matters if you're encrypting /home (as I do)
> or the system itself, as you then need a method of supplying the
> passphrase before any users can login. (I use a pseudo-user whose
> ~ is in /var/local/home/ with a crafted .bash_profile.)
> 
> Cheers,
> David.

[toc] | [prev] | [next] | [standalone]

#224045

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. I 
definitely wouldn't do it on an SSD.

># 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.)

[toc] | [prev] | [next] | [standalone]

#224047

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.

[toc] | [prev] | [next] | [standalone]

#224049

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.

>> > # 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.

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

[toc] | [prev] | [next] | [standalone]

#224077

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web