Re: Advice on encrypted filesystem
On 2020-06-27 01:46, Andrei POPESCU wrote: The latest recommendation I saw for "cheap flash based" storage is 4MiB in order to align with erase block sizes, so now I'm starting all my partitions at 4MiB instead of 1MiB. Interesting subject -- thanks for bringing it up. :-) STFW there does not appear to be a "one size fits all" solution -- the "best" answer depends upon the specific storage device/ controller/ firmware version and specific OS/ kernel/ version. Given my solid-state system drives are 16+ GB, losing 3 MiB by aligning the partitions at 4 MiB boundaries instead of 1 MiB boundaries is a small sacrifice; just in case it really does matter (now or in the future). David
Re: Advice on encrypted filesystem
On 2020-06-27 12:47, David Christensen wrote: The ATA secure erase command is designed to erase all blocks, both host-accessible and hidden. STFW, "secure erase" (aka "security erase") is an older feature and may not erase all NAND blocks, just the "mapping table". (When I have done this on my Intel SSD 520 Series devices and then dumped the entire drive with hexdump(1), the host reported all zeroes. But, I have not disassembled a drive, removed the NAND chips, and put them into a NAND chip reader.) There is a newer feature "sanitize' that is supposed to erase both the mapping table and all data storage NAND blocks: https://www.micron.com/about/blog/2017/march/how-to-securely-erase-micron-sata-ssds https://www.diskpart.com/articles/sanitize-or-secure-erase-ssd-4125.html https://www.microcontrollertips.com/ssds-secure-erase-sanitize-faq/ David
Re: Advice on encrypted filesystem
On 6/27/20 6:00 AM, David Christensen wrote: On 2020-06-26 18:25, David Wright wrote: 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? The best option is to command the SSD firmware to do a "secure delete". Some SSD manufacturers provide utilities for doing this. Alternatively, it can be done from the command line with Linux. On 2020-06-27 01:05, Admin4 wrote: > 1) backup your data to external usb drive > > 2) reinstall with encrypted enabled > > 3) restore data That process is likely to leave both host-accessible and hidden unencrypted blocks from the prior installation on the device. > = a lot of unencrypted data get's overwritten (if user does not have a > lot of data, generate some X-D) "a lot" is not the same as "all". The ATA secure erase command is designed to erase all blocks, both host-accessible and hidden. David
Re: Advice on encrypted filesystem
On Vi, 26 iun 20, 20:25:32, David Wright wrote: > > 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). The latest recommendation I saw for "cheap flash based" storage is 4MiB in order to align with erase block sizes, so now I'm starting all my partitions at 4MiB instead of 1MiB. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Advice on encrypted filesystem
1) backup your data to external usb drive 2) reinstall with encrypted enabled 3) restore data = a lot of unencrypted data get's overwritten (if user does not have a lot of data, generate some X-D) On 6/27/20 6:00 AM, David Christensen wrote: > On 2020-06-26 18:25, David Wright wrote: > >> 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? > > The best option is to command the SSD firmware to do a "secure > delete". Some SSD manufacturers provide utilities for doing this. > Alternatively, it can be done from the command line with Linux. > > > David
Re: Advice on encrypted filesystem
On 2020-06-26 21:00, David Christensen wrote: On 2020-06-26 18:25, David Wright wrote: 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? The best option is to command the SSD firmware to do a "secure delete". Some SSD manufacturers provide utilities for doing this. Alternatively, it can be done from the command line with Linux. Correction "ATA Secure Erase command": https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase David
Re: Advice on encrypted filesystem
On 2020-06-26 18:25, David Wright wrote: 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? The best option is to command the SSD firmware to do a "secure delete". Some SSD manufacturers provide utilities for doing this. Alternatively, it can be done from the command line with Linux. David
Re: Advice on encrypted filesystem
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.
Re: Advice on encrypted filesystem
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.
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.
Re: Advice on encrypted filesystem
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.)
Re: Advice on encrypted filesystem
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), rhkra...@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), rhkra...@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/urandomswap,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.
Re: Advice on encrypted filesystem
On Thu 25 Jun 2020 at 07:40:43 (-0400), rhkra...@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), rhkra...@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: swapLABEL=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.
Resolved (at least the sound) Re: Zoom client for Linux (was: Re: Advice on encrypted filesystem)
On Thursday, June 25, 2020 10:14:50 AM rhkra...@gmail.com wrote: > Can you give me any clues about how you told it which audio device to use > (and which you told it to use)? Ahh, I found the settings screen and switched the audio (to "Built In Analog Audio Stereo") and tested it -- it works. (I believe there is a test meeting somewhere, I want to try connecting to that to make sure things are working, and then I want to change my screen name -- I'm guessing I'll figure those out.
Re: Advice on encrypted filesystem
On Thursday, June 25, 2020 07:29:53 AM rhkra...@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?
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
Re: Advice on encrypted filesystem
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 signature.asc Description: PGP signature
Re: Advice on encrypted filesystem
On Thu, 25 Jun 2020 at 21:30, 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
Re: Advice on encrypted filesystem
On Wednesday, June 24, 2020 10:20:55 PM David Wright wrote: > On Wed 24 Jun 2020 at 21:28:38 (-0400), rhkra...@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.
Re: Advice on encrypted filesystem
On Wednesday, June 24, 2020 09:34:00 PM Roberto C. Sánchez wrote: > On Wed, Jun 24, 2020 at 09:28:38PM -0400, rhkra...@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.
Re: Advice on encrypted filesystem
On 6/25/2020 3:34 AM, Roberto C. Sánchez wrote: On Wed, Jun 24, 2020 at 09:28:38PM -0400, rhkra...@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
Re: Advice on encrypted filesystem
On Wed 24 Jun 2020 at 21:28:38 (-0400), rhkra...@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.
Re: Advice on encrypted filesystem
On 2020-06-24 18:34, Roberto C. Sánchez wrote: On Wed, Jun 24, 2020 at 09:28:38PM -0400, rhkra...@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
Re: Advice on encrypted filesystem
On Wed, Jun 24, 2020 at 09:28:38PM -0400, rhkra...@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
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?
