Re: [gentoo-user] Encrypting a hard drive's data. Best method.
Victor Ivanov wrote: > From what I gather, taking into account your other email as well, there > are two separate things going on which may or may not be related: > > 1) The (now open) filesystem isn't being mounted where it should as per > fstab > > 2) Even then, there appears to be a bogus 'private' parent directory: > /run/media/private// as opposed to /run/media// When I named it, I named it private. It could be that is where it got that word from. It could be DN picked it up, it could be other things picked it up as well. Basically, that's the LVM name for the group thingy. I named the partition privatepart. I added part so I would know it is a partition. Sometimes the names LVM uses can be confusing. I try to avoid naming a LVM group and a partition with the same name. If nothing else, I add 'part' for partitions or something that I can tell what they are more than what they are called. Example, I have a internal backup drive that has a LVM group named backup. The partition is also named backup. Yea, now which is which? If I ever redo that, I'll name the partition backuppart or something. Then I know which is a LVM group and which is a partition. > On 11/06/2020 23:17, Dale wrote: >> This is my fstab entry: >> >> UUID="7f0cf585-57c8-4a50-808b-987fc13ceee0" >> /home/dale/Desktop/Videos/Private ext4 defaults,users 0 0 >> ... >> You notice anything off about that? I make a error somewhere? Miss a >> option maybe? > fstab doesn't like quotes. The correct syntax would be: > UUID=7f0cf585-57c8-4a50-808b-987fc13ceee0 > > Re (1) above, given that /etc/conf.d/dmcrypt is only used by the dmcrypt > service through OpenRC its contents are irrelevant when using KDE. So, > from the perspective of DN updating fstab with the correct syntax should > be a two birds, one stone solution to both (1) and (2). > > Unless your encrypted volume is always connected to the system and you > would like it to be automatically unlocked (via means of being asked to > enter your password), there is no need to enter anything into > /etc/conf.d/dmcrypt and you can leave the file blank/commented out. > > Re (2), frankly, I have no idea but I'm curious as to where that > "private" parent directory might come from. The only possible source for > this that I can guess is from your entry in /etc/conf.d/dmcrypt in the > value for "target": I copied that method from a wiki. I also have this in fstab. The first one has been there for several years. It mounts when booting up. UUID="13d4bec9-1271-490c-b718-d8b1c68ae1e6" /backup ext4 defaults 0 2 UUID="7f0cf585-57c8-4a50-808b-987fc13ceee0" /home/dale/Desktop/Videos/Private ext4 defaults,users 0 0 It has quote marks and it works fine. Maybe that is a new thing?? That said, I'll remove them since on a Gentoo wiki, it doesn't show them. I commented out the entries in dmcrypt. I saved them in case I need to refer back later tho. It took me a while to figure out what all I needed and what I didn't tho. Poor google. >> ## 3TB private drive external >> target='private' >> source=UUID='107be33c-b31c-44b8-b4e7-400ee19fb440' > While this should only affect the name of the block device created under > "/dev/mapper" it seems too much of a coincidence that the bogus parent > directory bears the same name. I've tried to reproduce your set-up but I > still don't get such a parent under /run/media. Perhaps you can try > changing the value to something else and see if it creates a directory > with the new name? If so, this would confirm the theory, but it still > shouldn't be doing that. At least it would be a starting point for > diagnosis, if it's worth going into that at all. > > Also, note that, as I mentioned, when mounting a crypto container > through KDE DN or Dolphin your dmcrypt config is irrelevant and > disregarded. You should hence expect upon opening the container to have > the filesystem's block device appear as "/dev/mapper/luks_abcd1234". > > - Victor > I been doing it manually. I open the drive on the command line, make sure it is open and then mount it manually. It uses fstab and mounts where I want it that way. The DN tool just doesn't work. Actually, trying to use it to handle encrypted drives sort of screwed up my normal drives and such. Now it's mounting those things wrong. I'm concerned it is going to break some thing such as my SDHC cards that I put in a card reader. I started a new thread on that. How do you mount something within Dolphin? I've looked through the menus and I can't find anything on mounting listed. I haven't got my new glasses yet so maybe I'm not seeing it??? lol Thanks. I had to read this twice to make sure I got where you were going here. I think I got it tho. ;-) Dale :-) :-)
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
From what I gather, taking into account your other email as well, there are two separate things going on which may or may not be related: 1) The (now open) filesystem isn't being mounted where it should as per fstab 2) Even then, there appears to be a bogus 'private' parent directory: /run/media/private// as opposed to /run/media// On 11/06/2020 23:17, Dale wrote: > This is my fstab entry: > > UUID="7f0cf585-57c8-4a50-808b-987fc13ceee0" > /home/dale/Desktop/Videos/Private ext4 defaults,users 0 0 > ... > You notice anything off about that? I make a error somewhere? Miss a > option maybe? fstab doesn't like quotes. The correct syntax would be: UUID=7f0cf585-57c8-4a50-808b-987fc13ceee0 Re (1) above, given that /etc/conf.d/dmcrypt is only used by the dmcrypt service through OpenRC its contents are irrelevant when using KDE. So, from the perspective of DN updating fstab with the correct syntax should be a two birds, one stone solution to both (1) and (2). Unless your encrypted volume is always connected to the system and you would like it to be automatically unlocked (via means of being asked to enter your password), there is no need to enter anything into /etc/conf.d/dmcrypt and you can leave the file blank/commented out. Re (2), frankly, I have no idea but I'm curious as to where that "private" parent directory might come from. The only possible source for this that I can guess is from your entry in /etc/conf.d/dmcrypt in the value for "target": > ## 3TB private drive external > target='private' > source=UUID='107be33c-b31c-44b8-b4e7-400ee19fb440' While this should only affect the name of the block device created under "/dev/mapper" it seems too much of a coincidence that the bogus parent directory bears the same name. I've tried to reproduce your set-up but I still don't get such a parent under /run/media. Perhaps you can try changing the value to something else and see if it creates a directory with the new name? If so, this would confirm the theory, but it still shouldn't be doing that. At least it would be a starting point for diagnosis, if it's worth going into that at all. Also, note that, as I mentioned, when mounting a crypto container through KDE DN or Dolphin your dmcrypt config is irrelevant and disregarded. You should hence expect upon opening the container to have the filesystem's block device appear as "/dev/mapper/luks_abcd1234". - Victor signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
Victor Ivanov wrote: > On 10/06/2020 21:52, Dale wrote: >> I've got that in dmcrypt and fstab as the wiki says. That part works. >> It's the KDE part that isn't working correctly. However, I did do one >> thing different, I put users instead of user. Plural not singular. >> Should users work the same as user? > This makes little sense. The main difference between user and users is > that the former only allows the user who mounted the filesystem (or > root) to unmount the filesystem, whereas the latter (plural) relaxes > this rule and allows any user to unmount the filesystem. Then maybe that isn't the issue. I didn't think it would matter but did want to mention it. Just in case. ;-) > > On 10/06/2020 21:52, Dale wrote: >> I wonder, other distros have crypttab file instead of dmcrypt. I wonder >> if I created a crypttab file if that would help KDE even if Gentoo >> ignores it or doesn't know it exists. > Doubtful. As far as I'm aware "/etc/crypttab" is for systems that use > that atrocity called systemd. So unless you have your system set up to > use systemd, "/etc/conf.d/dmcrypt" is the correct one to use. No systemd here. Whew!! > On 10/06/2020 21:52, Dale wrote: >> It sounds like the Device Notifier is just not set up or designed to do >> what I want to do. > Unfortunately, it's quite basic indeed. I still, however, think you can > achieve what you intend to with fstab. I personally tested what I wrote > in my previous email and, apart from the usual false error message, it > mounts it exactly where I've described in /etc/fstab. I can also eject > it via Device Notifier. Could it be that there's something else going on > in your case? > > - Victor > My dmcrypt entry: ## 3TB private drive external target='private' source=UUID='107be33c-b31c-44b8-b4e7-400ee19fb440' I think I got that right but I'm me. lol This is my fstab entry: UUID="7f0cf585-57c8-4a50-808b-987fc13ceee0" /home/dale/Desktop/Videos/Private ext4 defaults,users 0 0 Right now I stuck it under Videos but it's because that was where I was when I started. Later on, I'll move it to be under Documents. I'll worry about moving it later on. You notice anything off about that? I make a error somewhere? Miss a option maybe? Thanks. Dale :-) :-)
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 10/06/2020 21:52, Dale wrote: > I've got that in dmcrypt and fstab as the wiki says. That part works. > It's the KDE part that isn't working correctly. However, I did do one > thing different, I put users instead of user. Plural not singular. > Should users work the same as user? This makes little sense. The main difference between user and users is that the former only allows the user who mounted the filesystem (or root) to unmount the filesystem, whereas the latter (plural) relaxes this rule and allows any user to unmount the filesystem. On 10/06/2020 21:52, Dale wrote: > I wonder, other distros have crypttab file instead of dmcrypt. I wonder > if I created a crypttab file if that would help KDE even if Gentoo > ignores it or doesn't know it exists. Doubtful. As far as I'm aware "/etc/crypttab" is for systems that use that atrocity called systemd. So unless you have your system set up to use systemd, "/etc/conf.d/dmcrypt" is the correct one to use. On 10/06/2020 21:52, Dale wrote: > It sounds like the Device Notifier is just not set up or designed to do > what I want to do. Unfortunately, it's quite basic indeed. I still, however, think you can achieve what you intend to with fstab. I personally tested what I wrote in my previous email and, apart from the usual false error message, it mounts it exactly where I've described in /etc/fstab. I can also eject it via Device Notifier. Could it be that there's something else going on in your case? - Victor signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
Michael wrote: > On Wednesday, 10 June 2020 07:59:19 BST Dale wrote: >> Howdy, >> >> Same topic just new question. I use KDE and am wanting to have it so >> the Device Notifier will allow me to mount the drive when I turn it on. > I probably missed in earlier threads, but is this is an externally powered > USB > device? > Not USB but eSATA. >> So far, I got it set up and when I turn the drive on and click for it to >> mount it, it asks me for a password. > Where do you "click for it"? The Device Notifier in the KDE panel thingy. I use it to access my cameras, SD cards put in my card reader and even my cell phone. > > >> I type in the password but it mounts it to the wrong place. > Please define "wrong place". > It mounts under /run. I want it mounted under /home. >> If I do it on the command line, it works as expected. > What is expected? > I was expecting it to mount from the Device Notifier just like it does from the command line. >> I have it set up in dmcrypt and fstab. So, command line >> works, KDE's Device Notifier doesn't. > For the avoidance of doubt: > > "command line" = /bin/mount > > "KDE's Device Notifier" = /usr/bin/udisksctl > > There is a difference between the two: > > $ ls -la /bin/mount > -rws--x--x 1 root root 56360 May 11 00:25 /bin/mount > > $ ls -la /usr/bin/udisksctl > -rwxr-xr-x 1 root root 60496 Nov 23 2019 /usr/bin/udisksctl > > > You run mount as root with temporarily elevated privileges and operate on > devices directly via the kernel, but can only mount such block devices if > they > have a corresponding /etc/fstab entry - unless you are root. > > You run udisksctl as plain user - it is a userspace command which operates on > the udisks daemon to manipulate mountable devices via D-Bus. The default > mountpoint by udisksctl is under /run/media//LABEL > True but since I'm wanting to mount it under the same /home directory as the user doing the mounting, it shouldn't require any additional privileges. >> It tells me I don't have >> permission to access but it also mounts it in the wrong place. I >> suspect it mounting it in the wrong place leads to the permissions >> error. It mounts under /run. I want it mounted under /home. > You may be able to achieve this via udev rules for the specific UUID of the > disk, or perhaps via a symlink from /home to the /run mountpoint. I haven't > tested this, but you could give it a spin and see what you get. > > PS. You can ignore my earlier questions, no need to answer them. The > structure of your message was perhaps back to front to assist my > understanding. :-) No problem. Sometimes when anyone is writing, it's assumed that everyone else knows the steps that are taken. Usually that is not the case. It's why we always ask for error messages, commands used etc etc etc. ;-) Based on everything I've found with google, I think the Device Notifier is badly limited. It can get to a certain point but it can't go any further. It seems we need a better tool or the current tool needs a little extra programming. I was wanting to avoid the command line part in case something happened to me and someone needed to access a encrypted device. Victor seems to confirm that with his reply. Thanks. Dale :-) :-)
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
Victor Ivanov wrote: > On 10/06/2020 07:59, Dale wrote: >> It tells me I don't have permission to access but it also mounts it > This KDE bug re Device Notifier has been present for a long time and > it's seriously infuriating. Mounting from Dolphin, on the other hand, > seems to work just fine, though it too doesn't miss the opportunity to > complain about privileges. > > It's not a Gentoo specific issue, as I've experienced this on other > distros too. I believe there was an upstream bug report that kept > getting resolved and reopened. > > On 10/06/2020 07:59, Dale wrote: >> I type in the password but it mounts it to the wrong place. > This is normal. By default, volumes mounted from userspace will be > mounted under "/run/media//". This makes sense and is > entirely due to user privileges. Mounting under other directories would > require escalation of privileges. But most basic UI features are > designed for the most common scenario. > > On 10/06/2020 07:59, Dale wrote: >> How do I tell the Device Notifier that I want it mounted somewhere >> else? > From KDE you can't and there's no KDE-specific tool to allow you to do > that. But you can add the UUID of the filesystem to /etc/fstab and KDE > will then mount it under that location. However, make sure that the UUID > is that of the open volume, not the encrypted container. > > For example, if you manually open the encrypted volume via the command > line, e.g.: > > # cryptsetup open /dev/sdz1 crypto_volume_name > > This will ask you for the encryption password and, if correct, will > create a new block device "/dev/mapper/crypto_volume_name". > > You can then get the UUID of "/dev/mapper/crypto_volume_name" with: > > # blkid /dev/crypto_volume_name > > At this point you can close your LUKS container via: > > # cryptsetup close crypto_volume_name > > You can bypass steps 1 and 3 above by mounting via the KDE as usual, > which will automatically create the block device > "/dev/mapper/luks_abcdef1234". You can then get its UUID via step 2 and > replace step 3 by ejecting the mounted volume. > > Finally, add this UUID to /etc/fstab in the usual way: > > UUID= /dst/mount/dir [mount_options],user 0 0 > > Note "user" under mount options. This is critical to making it work > seamlessly from KDE, otherwise it will require escalation of privileges > to mount the volume. > > Once you do the above, the volume should automatically be mounted under > "/dst/mount/dir" the next time you mount it via Dolphin or Device Notifier. > > It still won't get rid of the annoying "You don't have permissions" > error message, but it does work. > > Hope this helps. > > - Victor > I've got that in dmcrypt and fstab as the wiki says. That part works. It's the KDE part that isn't working correctly. However, I did do one thing different, I put users instead of user. Plural not singular. Should users work the same as user? I wonder, other distros have crypttab file instead of dmcrypt. I wonder if I created a crypttab file if that would help KDE even if Gentoo ignores it or doesn't know it exists. It sounds like the Device Notifier is just not set up or designed to do what I want to do. Given the number of people who do what I'm doing, it looks like KDE would either update the Device Notifier or have a new tool that handles encrypted things. Dale :-) :-)
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 10/06/2020 07:59, Dale wrote: > It tells me I don't have permission to access but it also mounts it This KDE bug re Device Notifier has been present for a long time and it's seriously infuriating. Mounting from Dolphin, on the other hand, seems to work just fine, though it too doesn't miss the opportunity to complain about privileges. It's not a Gentoo specific issue, as I've experienced this on other distros too. I believe there was an upstream bug report that kept getting resolved and reopened. On 10/06/2020 07:59, Dale wrote: > I type in the password but it mounts it to the wrong place. This is normal. By default, volumes mounted from userspace will be mounted under "/run/media//". This makes sense and is entirely due to user privileges. Mounting under other directories would require escalation of privileges. But most basic UI features are designed for the most common scenario. On 10/06/2020 07:59, Dale wrote: > How do I tell the Device Notifier that I want it mounted somewhere > else? From KDE you can't and there's no KDE-specific tool to allow you to do that. But you can add the UUID of the filesystem to /etc/fstab and KDE will then mount it under that location. However, make sure that the UUID is that of the open volume, not the encrypted container. For example, if you manually open the encrypted volume via the command line, e.g.: # cryptsetup open /dev/sdz1 crypto_volume_name This will ask you for the encryption password and, if correct, will create a new block device "/dev/mapper/crypto_volume_name". You can then get the UUID of "/dev/mapper/crypto_volume_name" with: # blkid /dev/crypto_volume_name At this point you can close your LUKS container via: # cryptsetup close crypto_volume_name You can bypass steps 1 and 3 above by mounting via the KDE as usual, which will automatically create the block device "/dev/mapper/luks_abcdef1234". You can then get its UUID via step 2 and replace step 3 by ejecting the mounted volume. Finally, add this UUID to /etc/fstab in the usual way: UUID= /dst/mount/dir [mount_options],user 0 0 Note "user" under mount options. This is critical to making it work seamlessly from KDE, otherwise it will require escalation of privileges to mount the volume. Once you do the above, the volume should automatically be mounted under "/dst/mount/dir" the next time you mount it via Dolphin or Device Notifier. It still won't get rid of the annoying "You don't have permissions" error message, but it does work. Hope this helps. - Victor signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On Wednesday, 10 June 2020 07:59:19 BST Dale wrote: > Howdy, > > Same topic just new question. I use KDE and am wanting to have it so > the Device Notifier will allow me to mount the drive when I turn it on. I probably missed in earlier threads, but is this is an externally powered USB device? > So far, I got it set up and when I turn the drive on and click for it to > mount it, it asks me for a password. Where do you "click for it"? > I type in the password but it mounts it to the wrong place. Please define "wrong place". > If I do it on the command line, it works as expected. What is expected? > I have it set up in dmcrypt and fstab. So, command line > works, KDE's Device Notifier doesn't. For the avoidance of doubt: "command line" = /bin/mount "KDE's Device Notifier" = /usr/bin/udisksctl There is a difference between the two: $ ls -la /bin/mount -rws--x--x 1 root root 56360 May 11 00:25 /bin/mount $ ls -la /usr/bin/udisksctl -rwxr-xr-x 1 root root 60496 Nov 23 2019 /usr/bin/udisksctl You run mount as root with temporarily elevated privileges and operate on devices directly via the kernel, but can only mount such block devices if they have a corresponding /etc/fstab entry - unless you are root. You run udisksctl as plain user - it is a userspace command which operates on the udisks daemon to manipulate mountable devices via D-Bus. The default mountpoint by udisksctl is under /run/media//LABEL > It tells me I don't have > permission to access but it also mounts it in the wrong place. I > suspect it mounting it in the wrong place leads to the permissions > error. It mounts under /run. I want it mounted under /home. You may be able to achieve this via udev rules for the specific UUID of the disk, or perhaps via a symlink from /home to the /run mountpoint. I haven't tested this, but you could give it a spin and see what you get. PS. You can ignore my earlier questions, no need to answer them. The structure of your message was perhaps back to front to assist my understanding. :-) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
Howdy, Same topic just new question. I use KDE and am wanting to have it so the Device Notifier will allow me to mount the drive when I turn it on. So far, I got it set up and when I turn the drive on and click for it to mount it, it asks me for a password. I type in the password but it mounts it to the wrong place. If I do it on the command line, it works as expected. I have it set up in dmcrypt and fstab. So, command line works, KDE's Device Notifier doesn't. It tells me I don't have permission to access but it also mounts it in the wrong place. I suspect it mounting it in the wrong place leads to the permissions error. It mounts under /run. I want it mounted under /home. How do I tell the Device Notifier that I want it mounted somewhere else? I've never done this part before since I let everything else mount under /run. My cameras, cell phone, card reader and such mounts under it. That's fine for those. This I want to mount under /home tho. Is this doable? Is there another tool KDE needs to do this? Thanks. Dale :-) :-)
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
antlists wrote: > On 07/06/2020 10:07, antlists wrote: >> I think it was LWN, there was an interesting article on crypto recently. > > https://lwn.net/Articles/821544/ > > Cheers, > Wol > > Looks like they are getting ready to toss sha1 overboard. If it is not secure, they should. At least most people who should know, already know it is not secure. I didn't have the details but I knew something was hacked and asked to be sure. I ended up using a AES one. I did set up, using zulucrypt at the moment, to encrypt a 3TB external hard drive. So far, it is working fine. I've closed it a few times and opened it a few times. The one thing I have not figure out yet, about to look into it, how to mount it to a place I pick. It's likely a setting I haven't noticed yet but I'll find it. Still not ready to even think of doing /home yet tho. That's a doozy. I guess first I'd have to move everything off the drives it's currently on, encrypt that drive and then move everything back. Another thing, having a secure password that is easy to type and remember but can't be guesses. Anyone remember the thread when I came up with a password for PGP and LastPass a year or so ago??? It took me a month to accomplish that but it is a good one. Then I got a cell phone. Easy to type on the keyboard, not so much on the cell phone tho. Still, it works well. It is a good one. Good luck to anyone trying to guess it or even hack it. lol I wish my other drive would have worked. I'd like to be able to compare things. They are both the same brand and size. Likely even the same model. But it has some serious issues. Even smartctrl was having trouble chatting with the drive. That's bad. May redo the drive but with command line tools this go around. Just for giggles. Thanks again. Dale :-) :-)
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 07/06/2020 10:07, antlists wrote: I think it was LWN, there was an interesting article on crypto recently. https://lwn.net/Articles/821544/ Cheers, Wol
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On Fri, Jun 05, 2020 at 11:37:23PM -0500, Dale wrote: > Howdy, > > I think I got a old 3TB hard drive to work. After dd'ing it, redoing > partitions and such, it seems to be working. Right now, I'm copying a > bunch of data to it to see how it holds up. Oh, it's a PMR drive too. > lol Once I'm pretty sure it is alive and working well, I want to play > with encryption. At some point, I plan to encrypt /home. I found a bit > of info with startpage but some is dated. This is one link that seems > to be from this year, at least updated this year. Encryption is a means to protect against adversaries, but in my case I mostly want to protect from incidental access. My top “use” cases: - I need to send in a broken disk for service/replacement - $DEVICE is stolen and I dont’t want the thief to access my personal stuff - the device needs to be serviced, but has its storage soldered on - protect from recovery on flash storage I’ve been running full-disk encryption with LUKS/LVM for some years now on my laptop’s SSD. I used Sakaki’s scripts to set up the kernel and initrd. The encryption password is entered during the boot process while still in the initrd phase. I don’t know of the current status of Sakaki’s stuff though (I must admit I moved away from Gentoo because portage took to much time on the laptop). On my main PC I used to have ~ on a hard disk and / on an SSD. So I left / unencrypted and symlinked sensitive files such as wpa_supplicant.conf and database files onto a directory beneath /home. Since decryption is done early at boot, there is no race condition. By now I upgraded the SSD and have both / and ~ on it, but I kept the scheme out of laziness. A week ago I got me and myself a used Surface Go (a little X86 tablet) which only has a small SSD soldered onto the board. There is no way to access or replace it. I didn’t want to use the same approach as with the laptop, because I wanted to be able to boot without a keyboard. This meant that PW entry at early boot was no option because there is no touch support at this stage. So I researched a little towards decryption at login. Ext4-internal encryption was a strong contender, because it allowed me to decrypt ~ on login, while still using a shared partitions for / and ~, which would give me more flexibility on the constrained SSD. It also encrypts filenames, but not access times (which I was OK with). Eventually though, I decided to go for more encapsulation and put ~ on a separate partition again. I set it up with LUKS and auto-mount it on login with pam_mount. On a performance not: the Surface Go has an NVME SSD and hdparm -t varies wildly between 220 and 640 MB/s. OTOH, cryptsetup benchark resulted in 1330 MiB/s for aes-cbc with a 128 bit key. Aes-xts was slower, but once I disabled all kernel mitigations¹, its throughput went up by more than 40 % and also reached 1300 MiB/s. And this is for the meagre Pentium Gold processor. So no worries in that department. ¹ Many of those vulnerabilities are about violating memory boundaries, which is most relevant for server operators and securing their users from each other. Thus, I don’t care about those on my personal machines and rather have the original performance. Exploits need to get *on* my machines first before they can snoop in my memory. -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me on any social network. I hate being bi-polar. It’s fantastic! signature.asc Description: PGP signature
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 07/06/2020 12:52, Victor Ivanov wrote: > Indeed. I second Rich and too would recommend sticking with AES for this > reason. LUKS will support an AES key of up to 512 bits. It's fast and > hardware acceleration is widely available. > ... > For example, Intel's native AES extensions work in 4x4 data blocks of > 128 bits but will support variable key lengths. Their white paper [3] > suggests supported key lengths are 128, 192, and 256 bits but I've been > using a 512 bit key on my drives for years with negligible performance > impact (Skylake systems). Perhaps this requires extra clarification re key length, which I should have included, as it may give misleading information. As an algorithm AES fundamentally only goes up to 256 bits for key length. However, in XTS mode (aes-xts) two _separate_ keys are used for the initialisation vector and the block encryption. As such, for AES-256 in XTS mode, one needs to supply 2x256b keys. Effectively, 512b are used, but this too may be misleading. It's better than 1x256b but certainly not as good as 1x512: (2^256 + 2^256) vs 2^512. It also maps well to hardware extensions already supporting key sizes of 256b. This is not possible in CBC or GCM mode which only allows for a single key of up to 256b. My apologies, it was a case of my fingers getting ahead of my thoughts and not having formulating the latter appropriately. Regards, Victor signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 07/06/2020 09:08, Dale wrote: > You can have a password, a key file, both or likely other options as > well. On one video, the guy generated a key file with urandom that was > 1024 characters. As he put it, try typing that in. Indeed! All of these techniques have various pros/cons which is partly why my last reply / novel ended up being long yet still shallow. A key file would, generally, be more secure provided you can keep the medium on which it is stored secure as well. A long and strong password doesn't have to be difficult to type though. A lot of 2FA dongles, such as the YubiKey will allow for one (or more) of its key slots to be programmed in plain text. If you have one, this would allow you to effectively "paste" a very long password in less than a second. Then again, you will have to keep your dongle secure as well, as plain text means anyone can "paste" the password into a text file. Again, pros/cons of the strategy. On 07/06/2020 09:08, Dale wrote: > Then I found out about crypttab. I don't have that on my system, yet. Crypttab is the standard on most distributions. Gentoo, however, uses "/etc/conf.d/dmcrypt". Personally, I find its syntax less of an eyesore and more favourable, but it does effectively the same thing. And the comments inside it are even better than a man page haha On 07/06/2020 09:08, Dale wrote: > I still don't think I'm ready to try and do this on a hard drive. Don't let any of that discourage you :) It's a lot simpler than it may seem, and most desktop environments (I believe you we using KDE?) have excellent support for mounting and unmounting/ejecting encrypted volumes both internal, as well as removable, once the LUKS container has been set up. The guide [1] (also linked to earlier) is comprehensive, but fundamentally the most relevant part for getting started are steps 2.3-2.5. If you use genkernel, with LUKS="yes" in the config it will have taken care of the kernel for you and even created a initramfs suitable for an encrypted root. As Rich suggested try it out with a flash drive or a loopback file. On a side note re drives, if using LUKS with an SSD you may or may not wish to keep trimming disabled, as it may lead to leaked data regarding the blocks being trimmed [2]. For this reason, trim pass-through is left OFF by default. The leaked information, however, is minimal and I doubt it poses any significant risk for the average use case. On 07/06/2020 09:08, Dale wrote: > I notice that one can use different encryption tools. I have Blowfish, > Twofish, AES and sha*** Bear in mind not all of the items listed are encryption algorithms per se. The SHA and Argon families are hashing algorithms/functions used to hash your password and store it an obfuscated form. They are also used as HMAC functions in the context of encrypted data exchange. The key thing is that hash functions are one-way. That is, it's computationally straightforward to create the hash of a given input, but computationally infeasible to reverse the process. They do not use a a separate encryption key, and the result is always deterministic and reproducible. I would stick with SHA as its widely supported. Except for sha1 which was cracked a few years back. If you choose sha256 or better yet sha512 you can't go wrong. Argon2 is a great choice, but if I'm not mistaken it's only supported by LUKS2 which Gentoo only recently made the default. I believe most current distros have LUKS2 by default, but older ones, including some LTS versions and distros with release cycles of once per century or so may not support that, so for removable drives I would stick to LUKS1. On 07/06/2020 11:33, Rich Freeman wrote: > AES is probably the most mainstream crypto system out there and is > considered very secure. It is also widely supported by hardware and > all recent Intel/AMD CPUs. Indeed. I second Rich and too would recommend sticking with AES for this reason. LUKS will support an AES key of up to 512 bits. It's fast and hardware acceleration is widely available. For example, Intel's native AES extensions work in 4x4 data blocks of 128 bits but will support variable key lengths. Their white paper [3] suggests supported key lengths are 128, 192, and 256 bits but I've been using a 512 bit key on my drives for years with negligible performance impact (Skylake systems). But since data block size is fixed, this hardly surprising. Acceleration of key length > 128b then only becomes relevant at key generation time which is a one-time step, so the cost of this step becomes largely irrelevant. [1] https://wiki.gentoo.org/wiki/Dm-crypt [2] http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html [3] https://www.intel.com/content/dam/doc/white-paper/enterprise-security-aes-ni-white-paper.pdf signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On Sun, Jun 7, 2020 at 4:08 AM Dale wrote: > > I still don't think I'm ready to try and do this on a hard drive. I'm > certainly not going to do this with /home yet. If you have a spare drive or just a USB stick lying around, set it up on that. Then you can test that it mounts on boot and prompts for a password and all that stuff. Or you can use a loopback filesystem using a file on your hard drive. That is pretty safe as long as you don't enter "/bin/bash" as your loopback filename or whatever. I'm not sure if that will correctly mount itself automatically at boot though, as I'm not sure if the various service dependencies are set up to handle it (the drive containing the file has to be mounted first). > I notice that one can use different encryption tools. I have Blowfish, > Twofish, AES and sha*** as well as many others. I'd stick with AES. If you're trying to keep the NSA out of your hard drive and you think they're part of a conspiracy to get people to use AES despite having cracked it, then I don't know what to tell you because they're probably going to get you no matter what you do... :) AES is probably the most mainstream crypto system out there and is considered very secure. It is also widely supported by hardware and all recent Intel/AMD CPUs. 128-bit keys are the most standard. Linux supports 256-bit though if you use that I'm not sure if hardware-acceleration is available. -- Rich
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 07/06/2020 09:08, Dale wrote: I notice that one can use different encryption tools. I have Blowfish, Twofish, AES and sha*** as well as many others. I know some have been compromised. Which ones are known to be secure? I seem to recall that after Snowden some had to be redone and some new ones popped up to make sure they were secure. Thoughts?? Some had to be redone ... Elliptic Cryptograph Curve or whatever it's called. The basic maths is secure, but the NSA got a standard released (you have to pick a set of constants) where the constants had been nobbled. DJB has released a different set of constants (ECD25519) which is thought to be secure. I think it was LWN, there was an interesting article on crypto recently. Cheers, Wol
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
Dale wrote: > > > My take. Bad password, easy to guess, easy to crack because it is > simple or common; not very secure even if the password is changed > since one could use the old password in certain situations and get at > the data. Good strong password, changed or not; hard to crack even if > the whole drive is taken. > > Moral of the story. Have a good strong password and keep your mouth > shut about what the password is, unless you want that person to spill > the beans. Or you plan to knock them off later. ROFLMBO > > I'm not storing the secrets to some new weapon that will destroy the > world and everything on it, including the roaches. Well, that last > one might be OK. lol I just want it so that when I fall into the > cremation chamber or a cemetery plot, it won't be easy for a person to > access the drive. I'm good at the keeping password to myself bit. > Still thinking on killing all the roaches tho . I'd keep that secure > but I wouldn't mind being rid of those. :/ > > I think I need to watch a youtube video on this tho. I want to watch > a person not only install it but actually use it. For example, what > triggers it asking for a password and what does it look like? Is it > pretty fast, take a few seconds or what? I got a lot of questions but > they are things that can't be answered easily in text. Yea, gotta go > visit youtube. Test drive youtube-dl again. > > Dale > > :-) :-) OK. Found some videos and jeez, there is a ton of ways to use this. You can have a password, a key file, both or likely other options as well. On one video, the guy generated a key file with urandom that was 1024 characters. As he put it, try typing that in. Anyway, he put the file in / and used the file to mount the thing automatically after some setup. If however he goes to another puter, either you have to have that key file on it to or type in the password. He also set it up to mount automatically. Then I found out about crypttab. I don't have that on my system, yet. I was wondering how the system would know when a drive or partition was encrypted or not. Well, there you go. Once crypttab and fstab are set up, it can mount automatically. Well neato. ;-) When watching a video or two, I had to google some things. I run up on zulucrypt. It's a GUI that can handle several different encryption tools. Yes, one should at least be familiar with command line just in case the GUI doesn't work but having a GUI does make it easier. I still don't think I'm ready to try and do this on a hard drive. I'm certainly not going to do this with /home yet. Between this thread and a few videos, pictures says a lot, it's starting to make sense. I also noticed, it is really fast. One may need a stopwatch to even notice it is encrypted at all. I notice that one can use different encryption tools. I have Blowfish, Twofish, AES and sha*** as well as many others. I know some have been compromised. Which ones are known to be secure? I seem to recall that after Snowden some had to be redone and some new ones popped up to make sure they were secure. Thoughts?? Dale :-) :-)
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 06/06/2020 21:12, Rich Freeman wrote: To do this I'm just going to store my keys on the root filesystem so that the systems can be booted without interaction. Obviously if somebody compromises the files with the keys they can decrypt my drives, but this means that I just have to protect a couple of SD cards which contain my root filesystems, instead of worrying about each individual hard drive. The drives themselves end up being much more secure, because the password used to protect each drive is random and long - brute-forcing the password will be no easier than brute-forcing AES itself. This doesn't protect me at all if somebody breaks into my house and steals everything. On the other hand, if you're always present at boot, stick the keys on a USB that has to be in the laptop when it starts. If that's on your (physical) keyring, chances are it won't be compromised at the same time as the laptop - and hopefully the attacker won't realise it's needed for boot :-) (yes I know - security through obscurity is bad as your MAIN defence, but a few layers on top of something secure just makes life more of a pain for an attacker :-) Cheers, Wol
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
Sebastiaan L. Zoutendijk wrote: > Dear Dale, > > On Friday 5 June 2020, 11.37pm -0500, Dale wrote: > >> Is this a secure method or is there a more secure way? Is there any >> known issues with using this? Anyone here use this method? Keep in >> mind, LVM. BTFRS, SP?, may come later. > Another thing to keep in mind: if you only encrypt your /home, it is > possible that some data leak out of the encrypted volume. For example, > if you use swap, then the decrypted contents of /home residing in RAM > can be swapped out. If you want to protect yourself against that, you > will need to encrypt the swap volume as well. The same could happen with > temporary files, so /tmp and /var/tmp might also need special treatment. > Aside from encrypting, tmpfs is another possibility here. > This problem is similar, but slightly different, to that described > by J. Roeleveld. Here I am talking about the contents of your files > leaking, instead of the LUKS keys. > If you are going to encrypt multiple filesystems, you can either > make separate LUKS volumes for each of them (each LUKS volume being > inside a partition or LVM volume, for example), or you can create one > LUKS volume with several LVM volumes inside. > > Sincerely, > > Bas > > > -- > Sebastiaan L. Zoutendijk | slzoutend...@gmail.com > > That's something to think on. Right now, I'm going sorta simple and data that if I forget the password, I still got copies of. No big loss. Later on tho, that info could come in handy. I know a guy that has his locked down tight. I suspect everything is password protected. He was in China for a bit and it was sort of a requirement. Off to youtube. Dale :-) :-)
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
Rich Freeman wrote: > On Sat, Jun 6, 2020 at 8:47 PM Victor Ivanov wrote: >> On 06/06/2020 21:12, Rich Freeman wrote: >>> Maybe we're miscommunicating, but it seems like you're moving the >>> goalposts here. >>> ... >>> Your original point was, "The problem here is that a leaked header >>> immediately means a compromised volume." >> I believe we're on the same page and it's indeed due to miscommunication >> and I suspect this is where the main point of miscommunication lies. >> You're taking my statement out of context. No doubt, I most certainly >> could have phrased this part better and made it clearer. It may not have >> been obvious but that sentence was aimed specifically in the context >> where a weak password is used or, especially, when a password has been >> compromised and how being able to change said password might have little >> effect. In which case the point still stands - when a password is >> compromised, there is a possibility that changing said password may not >> necessarily be the end of the matter as the (old) header may or may not >> have been leaked too either as part of the same or a previous attack - >> not necessarily involving physical access. > I think we're on the same page and just talking past each other. I > didn't catch that as being the intended context, and in the scenario > you describe you are of course completely correct. > > Thanks for bringing this point up though, as it isn't really something > I'd given much thought to. > My take. Bad password, easy to guess, easy to crack because it is simple or common; not very secure even if the password is changed since one could use the old password in certain situations and get at the data. Good strong password, changed or not; hard to crack even if the whole drive is taken. Moral of the story. Have a good strong password and keep your mouth shut about what the password is, unless you want that person to spill the beans. Or you plan to knock them off later. ROFLMBO I'm not storing the secrets to some new weapon that will destroy the world and everything on it, including the roaches. Well, that last one might be OK. lol I just want it so that when I fall into the cremation chamber or a cemetery plot, it won't be easy for a person to access the drive. I'm good at the keeping password to myself bit. Still thinking on killing all the roaches tho . I'd keep that secure but I wouldn't mind being rid of those. :/ I think I need to watch a youtube video on this tho. I want to watch a person not only install it but actually use it. For example, what triggers it asking for a password and what does it look like? Is it pretty fast, take a few seconds or what? I got a lot of questions but they are things that can't be answered easily in text. Yea, gotta go visit youtube. Test drive youtube-dl again. Dale :-) :-)
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On Sat, Jun 6, 2020 at 8:47 PM Victor Ivanov wrote: > > On 06/06/2020 21:12, Rich Freeman wrote: > > Maybe we're miscommunicating, but it seems like you're moving the > > goalposts here. > > ... > > Your original point was, "The problem here is that a leaked header > > immediately means a compromised volume." > > I believe we're on the same page and it's indeed due to miscommunication > and I suspect this is where the main point of miscommunication lies. > You're taking my statement out of context. No doubt, I most certainly > could have phrased this part better and made it clearer. It may not have > been obvious but that sentence was aimed specifically in the context > where a weak password is used or, especially, when a password has been > compromised and how being able to change said password might have little > effect. In which case the point still stands - when a password is > compromised, there is a possibility that changing said password may not > necessarily be the end of the matter as the (old) header may or may not > have been leaked too either as part of the same or a previous attack - > not necessarily involving physical access. I think we're on the same page and just talking past each other. I didn't catch that as being the intended context, and in the scenario you describe you are of course completely correct. Thanks for bringing this point up though, as it isn't really something I'd given much thought to. -- Rich
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 06/06/2020 21:12, Rich Freeman wrote: > My point remains: > > The header is as secure as the disk. If the disk is secure against > brute-force, then so is the header. I never said otherwise. This was, in fact, explicitly stated in my concluding remarks of my original post where I say "If using a password, a strong password is a must." It was also emphasised once more in my response to your previous email, towards the end. But it also doesn't mean that one might not want to take additional preemptive steps following an attack, depending on the circumstances surrounding the attack. On 06/06/2020 21:12, Rich Freeman wrote: > Maybe we're miscommunicating, but it seems like you're moving the > goalposts here. > ... > Your original point was, "The problem here is that a leaked header > immediately means a compromised volume." I believe we're on the same page and it's indeed due to miscommunication and I suspect this is where the main point of miscommunication lies. You're taking my statement out of context. No doubt, I most certainly could have phrased this part better and made it clearer. It may not have been obvious but that sentence was aimed specifically in the context where a weak password is used or, especially, when a password has been compromised and how being able to change said password might have little effect. In which case the point still stands - when a password is compromised, there is a possibility that changing said password may not necessarily be the end of the matter as the (old) header may or may not have been leaked too either as part of the same or a previous attack - not necessarily involving physical access. On 06/06/2020 21:12, Rich Freeman wrote: > The whole reason you're using encryption is to > protect the data if your disk is stolen/etc. If they steal the disk > they get the header too. So, if a leaked header means that your > volume is compromised, then a stolen disk does so as well, which means > your encryption is worthless. This is probably another point of confusion. You make a strong case about a stolen drive, but this was never a case I specifically argued about. If the whole drive itself is stolen then there's little to discuss as there's nothing that can be done post facto to mitigate the circumstances, so any points raised re a leaked header or a change of password can be thrown out of the window and the only hope in such a scenario is that the password used is strong enough to safe guard against guessing attacks. So this case is largely irrelevant re some of the points I made. Perhaps it seems that the goalpost moves because I never set one - my original email was a _general discussion_ on the different considerations that one might want to have if using a password and how the ability to change a password may lead to a false sense of security. Clearly, at the end of the day how exactly all these points fit together is dependent on the threat model and what scenarios are more and less likely to happen, which I also pointed out but perhaps not as clearly as I should have. And so is the analysis, assessment of implications, and steps to take following an attack. The only time I referred to non-password methods (such as detached header) was in response to your previous email re header security. Retrospectively, I admit I too may have taken your point into a different, more general direction that takes the discussion beyond the scope of just passwords. For which I'm certainly liable. I hope this clarifies the matter. Best Regards, Victor signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
Dear Dale, On Friday 5 June 2020, 11.37pm -0500, Dale wrote: > Is this a secure method or is there a more secure way? Is there any > known issues with using this? Anyone here use this method? Keep in > mind, LVM. BTFRS, SP?, may come later. Another thing to keep in mind: if you only encrypt your /home, it is possible that some data leak out of the encrypted volume. For example, if you use swap, then the decrypted contents of /home residing in RAM can be swapped out. If you want to protect yourself against that, you will need to encrypt the swap volume as well. The same could happen with temporary files, so /tmp and /var/tmp might also need special treatment. Aside from encrypting, tmpfs is another possibility here. This problem is similar, but slightly different, to that described by J. Roeleveld. Here I am talking about the contents of your files leaking, instead of the LUKS keys. If you are going to encrypt multiple filesystems, you can either make separate LUKS volumes for each of them (each LUKS volume being inside a partition or LVM volume, for example), or you can create one LUKS volume with several LVM volumes inside. Sincerely, Bas -- Sebastiaan L. Zoutendijk | slzoutend...@gmail.com
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On Sat, Jun 6, 2020 at 3:38 PM Victor Ivanov wrote: > > On 06/06/2020 19:51, Rich Freeman wrote: > > Sure, if the attacker has a copy of the header they can spend as much > > time as they wish brute-forcing it. However, the same is true if they > > have the entire disk, and that is precisely the scenario we're trying > > to guard against. > > Not true. A key file stored outside the header is arguably way more > secure than a password - there's no longer a single point of failure. > Then there is also the option of having a detached LUKS header that is > never written to the block device in the first place which effectively > leaves the adversary with a stolen brick. Maybe we're miscommunicating, but it seems like you're moving the goalposts here. My point remains: The header is as secure as the disk. If the disk is secure against brute-force, then so is the header. Your original point was, "The problem here is that a leaked header immediately means a compromised volume." This makes no sense. The whole reason you're using encryption is to protect the data if your disk is stolen/etc. If they steal the disk they get the header too. So, if a leaked header means that your volume is compromised, then a stolen disk does so as well, which means your encryption is worthless. Now, obviously if you don't store the key in the header or store the header on the disk, that is more secure. However, if the key isn't in the header then a leaked header does not give an attacker any opportunity to brute-force it, because there is nothing to brute force. There are many things that can be done to make the disk more secure, like not using a memorable password or not storing the key on the disk. Obviously these sorts of solutions create additional problems with key management, and if you solve them incorrectly then you might actually reduce security. > I was merely emphasising the fact that > when using a password, having the facility to change the password can > give a false sense of security Sure, there is really no point in "rotating passwords" with LUKS. If somebody gets a copy of your disk then they effectively have a snapshot of your password. If you later change it the data they still have a copy of what it used to be. And if they do have the ability to periodically snapshot your header and you keep changing your password, then they can bruteforce all your passwords in parallel and if they obtain any of them they can decrypt the drive, unless you change the session key and re-encrypt the drive. With any of these things you have to understand your threat model. For example, on my distributed filesystem I'm moving to encrypted drives to protect me in case I have to dispose of a drive without the opportunity to wipe it first. To do this I'm just going to store my keys on the root filesystem so that the systems can be booted without interaction. Obviously if somebody compromises the files with the keys they can decrypt my drives, but this means that I just have to protect a couple of SD cards which contain my root filesystems, instead of worrying about each individual hard drive. The drives themselves end up being much more secure, because the password used to protect each drive is random and long - brute-forcing the password will be no easier than brute-forcing AES itself. This doesn't protect me at all if somebody breaks into my house and steals everything. -- Rich
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 06/06/2020 19:51, Rich Freeman wrote: > If you're talking about the drive header that is actually written to > disk, it is as secure as the entire drive is, since the drive contains > the header. I never said it was any less secure. It would be daft to even assume something like that as it's de facto the door to the encrypted data. The point I was making is simply that it increases the risk of data breach when a password is used, especially if (one of) the password(s) has been or is subsequently compromised. After all, it's difficult to remember passwords that are long enough and have high entropy. There are also the practicals inconveniences of having to type a long password. On 06/06/2020 19:51, Rich Freeman wrote: > If the password can be brute-forced then the encryption is worthless. > ... > If you're using LUKS the security of the system is only as secure as > your password(s). LUKS uses a random key to encrypt the drive, and it > applies many rounds of encryption to your password to protect the > session key. That will greatly slow down a brute force attack. > However, if your encryption key is "12345" then a brute force attack > is likely to succeed. Hence my previous point on ensuring a strong password. On 06/06/2020 19:51, Rich Freeman wrote: > Sure, if the attacker has a copy of the header they can spend as much > time as they wish brute-forcing it. However, the same is true if they > have the entire disk, and that is precisely the scenario we're trying > to guard against. Not true. A key file stored outside the header is arguably way more secure than a password - there's no longer a single point of failure. Then there is also the option of having a detached LUKS header that is never written to the block device in the first place which effectively leaves the adversary with a stolen brick. Are any of the "more secure" setups inconvenient to use? Sure. And I doubt the average person would be that paranoid to use a detached header, which by itself introduces a whole lot of issues like how do you store the header itself securely. I was merely emphasising the fact that when using a password, having the facility to change the password can give a false sense of security in a select number of cases, especially if the password being used prioritises memorability over sophistication, often leading to low entropy, and that this is particularly problematic for leaked passwords as brute-forcing high entropy passwords is not feasible anyway as per your own words. Regards, Victor signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 6 June 2020 17:07:37 CEST, Dale wrote: >antlists wrote: >> On 06/06/2020 08:49, Dale wrote: >>> First drive seems to have died. Got part way copying files and >>> things got interesting. When checking smartctrl, it even puked on >my >>> keyboard. Drive only had a few hundred hours on it so maybe the >>> drive was iffy from the start or that enclosure did damage somehow. >>> Either way, drive two being tested. Running smartctrl test first >and >>> then restart from scratch and fill it up with files or something. >> >> Take it out the enclosure and it might be fine. I regularly have >> drives "die" in an enclosure and then work fine when I take them out. >> >> That's why I bought an open bay - it's eSATA and the only bit of the >> drive that is enclosed is the connectors. Keeps the drive from >cooking >> ... >> >> Oh - the other thing - if it's PMR and you're copying files onto it, >> expect a puke! That thing on WD Reds going PMR, I copied most of that >> on to the linux raid mailing list and the general feeling I get is >> "PMR is bad". >> >> Cheers, >> Wol >> >> > > >I may test it later by connecting it directly to the SATA card but I >suspect the drive is bad. I managed to get the selftest data from the >drive once after several tries and it had a lot of failures. It had >more than one type of error as well. At this point, I don't see me >trusting any data on it anyway. The first type of enclosure I think is >just cheaply made. The new types, rock solid. > >Read other replies, yea, SMR isn't good for my use case. I do have a >external drive that I do incremental backups on that is SMR. It works >OK but the other day I had a rather large list of new files. It got a >little slow toward the end. I suspect its PMR section got full. It >eventually finished but I did notice a slow down, a good sized one. >Avoiding SMR like its the plague. > >Reading other replies, some two or three times. ;-) Lots of good >info. I'm wanting to encrypt /home but also want another drive that >when I'm gone, it is no longer accessible. A person can dd the drive >or >something and start over but not access the data on it. Right now, the >3TB will be more than enough for that. > >Thanks to all for the info. Getting new reading glasses today. Should >have new prescription glasses this coming week, hope anyway. Sometimes >it takes a while to get the lenses made. They have to use a really >complicated process. I think each lens costs around $200. My eyes >aren't much to work with. Basically, I'm more cyclops, just in the >right place. :/ > >Dale > >:-) :-) One thing to add to this: Encryption keys are stored in memory (or else it doesn't work) This can also be leaked to disk (SWAP, for instance). I tend to either encrypt it all (apart from the boot partition) or don't bother at all. For me, it depends in how and where the system is used. Laptops travel with me and if they can be physically compromised, they get reinstalled with a fully new encryption key. Normally, the laptop is fully switched off when nog in use and the boot process, on the encrypted section, will check the boot partition with a known clean state. If it fails that check, there is a big warning and several services will fail to start. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On Sat, Jun 6, 2020 at 10:07 AM Victor Ivanov wrote: > > The problem here is that a leaked header immediately means a compromised > volume. An adversary who gets hold of the header can now spend as much > time as they would like to brute force a password (depending on password > strength) and derive the encryption key. Or if they have an (older) copy > of the header with a leaked password before it was changed they can get > hold of the encryption key with virtually no effort at all by using said > password. The only solution to a compromised header is full > re-encryption. Even having a rolling password won't change that. If you're talking about the drive header that is actually written to disk, it is as secure as the entire drive is, since the drive contains the header. The whole point of full-disk encryption is to keep the contents of the disk secure even if you lose physical possession of the disk. If the password can be brute-forced then the encryption is worthless. Sure, if the attacker has a copy of the header they can spend as much time as they wish brute-forcing it. However, the same is true if they have the entire disk, and that is precisely the scenario we're trying to guard against. If you're using LUKS the security of the system is only as secure as your password(s). LUKS uses a random key to encrypt the drive, and it applies many rounds of encryption to your password to protect the session key. That will greatly slow down a brute force attack. However, if your encryption key is "12345" then a brute force attack is likely to succeed. -- Rich
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
antlists wrote: > On 06/06/2020 08:49, Dale wrote: >> First drive seems to have died. Got part way copying files and >> things got interesting. When checking smartctrl, it even puked on my >> keyboard. Drive only had a few hundred hours on it so maybe the >> drive was iffy from the start or that enclosure did damage somehow. >> Either way, drive two being tested. Running smartctrl test first and >> then restart from scratch and fill it up with files or something. > > Take it out the enclosure and it might be fine. I regularly have > drives "die" in an enclosure and then work fine when I take them out. > > That's why I bought an open bay - it's eSATA and the only bit of the > drive that is enclosed is the connectors. Keeps the drive from cooking > ... > > Oh - the other thing - if it's PMR and you're copying files onto it, > expect a puke! That thing on WD Reds going PMR, I copied most of that > on to the linux raid mailing list and the general feeling I get is > "PMR is bad". > > Cheers, > Wol > > I may test it later by connecting it directly to the SATA card but I suspect the drive is bad. I managed to get the selftest data from the drive once after several tries and it had a lot of failures. It had more than one type of error as well. At this point, I don't see me trusting any data on it anyway. The first type of enclosure I think is just cheaply made. The new types, rock solid. Read other replies, yea, SMR isn't good for my use case. I do have a external drive that I do incremental backups on that is SMR. It works OK but the other day I had a rather large list of new files. It got a little slow toward the end. I suspect its PMR section got full. It eventually finished but I did notice a slow down, a good sized one. Avoiding SMR like its the plague. Reading other replies, some two or three times. ;-) Lots of good info. I'm wanting to encrypt /home but also want another drive that when I'm gone, it is no longer accessible. A person can dd the drive or something and start over but not access the data on it. Right now, the 3TB will be more than enough for that. Thanks to all for the info. Getting new reading glasses today. Should have new prescription glasses this coming week, hope anyway. Sometimes it takes a while to get the lenses made. They have to use a really complicated process. I think each lens costs around $200. My eyes aren't much to work with. Basically, I'm more cyclops, just in the right place. :/ Dale :-) :-)
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 6/6/20 10:10 AM, Rich Freeman wrote: One of the problems with drive-managed SMR is that it can seem to be ok when you're just doing light duty access, and then when one of your other drives fails and you're doing a zfs resilver the SMR drive starts performing an order of magnitude or more worse and you find yourself painted in to a corner. The first time I read that, I saw "and you find yourself pained into a corner." I suppose that's also true.
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 06/06/2020 14:57, antlists wrote: Oh - the other thing - if it's PMR and you're copying files onto it, expect a puke! That thing on WD Reds going PMR, I copied most of that on to the linux raid mailing list and the general feeling I get is "PMR is bad". Whoops have I got my PMR and SMR mixed up ... ? Cheers, Wol
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 06/06/2020 11:32, Michael wrote: Of particular interest to me is recovery of encrypted files/partitions, using a different installation than the original. Having to keep a copy of the original installation kernel keys for ext4 with any data backups and additionally remembering to refresh them every time a new kernel is installed, adds to the user-un-friendliness of an encryption method. Just to throw a BIG monkey-wrench into the picture, be careful if you install or upgrade any operating system ... One of the problems that crops up every now and then on the raid mailing list is "intelligent" utilities writing an MBR or GPT without asking... And the latest one was an upgrade to debian. Something seemed to have written a GPT to /dev/md0 which obviously didn't do the array much good ... it always used to be just writing to a hard drive like /dev/sdX and now it seems to be writing to other block devices as well :-( Cheers, Wol
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On Sat, Jun 6, 2020 at 9:57 AM antlists wrote: > > Oh - the other thing - if it's PMR and you're copying files onto it, > expect a puke! That thing on WD Reds going PMR, I copied most of that on > to the linux raid mailing list and the general feeling I get is "PMR is > bad". > You're mixing up PMR/SMR there. PMR=CMR=the way things have been for the last few decades. SMR is the new shingled technology. There is nothing wrong with it per se, but it is NOT a drop-in substitute for all applications. It works best if it is host-managed with a filesystem or application that was engineered specifically to use it. If you tried to swap a hard drive with a tape drive you'd have terrible results 99% of the time, but that doesn't make tape drives a bad thing. They just aren't drop-in substitutes for hard drives and you need to use them with appropriate applications. One of the problems with drive-managed SMR is that it can seem to be ok when you're just doing light duty access, and then when one of your other drives fails and you're doing a zfs resilver the SMR drive starts performing an order of magnitude or more worse and you find yourself painted in to a corner. -- Rich
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 06/06/2020 05:37, Dale wrote: > One other question, can one change the password every once in a while? > Or once set, you stuck with it from then on? A point I forgot to mention in my previous email is regarding passwords. While most encryption methods will allow for a password change (CryFS doesn't) be mindful that with methods used to encrypt large amounts of data the actual encryption key is generated once at volume creation time and is never changed. A password is only used to decrypt/derive the key itself. This is purely due to practical considerations. If you change the actual encryption key, then all encrypted data will have to be decrypted with the old key and re-encrypted with the new key. This may be a perfectly reasonable thing to do for file-based encryption or small amounts of data where a password change also means a key change, but is completely infeasible for larger scale volume encryption that may contain hundreds of GB of data. Thus, if a password has been compromised, it is not unreasonable to assume that anyone who knows the password and has had access to the encrypted volume might be able to get [or has already got] hold of the encryption key itself once the volume was opened. Hence, changing a leaked password doesn't make a compromised volume secure again. Of course, if it can be safely determined that a leaked password has not yet been used to access the volume, a swift preemptive change of the password will retain security. There is one exception to this where an adversary has a copy of the header (or similar) of the encryption volume. Here's a quick example with LUKS. A LUKS volume has a ~2MB header which stores all (hashed) passwords and the password-encrypted decryption key. The header can be read and stored separately. In fact, it's good practice for one to back up the header in case it ever gets corrupted (a corrupt header often means saying goodbye to your data w/o a backup). The problem here is that a leaked header immediately means a compromised volume. An adversary who gets hold of the header can now spend as much time as they would like to brute force a password (depending on password strength) and derive the encryption key. Or if they have an (older) copy of the header with a leaked password before it was changed they can get hold of the encryption key with virtually no effort at all by using said password. The only solution to a compromised header is full re-encryption. Even having a rolling password won't change that. Bottom line wrt passwords, one should not rely on or assume that having the facility to change a password will keep their data safe. If using a password, a strong password is a must. Again, it boils down to the usual trade-offs, likelihood of physical access, etc, etc. But I thought it an important point to note, as a surprisingly large number of people I have spoken to before seem to be unaware of this caveat (I'm not suggesting you are one of them). Regards, Victor signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 06/06/2020 08:49, Dale wrote: First drive seems to have died. Got part way copying files and things got interesting. When checking smartctrl, it even puked on my keyboard. Drive only had a few hundred hours on it so maybe the drive was iffy from the start or that enclosure did damage somehow. Either way, drive two being tested. Running smartctrl test first and then restart from scratch and fill it up with files or something. Take it out the enclosure and it might be fine. I regularly have drives "die" in an enclosure and then work fine when I take them out. That's why I bought an open bay - it's eSATA and the only bit of the drive that is enclosed is the connectors. Keeps the drive from cooking ... Oh - the other thing - if it's PMR and you're copying files onto it, expect a puke! That thing on WD Reds going PMR, I copied most of that on to the linux raid mailing list and the general feeling I get is "PMR is bad". Cheers, Wol
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 06/06/2020 12:05, Rich Freeman wrote: > Usually you want the encryption as close to the disk as possible > because if somebody gets your disk it gives them less to work with. > They don't know that you have a logical volume called "home" on it, > and so on. I concur with Rich on this. One of the key considerations for encryption is how much is it that want encrypted and what metadata are you willing to have publicly visible. As an extreme example, you can think of the simplest form of encryption - on a per file basis. Contents are encrypted, but things like file name and size, creation and modification timestamps, filesystem directory tree are all available to an imaginary adversary. One can further deduce information about the file by its extension, and use all of that to come up with a good attack strategy for decryption. In other cases, contents may be irrelevant to an adversary, as they can already infer a lot about a person - if that's what they are interested in - from directory listings etc, depending on what they are looking for. Filesystem-based support for encryption will inevitably leak some metadata. On the other extreme you have block-level encryption which hides all contents, including filesystem information, for a given block device. With multiple physical partitions, however, this too can leak a degree of information. For example, it would be reasonable to assume that the largest partition is a person's "storage" partition. So attempts can be targeted at that block device, ignoring all other ones. It's also cumbersome to manage as unlocking multiple block devices would require multiple password entries unless a common key file is used. Michael mentioned CryFS which is kind of in the middle. It's an "overlay" filesystem, anything within a CyFS volume is encrypted into fixed-size (e.g. 64KB) block files. This includes file names and all file meta data, directory structure, etc., and all encrypted content can be interleaved across different blocks. However, depending on the size of the average files you have, it can have a significant overhead where contents of the encrypted CryFS volume can be considerably larger than the actual contents of your encrypted data. This can addressed, to a degree, by playing with the block size. Smaller block size will reduce overhead but will increase the number of block-sized encrypted files on the actual filesystem, which can eat up a lot of INodes. The downside is, the block size cannot be changed once a CryFS volume is created, and neither can the password. These require creating a new CryFS volume and migrating your files. As such, my personal view on the matter is that CryFS is usually good for small volumes and is indeed very good for securing content on cloud services like Dropbox that do not normally encrypt your data. Personally, I have been using LUKS and LVM for many years. On OS-bearing drives I would have a non-encrypted /boot partition for the kernel and initrd whilst the remainder of the drive would be a LUKS encrypted block device - two partitions in total (3 for a GPT system). Within the latter, I would create LVM partitions as I desire (including OS root). LUKS has 8 slots that can hold up to 8 passwords or key files (or any combination of both) at a time. This set up is pretty much zero-leak. For an external drive I would use LUKS across the whole drive. Note in the former case the /boot partition is still vulnerable and a compromised kernel image could lead to a leaked LUKS password once the LUKS block device is opened. Signing the kernel and its modules is one possible solution. At the end of the day, which method you choose is based on a balancing trade-offs and likelihoods of an attack. That said, virtually all modern processors in the last 10y or so have native hardware extensions for accelerating common encryption algorithms such as AES. As such, having full-disk encryption has very little performance overhead on read/write speeds. You can use "cryptsetup benchmark" to see upper bound estimates of read/write speeds. The values shown are in-memory estimates and are thus CPU/memory bottlenecked. For example, on one of my systems with a mobile i7 CPU AES with 512b key (maximum supported by LUKS with AES) shows about 2,000MB/s for both read/write. This is more than enough to saturate a SATA3 drive's 6Gb/s best-case data rate as well as a lot of current generation consumer grade NVMe drives. In summary (and final remarks): * Performance overhead these days is largely irrelevant for common use cases * Use case (e.g. cloud storage or local drives) and what is left behind unencrypted is a key consideration when choosing a method. * Generally, block-level encryption is preferable to filesystem encryption * LUKS is Linux-specific. If cross-platform compatibility is required this won't be a good choice. Then again, so is LVM. * TrueCrypt is obsolete - do not use this if you can avoid it * VeraCrypt (its successor) is cross platform.
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On Sat, Jun 6, 2020 at 3:49 AM Dale wrote: > > Thanks for both replies. I found one other Gentoo one but it was encrypting > the whole thing, /boot and all, plus they used efi. I didn't find the one > you linked too. The Gentoo guide that was linked uses an example of encrypting a partition. This is just block device layering though. You can probably stack them anyway you want as long as the various services/etc are set up to load in the right order. You could encrypt the disk and stick LVM on it. Or you could stick LVM on the disk and use LUKS on the logical volumes inside. Usually you want the encryption as close to the disk as possible because if somebody gets your disk it gives them less to work with. They don't know that you have a logical volume called "home" on it, and so on. Some more recent filesystems have encryption built into them, like zfs/etc (well, the most recent version). There can be benefits to doing it this way as the filesystem might be better able to cope with data corruption if there is some problem later. However, you can always stick dm-crypt/LUKS/etc on a physical disk and then just treat the resulting block device as if it were your disk. dm-crypt itself has very little overhead. As you pointed out, the main thing you do have to be careful about is /boot. As long as you're using an appropriate initramfs you can do just about anything else after that, but your firmware isn't going to go prompting for your LUKS password/etc. I should mention it for completeness, but I don't recommend this: you can also use ATA security with a password that unlocks the hard drive. In theory the drive should be encrypting its data when security is in use, and it makes the drive inaccessible without the password. The problem is that this is generally not audited by anybody and you have no way of knowing what the drive is doing or whether it is a secure implementation. But, I mention it for completeness, because it can be done on Linux. -- Rich
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On Saturday, 6 June 2020 08:49:54 BST Dale wrote: > J. Roeleveld wrote: > > On 6 June 2020 06:37:23 CEST, Dale wrote: > >> Howdy, > >> > >> I think I got a old 3TB hard drive to work. After dd'ing it, redoing > >> partitions and such, it seems to be working. Right now, I'm copying a > >> bunch of data to it to see how it holds up. Oh, it's a PMR drive too. > >> lol Once I'm pretty sure it is alive and working well, I want to play > >> with encryption. At some point, I plan to encrypt /home. I found a > >> bit > >> of info with startpage but some is dated. This is one link that seems > >> to be from this year, at least updated this year. > >> > >> https://linoxide.com/linux-how-to/encrypt-linux-filesystem/ > >> > >> It seems like a nice one since it has commands and what it should look > >> like when it is performing the commands. I like knowing what I'm doing > >> sort of matches what the howto shows. It also seems to use LVM which I > >> will be using as well. I think I can follow that and get a working > >> encrypted storage. Later, I can attempt this on /home without doing it > >> blind. I also have the options in the kernel as well. I'll post them > >> at the bottom. I enabled quite a lot a while back. ;-) > >> > >> Is this a secure method or is there a more secure way? Is there any > >> known issues with using this? Anyone here use this method? Keep in > >> mind, LVM. BTFRS, SP?, may come later. > >> > >> One other question, can one change the password every once in a while? > >> Or once set, you stuck with it from then on? > >> > >> If anyone has links to even better howtos, I'd love to check them out. > >> > >> Dale > >> > >> :-) :-) > >> > >> root@fireball / # zcat /proc/config.gz | grep crypt | grep =y > >> CONFIG_ARCH_HAS_MEM_ENCRYPT=y > >> CONFIG_DM_CRYPT=y > >> CONFIG_CRYPTO=y > >> CONFIG_CRYPTO_ALGAPI=y > >> CONFIG_CRYPTO_ALGAPI2=y > >> CONFIG_CRYPTO_AEAD=y > >> CONFIG_CRYPTO_AEAD2=y > >> CONFIG_CRYPTO_SKCIPHER=y > >> CONFIG_CRYPTO_SKCIPHER2=y > >> CONFIG_CRYPTO_HASH=y > >> CONFIG_CRYPTO_HASH2=y > >> CONFIG_CRYPTO_RNG=y > >> CONFIG_CRYPTO_RNG2=y > >> CONFIG_CRYPTO_RNG_DEFAULT=y > >> CONFIG_CRYPTO_AKCIPHER2=y > >> CONFIG_CRYPTO_AKCIPHER=y > >> CONFIG_CRYPTO_KPP2=y > >> CONFIG_CRYPTO_ACOMP2=y > >> CONFIG_CRYPTO_MANAGER=y > >> CONFIG_CRYPTO_MANAGER2=y > >> CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y > >> CONFIG_CRYPTO_GF128MUL=y > >> CONFIG_CRYPTO_NULL=y > >> CONFIG_CRYPTO_NULL2=y > >> CONFIG_CRYPTO_CRYPTD=y > >> CONFIG_CRYPTO_AUTHENC=y > >> CONFIG_CRYPTO_SIMD=y > >> CONFIG_CRYPTO_GLUE_HELPER_X86=y > >> CONFIG_CRYPTO_RSA=y > >> CONFIG_CRYPTO_ECHAINIV=y > >> CONFIG_CRYPTO_CBC=y > >> CONFIG_CRYPTO_ECB=y > >> CONFIG_CRYPTO_LRW=y > >> CONFIG_CRYPTO_XTS=y > >> CONFIG_CRYPTO_NHPOLY1305=y > >> CONFIG_CRYPTO_NHPOLY1305_SSE2=y > >> CONFIG_CRYPTO_NHPOLY1305_AVX2=y > >> CONFIG_CRYPTO_ESSIV=y > >> CONFIG_CRYPTO_HMAC=y > >> CONFIG_CRYPTO_CRC32C=y > >> CONFIG_CRYPTO_XXHASH=y > >> CONFIG_CRYPTO_BLAKE2B=y > >> CONFIG_CRYPTO_CRCT10DIF=y > >> CONFIG_CRYPTO_MD5=y > >> CONFIG_CRYPTO_RMD128=y > >> CONFIG_CRYPTO_RMD160=y > >> CONFIG_CRYPTO_RMD256=y > >> CONFIG_CRYPTO_RMD320=y > >> CONFIG_CRYPTO_SHA1=y > >> CONFIG_CRYPTO_SHA1_SSSE3=y > >> CONFIG_CRYPTO_SHA256_SSSE3=y > >> CONFIG_CRYPTO_SHA512_SSSE3=y > >> CONFIG_CRYPTO_SHA256=y > >> CONFIG_CRYPTO_SHA512=y > >> CONFIG_CRYPTO_WP512=y > >> CONFIG_CRYPTO_AES=y > >> CONFIG_CRYPTO_AES_TI=y > >> CONFIG_CRYPTO_ARC4=y > >> CONFIG_CRYPTO_BLOWFISH=y > >> CONFIG_CRYPTO_BLOWFISH_COMMON=y > >> CONFIG_CRYPTO_BLOWFISH_X86_64=y > >> CONFIG_CRYPTO_CAMELLIA=y > >> CONFIG_CRYPTO_CAMELLIA_X86_64=y > >> CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=y > >> CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=y > >> CONFIG_CRYPTO_DES=y > >> CONFIG_CRYPTO_SERPENT=y > >> CONFIG_CRYPTO_SERPENT_SSE2_X86_64=y > >> CONFIG_CRYPTO_TWOFISH=y > >> CONFIG_CRYPTO_TWOFISH_COMMON=y > >> CONFIG_CRYPTO_TWOFISH_X86_64=y > >> CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=y > >> CONFIG_CRYPTO_ANSI_CPRNG=y > >> CONFIG_CRYPTO_DRBG_MENU=y > >> CONFIG_CRYPTO_DRBG_HMAC=y > >> CONFIG_CRYPTO_DRBG=y > >> CONFIG_CRYPTO_JITTERENTROPY=y > >> CONFIG_CRYPTO_USER_API=y > >> CONFIG_CRYPTO_USER_API_HASH=y > >> CONFIG_CRYPTO_USER_API_SKCIPHER=y > >> CONFIG_CRYPTO_USER_API_RNG=y > >> CONFIG_CRYPTO_LIB_AES=y > >> CONFIG_CRYPTO_LIB_ARC4=y > >> CONFIG_CRYPTO_LIB_DES=y > >> CONFIG_CRYPTO_LIB_POLY1305_GENERIC=y > >> CONFIG_CRYPTO_LIB_SHA256=y > >> CONFIG_CRYPTO_HW=y > >> root@fireball / # > >> > >> Just wanted to have a few extras. ROFL Nowt wrong with that, as long as you remember MD5, SHA1 and some other offerings from your list above have been compromised and should not be used if strong encryption/integrity is required. > > A gentoo centric manual/howto: > > > > https://wiki.gentoo.org/wiki/Dm-crypt > > Thanks for both replies. I found one other Gentoo one but it was > encrypting the whole thing, /boot and all, plus they used efi. I didn't > find the one you linked too. > > First drive seems to have died. Got
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
J. Roeleveld wrote: > On 6 June 2020 06:37:23 CEST, Dale wrote: >> Howdy, >> >> I think I got a old 3TB hard drive to work. After dd'ing it, redoing >> partitions and such, it seems to be working. Right now, I'm copying a >> bunch of data to it to see how it holds up. Oh, it's a PMR drive too. >> lol Once I'm pretty sure it is alive and working well, I want to play >> with encryption. At some point, I plan to encrypt /home. I found a >> bit >> of info with startpage but some is dated. This is one link that seems >> to be from this year, at least updated this year. >> >> https://linoxide.com/linux-how-to/encrypt-linux-filesystem/ >> >> It seems like a nice one since it has commands and what it should look >> like when it is performing the commands. I like knowing what I'm doing >> sort of matches what the howto shows. It also seems to use LVM which I >> will be using as well. I think I can follow that and get a working >> encrypted storage. Later, I can attempt this on /home without doing it >> blind. I also have the options in the kernel as well. I'll post them >> at the bottom. I enabled quite a lot a while back. ;-) >> >> Is this a secure method or is there a more secure way? Is there any >> known issues with using this? Anyone here use this method? Keep in >> mind, LVM. BTFRS, SP?, may come later. >> >> One other question, can one change the password every once in a while? >> Or once set, you stuck with it from then on? >> >> If anyone has links to even better howtos, I'd love to check them out. >> >> Dale >> >> :-) :-) >> >> >> root@fireball / # zcat /proc/config.gz | grep crypt | grep =y >> CONFIG_ARCH_HAS_MEM_ENCRYPT=y >> CONFIG_DM_CRYPT=y >> CONFIG_CRYPTO=y >> CONFIG_CRYPTO_ALGAPI=y >> CONFIG_CRYPTO_ALGAPI2=y >> CONFIG_CRYPTO_AEAD=y >> CONFIG_CRYPTO_AEAD2=y >> CONFIG_CRYPTO_SKCIPHER=y >> CONFIG_CRYPTO_SKCIPHER2=y >> CONFIG_CRYPTO_HASH=y >> CONFIG_CRYPTO_HASH2=y >> CONFIG_CRYPTO_RNG=y >> CONFIG_CRYPTO_RNG2=y >> CONFIG_CRYPTO_RNG_DEFAULT=y >> CONFIG_CRYPTO_AKCIPHER2=y >> CONFIG_CRYPTO_AKCIPHER=y >> CONFIG_CRYPTO_KPP2=y >> CONFIG_CRYPTO_ACOMP2=y >> CONFIG_CRYPTO_MANAGER=y >> CONFIG_CRYPTO_MANAGER2=y >> CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y >> CONFIG_CRYPTO_GF128MUL=y >> CONFIG_CRYPTO_NULL=y >> CONFIG_CRYPTO_NULL2=y >> CONFIG_CRYPTO_CRYPTD=y >> CONFIG_CRYPTO_AUTHENC=y >> CONFIG_CRYPTO_SIMD=y >> CONFIG_CRYPTO_GLUE_HELPER_X86=y >> CONFIG_CRYPTO_RSA=y >> CONFIG_CRYPTO_ECHAINIV=y >> CONFIG_CRYPTO_CBC=y >> CONFIG_CRYPTO_ECB=y >> CONFIG_CRYPTO_LRW=y >> CONFIG_CRYPTO_XTS=y >> CONFIG_CRYPTO_NHPOLY1305=y >> CONFIG_CRYPTO_NHPOLY1305_SSE2=y >> CONFIG_CRYPTO_NHPOLY1305_AVX2=y >> CONFIG_CRYPTO_ESSIV=y >> CONFIG_CRYPTO_HMAC=y >> CONFIG_CRYPTO_CRC32C=y >> CONFIG_CRYPTO_XXHASH=y >> CONFIG_CRYPTO_BLAKE2B=y >> CONFIG_CRYPTO_CRCT10DIF=y >> CONFIG_CRYPTO_MD5=y >> CONFIG_CRYPTO_RMD128=y >> CONFIG_CRYPTO_RMD160=y >> CONFIG_CRYPTO_RMD256=y >> CONFIG_CRYPTO_RMD320=y >> CONFIG_CRYPTO_SHA1=y >> CONFIG_CRYPTO_SHA1_SSSE3=y >> CONFIG_CRYPTO_SHA256_SSSE3=y >> CONFIG_CRYPTO_SHA512_SSSE3=y >> CONFIG_CRYPTO_SHA256=y >> CONFIG_CRYPTO_SHA512=y >> CONFIG_CRYPTO_WP512=y >> CONFIG_CRYPTO_AES=y >> CONFIG_CRYPTO_AES_TI=y >> CONFIG_CRYPTO_ARC4=y >> CONFIG_CRYPTO_BLOWFISH=y >> CONFIG_CRYPTO_BLOWFISH_COMMON=y >> CONFIG_CRYPTO_BLOWFISH_X86_64=y >> CONFIG_CRYPTO_CAMELLIA=y >> CONFIG_CRYPTO_CAMELLIA_X86_64=y >> CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=y >> CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=y >> CONFIG_CRYPTO_DES=y >> CONFIG_CRYPTO_SERPENT=y >> CONFIG_CRYPTO_SERPENT_SSE2_X86_64=y >> CONFIG_CRYPTO_TWOFISH=y >> CONFIG_CRYPTO_TWOFISH_COMMON=y >> CONFIG_CRYPTO_TWOFISH_X86_64=y >> CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=y >> CONFIG_CRYPTO_ANSI_CPRNG=y >> CONFIG_CRYPTO_DRBG_MENU=y >> CONFIG_CRYPTO_DRBG_HMAC=y >> CONFIG_CRYPTO_DRBG=y >> CONFIG_CRYPTO_JITTERENTROPY=y >> CONFIG_CRYPTO_USER_API=y >> CONFIG_CRYPTO_USER_API_HASH=y >> CONFIG_CRYPTO_USER_API_SKCIPHER=y >> CONFIG_CRYPTO_USER_API_RNG=y >> CONFIG_CRYPTO_LIB_AES=y >> CONFIG_CRYPTO_LIB_ARC4=y >> CONFIG_CRYPTO_LIB_DES=y >> CONFIG_CRYPTO_LIB_POLY1305_GENERIC=y >> CONFIG_CRYPTO_LIB_SHA256=y >> CONFIG_CRYPTO_HW=y >> root@fireball / # >> >> Just wanted to have a few extras. ROFL > A gentoo centric manual/howto: > > https://wiki.gentoo.org/wiki/Dm-crypt > Thanks for both replies. I found one other Gentoo one but it was encrypting the whole thing, /boot and all, plus they used efi. I didn't find the one you linked too. First drive seems to have died. Got part way copying files and things got interesting. When checking smartctrl, it even puked on my keyboard. Drive only had a few hundred hours on it so maybe the drive was iffy from the start or that enclosure did damage somehow. Either way, drive two being tested. Running smartctrl test first and then restart from scratch and fill it up with files or something. Thanks much. Dale :-) :-)
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 6 June 2020 06:37:23 CEST, Dale wrote: >Howdy, > >I think I got a old 3TB hard drive to work. After dd'ing it, redoing >partitions and such, it seems to be working. Right now, I'm copying a >bunch of data to it to see how it holds up. Oh, it's a PMR drive too. >lol Once I'm pretty sure it is alive and working well, I want to play >with encryption. At some point, I plan to encrypt /home. I found a >bit >of info with startpage but some is dated. This is one link that seems >to be from this year, at least updated this year. > >https://linoxide.com/linux-how-to/encrypt-linux-filesystem/ > >It seems like a nice one since it has commands and what it should look >like when it is performing the commands. I like knowing what I'm doing >sort of matches what the howto shows. It also seems to use LVM which I >will be using as well. I think I can follow that and get a working >encrypted storage. Later, I can attempt this on /home without doing it >blind. I also have the options in the kernel as well. I'll post them >at the bottom. I enabled quite a lot a while back. ;-) > >Is this a secure method or is there a more secure way? Is there any >known issues with using this? Anyone here use this method? Keep in >mind, LVM. BTFRS, SP?, may come later. > >One other question, can one change the password every once in a while? >Or once set, you stuck with it from then on? > >If anyone has links to even better howtos, I'd love to check them out. > >Dale > >:-) :-) > > >root@fireball / # zcat /proc/config.gz | grep crypt | grep =y >CONFIG_ARCH_HAS_MEM_ENCRYPT=y >CONFIG_DM_CRYPT=y >CONFIG_CRYPTO=y >CONFIG_CRYPTO_ALGAPI=y >CONFIG_CRYPTO_ALGAPI2=y >CONFIG_CRYPTO_AEAD=y >CONFIG_CRYPTO_AEAD2=y >CONFIG_CRYPTO_SKCIPHER=y >CONFIG_CRYPTO_SKCIPHER2=y >CONFIG_CRYPTO_HASH=y >CONFIG_CRYPTO_HASH2=y >CONFIG_CRYPTO_RNG=y >CONFIG_CRYPTO_RNG2=y >CONFIG_CRYPTO_RNG_DEFAULT=y >CONFIG_CRYPTO_AKCIPHER2=y >CONFIG_CRYPTO_AKCIPHER=y >CONFIG_CRYPTO_KPP2=y >CONFIG_CRYPTO_ACOMP2=y >CONFIG_CRYPTO_MANAGER=y >CONFIG_CRYPTO_MANAGER2=y >CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y >CONFIG_CRYPTO_GF128MUL=y >CONFIG_CRYPTO_NULL=y >CONFIG_CRYPTO_NULL2=y >CONFIG_CRYPTO_CRYPTD=y >CONFIG_CRYPTO_AUTHENC=y >CONFIG_CRYPTO_SIMD=y >CONFIG_CRYPTO_GLUE_HELPER_X86=y >CONFIG_CRYPTO_RSA=y >CONFIG_CRYPTO_ECHAINIV=y >CONFIG_CRYPTO_CBC=y >CONFIG_CRYPTO_ECB=y >CONFIG_CRYPTO_LRW=y >CONFIG_CRYPTO_XTS=y >CONFIG_CRYPTO_NHPOLY1305=y >CONFIG_CRYPTO_NHPOLY1305_SSE2=y >CONFIG_CRYPTO_NHPOLY1305_AVX2=y >CONFIG_CRYPTO_ESSIV=y >CONFIG_CRYPTO_HMAC=y >CONFIG_CRYPTO_CRC32C=y >CONFIG_CRYPTO_XXHASH=y >CONFIG_CRYPTO_BLAKE2B=y >CONFIG_CRYPTO_CRCT10DIF=y >CONFIG_CRYPTO_MD5=y >CONFIG_CRYPTO_RMD128=y >CONFIG_CRYPTO_RMD160=y >CONFIG_CRYPTO_RMD256=y >CONFIG_CRYPTO_RMD320=y >CONFIG_CRYPTO_SHA1=y >CONFIG_CRYPTO_SHA1_SSSE3=y >CONFIG_CRYPTO_SHA256_SSSE3=y >CONFIG_CRYPTO_SHA512_SSSE3=y >CONFIG_CRYPTO_SHA256=y >CONFIG_CRYPTO_SHA512=y >CONFIG_CRYPTO_WP512=y >CONFIG_CRYPTO_AES=y >CONFIG_CRYPTO_AES_TI=y >CONFIG_CRYPTO_ARC4=y >CONFIG_CRYPTO_BLOWFISH=y >CONFIG_CRYPTO_BLOWFISH_COMMON=y >CONFIG_CRYPTO_BLOWFISH_X86_64=y >CONFIG_CRYPTO_CAMELLIA=y >CONFIG_CRYPTO_CAMELLIA_X86_64=y >CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=y >CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=y >CONFIG_CRYPTO_DES=y >CONFIG_CRYPTO_SERPENT=y >CONFIG_CRYPTO_SERPENT_SSE2_X86_64=y >CONFIG_CRYPTO_TWOFISH=y >CONFIG_CRYPTO_TWOFISH_COMMON=y >CONFIG_CRYPTO_TWOFISH_X86_64=y >CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=y >CONFIG_CRYPTO_ANSI_CPRNG=y >CONFIG_CRYPTO_DRBG_MENU=y >CONFIG_CRYPTO_DRBG_HMAC=y >CONFIG_CRYPTO_DRBG=y >CONFIG_CRYPTO_JITTERENTROPY=y >CONFIG_CRYPTO_USER_API=y >CONFIG_CRYPTO_USER_API_HASH=y >CONFIG_CRYPTO_USER_API_SKCIPHER=y >CONFIG_CRYPTO_USER_API_RNG=y >CONFIG_CRYPTO_LIB_AES=y >CONFIG_CRYPTO_LIB_ARC4=y >CONFIG_CRYPTO_LIB_DES=y >CONFIG_CRYPTO_LIB_POLY1305_GENERIC=y >CONFIG_CRYPTO_LIB_SHA256=y >CONFIG_CRYPTO_HW=y >root@fireball / # > >Just wanted to have a few extras. ROFL A gentoo centric manual/howto: https://wiki.gentoo.org/wiki/Dm-crypt -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Encrypting a hard drive's data. Best method.
On 6 June 2020 06:37:23 CEST, Dale wrote: >Howdy, > >I think I got a old 3TB hard drive to work. After dd'ing it, redoing >partitions and such, it seems to be working. Right now, I'm copying a >bunch of data to it to see how it holds up. Oh, it's a PMR drive too. >lol Once I'm pretty sure it is alive and working well, I want to play >with encryption. At some point, I plan to encrypt /home. I found a >bit >of info with startpage but some is dated. This is one link that seems >to be from this year, at least updated this year. > >https://linoxide.com/linux-how-to/encrypt-linux-filesystem/ > >It seems like a nice one since it has commands and what it should look >like when it is performing the commands. I like knowing what I'm doing >sort of matches what the howto shows. It also seems to use LVM which I >will be using as well. I think I can follow that and get a working >encrypted storage. Later, I can attempt this on /home without doing it >blind. I also have the options in the kernel as well. I'll post them >at the bottom. I enabled quite a lot a while back. ;-) > >Is this a secure method or is there a more secure way? Is there any >known issues with using this? Anyone here use this method? Keep in >mind, LVM. BTFRS, SP?, may come later. > >One other question, can one change the password every once in a while? >Or once set, you stuck with it from then on? > >If anyone has links to even better howtos, I'd love to check them out. > >Dale > >:-) :-) > > >root@fireball / # zcat /proc/config.gz | grep crypt | grep =y >CONFIG_ARCH_HAS_MEM_ENCRYPT=y >CONFIG_DM_CRYPT=y >CONFIG_CRYPTO=y >CONFIG_CRYPTO_ALGAPI=y >CONFIG_CRYPTO_ALGAPI2=y >CONFIG_CRYPTO_AEAD=y >CONFIG_CRYPTO_AEAD2=y >CONFIG_CRYPTO_SKCIPHER=y >CONFIG_CRYPTO_SKCIPHER2=y >CONFIG_CRYPTO_HASH=y >CONFIG_CRYPTO_HASH2=y >CONFIG_CRYPTO_RNG=y >CONFIG_CRYPTO_RNG2=y >CONFIG_CRYPTO_RNG_DEFAULT=y >CONFIG_CRYPTO_AKCIPHER2=y >CONFIG_CRYPTO_AKCIPHER=y >CONFIG_CRYPTO_KPP2=y >CONFIG_CRYPTO_ACOMP2=y >CONFIG_CRYPTO_MANAGER=y >CONFIG_CRYPTO_MANAGER2=y >CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y >CONFIG_CRYPTO_GF128MUL=y >CONFIG_CRYPTO_NULL=y >CONFIG_CRYPTO_NULL2=y >CONFIG_CRYPTO_CRYPTD=y >CONFIG_CRYPTO_AUTHENC=y >CONFIG_CRYPTO_SIMD=y >CONFIG_CRYPTO_GLUE_HELPER_X86=y >CONFIG_CRYPTO_RSA=y >CONFIG_CRYPTO_ECHAINIV=y >CONFIG_CRYPTO_CBC=y >CONFIG_CRYPTO_ECB=y >CONFIG_CRYPTO_LRW=y >CONFIG_CRYPTO_XTS=y >CONFIG_CRYPTO_NHPOLY1305=y >CONFIG_CRYPTO_NHPOLY1305_SSE2=y >CONFIG_CRYPTO_NHPOLY1305_AVX2=y >CONFIG_CRYPTO_ESSIV=y >CONFIG_CRYPTO_HMAC=y >CONFIG_CRYPTO_CRC32C=y >CONFIG_CRYPTO_XXHASH=y >CONFIG_CRYPTO_BLAKE2B=y >CONFIG_CRYPTO_CRCT10DIF=y >CONFIG_CRYPTO_MD5=y >CONFIG_CRYPTO_RMD128=y >CONFIG_CRYPTO_RMD160=y >CONFIG_CRYPTO_RMD256=y >CONFIG_CRYPTO_RMD320=y >CONFIG_CRYPTO_SHA1=y >CONFIG_CRYPTO_SHA1_SSSE3=y >CONFIG_CRYPTO_SHA256_SSSE3=y >CONFIG_CRYPTO_SHA512_SSSE3=y >CONFIG_CRYPTO_SHA256=y >CONFIG_CRYPTO_SHA512=y >CONFIG_CRYPTO_WP512=y >CONFIG_CRYPTO_AES=y >CONFIG_CRYPTO_AES_TI=y >CONFIG_CRYPTO_ARC4=y >CONFIG_CRYPTO_BLOWFISH=y >CONFIG_CRYPTO_BLOWFISH_COMMON=y >CONFIG_CRYPTO_BLOWFISH_X86_64=y >CONFIG_CRYPTO_CAMELLIA=y >CONFIG_CRYPTO_CAMELLIA_X86_64=y >CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=y >CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=y >CONFIG_CRYPTO_DES=y >CONFIG_CRYPTO_SERPENT=y >CONFIG_CRYPTO_SERPENT_SSE2_X86_64=y >CONFIG_CRYPTO_TWOFISH=y >CONFIG_CRYPTO_TWOFISH_COMMON=y >CONFIG_CRYPTO_TWOFISH_X86_64=y >CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=y >CONFIG_CRYPTO_ANSI_CPRNG=y >CONFIG_CRYPTO_DRBG_MENU=y >CONFIG_CRYPTO_DRBG_HMAC=y >CONFIG_CRYPTO_DRBG=y >CONFIG_CRYPTO_JITTERENTROPY=y >CONFIG_CRYPTO_USER_API=y >CONFIG_CRYPTO_USER_API_HASH=y >CONFIG_CRYPTO_USER_API_SKCIPHER=y >CONFIG_CRYPTO_USER_API_RNG=y >CONFIG_CRYPTO_LIB_AES=y >CONFIG_CRYPTO_LIB_ARC4=y >CONFIG_CRYPTO_LIB_DES=y >CONFIG_CRYPTO_LIB_POLY1305_GENERIC=y >CONFIG_CRYPTO_LIB_SHA256=y >CONFIG_CRYPTO_HW=y >root@fireball / # > >Just wanted to have a few extras. ROFL Dale, I didn't read the full page, but as it uses LUKS to manage the encryption, it is (at least similar) to what I do on my laptops. A LUKS volume has support for multiple (I think 4) key slots (passwords that will decrypt the volume) So, in order to change the password you would do: 1) add the new password into an unused slot 2) test the new password works 3) delete the old password (freeing the slot) -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
