Re: [gentoo-user] Encrypted drives, password generation and management howto, guide.
On Wed, 15 May 2024 20:55:53 -0500, Dale wrote: > > xclip is not a clipboard, it is a tool to manage the contents of the > > existing clipboards and selection buffers. > > > > > > > Well, just for giggles. > > root@fireball / # echo "" | xclip > -bash: xclip: command not found > root@fireball / # > > It didn't like it. :/ You missed out the important first step: $ emerge -a xclip :-( -- Neil Bothwick WinErr 683: Time out error - Operator fell asleep while waiting for the system to complete boot procedure. pgp4EEaRUWqz5.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Encrypted drives, password generation and management howto, guide.
Neil Bothwick wrote: > On Wed, 15 May 2024 08:09:01 -0500, Dale wrote: > >>> x11-misc/xclip >>> >>> Or just select some empty space in an application, to overwrite your >>> previous selection. >> Well, since it works, something is acting as a clipboard. It doesn't >> seem to be xclip in my case. > xclip is not a clipboard, it is a tool to manage the contents of the > existing clipboards and selection buffers. > > Well, just for giggles. root@fireball / # echo "" | xclip -bash: xclip: command not found root@fireball / # It didn't like it. :/ It seems that it only remembers one in memory anyway. Once I highlight something else, it kinda clears itself. That works. Heck, I have to clear the Konsole when I exit kpcli anyway. Dale :-) :-)
Re: [gentoo-user] Encrypted drives, password generation and management howto, guide.
On Wed, 15 May 2024 08:09:01 -0500, Dale wrote: > > x11-misc/xclip > > > > Or just select some empty space in an application, to overwrite your > > previous selection. > > Well, since it works, something is acting as a clipboard. It doesn't > seem to be xclip in my case. xclip is not a clipboard, it is a tool to manage the contents of the existing clipboards and selection buffers. -- Neil Bothwick Loose bits sink chips. pgp8VMd5CFgb7.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Encrypted drives, password generation and management howto, guide.
Peter Humphrey wrote: > On Wednesday, 15 May 2024 14:37:22 BST Michael wrote: > >> There are 3 'cliboards', known as selections, I know of: >> >> 1. Primary - you select some text by holding down your left mouse button (or >> Shift+arrow) and you paste it with your middle button (or Shift+Insert - >> depending on application). >> >> 2. Secondary - some applications will autoselect text, e.g. when you click >> in the non-empty address bar of a browser. This can replace any selection >> you had in the Primary selection. It depends on the particular >> application. >> >> 3. Clipboard - this is the Ctrl+x/c/v MSWindows style of cut/copy/paste menu >> items. > I just think of them simply as a selection buffer and a paste buffer. It > obviates any more complicated mental models. > >> I understand there's a new disk technology about to be released upon us with >> laser heating up the area where data is being stored, to increase density >> and therefore hugely increase capacity. Your next spinning drive could >> well be 30-50T or more! 0_0 > Oo-er! > > -- Regards, Peter. This explanation makes sense. Looks like once I highlight something else, it forgets the previous highlight. That goes with how it seems to work as well. On the larger hard drives, I just bought a Fractal case that holds at least 18 drives. Now this. :-D Dale :-) :-)
Re: [gentoo-user] Encrypted drives, password generation and management howto, guide.
On Wednesday, 15 May 2024 14:37:22 BST Michael wrote: > There are 3 'cliboards', known as selections, I know of: > > 1. Primary - you select some text by holding down your left mouse button (or > Shift+arrow) and you paste it with your middle button (or Shift+Insert - > depending on application). > > 2. Secondary - some applications will autoselect text, e.g. when you click > in the non-empty address bar of a browser. This can replace any selection > you had in the Primary selection. It depends on the particular > application. > > 3. Clipboard - this is the Ctrl+x/c/v MSWindows style of cut/copy/paste menu > items. I just think of them simply as a selection buffer and a paste buffer. It obviates any more complicated mental models. > I understand there's a new disk technology about to be released upon us with > laser heating up the area where data is being stored, to increase density > and therefore hugely increase capacity. Your next spinning drive could > well be 30-50T or more! 0_0 Oo-er! -- Regards, Peter. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Encrypted drives, password generation and management howto, guide.
On Wednesday, 15 May 2024 14:09:01 BST Dale wrote: > Michael wrote: > > On Wednesday, 15 May 2024 11:56:04 BST Dale wrote: > >> There doesn't appear to be a xclip on here, not as a command anyway. > >> Could it be some other name? Maybe it changed? I'm sure it is > >> something. I just don't know what. > >> > >> Thanks. > >> > >> Dale > >> > >> :-) :-) > > > > x11-misc/xclip > > > > Or just select some empty space in an application, to overwrite your > > previous selection. > > Well, since it works, something is acting as a clipboard. It doesn't > seem to be xclip in my case. Anyway, that's what I been doing is > highlighting something else and that makes it paste the new highlighted > info instead of previous info. I have no idea if those entries are > stored somewhere or when gone, they gone. I'm hoping they are gone. There are 3 'cliboards', known as selections, I know of: 1. Primary - you select some text by holding down your left mouse button (or Shift+arrow) and you paste it with your middle button (or Shift+Insert - depending on application). 2. Secondary - some applications will autoselect text, e.g. when you click in the non-empty address bar of a browser. This can replace any selection you had in the Primary selection. It depends on the particular application. 3. Clipboard - this is the Ctrl+x/c/v MSWindows style of cut/copy/paste menu items. More details can be found in the spec here: https://specifications.freedesktop.org/clipboards-spec/clipboards-latest.txt As far as I know the Primary selection is not stored anywhere - other than within the application's memory space where the range of characters have been selected. The xserver will call for this when you middle click to paste it on another application's window. The Clipboard may be stored in RAM or cache of any applications which use this method. > P. S. My new 16TB drive is almost done with the long SMART test. :-D I understand there's a new disk technology about to be released upon us with laser heating up the area where data is being stored, to increase density and therefore hugely increase capacity. Your next spinning drive could well be 30-50T or more! 0_0 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Encrypted drives, password generation and management howto, guide.
Michael wrote: > On Wednesday, 15 May 2024 11:56:04 BST Dale wrote: >> Neil Bothwick wrote: >>> On Wed, 15 May 2024 03:44:49 -0500, Dale wrote: I thought that too. I highlighted some text in a Konsole and then looked in the KDE clipboard, what I highlighted was not there. It wasn't there after I pasted it either. It goes to a clipboard somewhere but it appears it only remembers one entry then forgets when you highlight something else. I'm not aware of a way to access it yet. I've looked for it but can't find it. To be honest, I wish there was a way to clear it, wherever it is. I clear my KDE clipboard that is on my desktop pretty regular. I always do so after copying passwords or something important. >>> xclip manipulates both the standard and X selection clipboards. It works >>> with the X selection clipboard by default, so you shold be able to clear >>> it with >>> >>> echo "" | xclip >>> I'm wondering if that clipboard is a part of Konsole itself. I've never seen anything in the KDE clipboard that I just highlighted in Konsole. >>> It's part of X. >>> I could use Bitwarden to generate passwords but then I'd need to copy it to my regular clipboard to get it to the Konsole. I wanted to avoid that. >>> Bitwarden has an option to clear the clipboard after a configurable time, >>> much like KeePassXC. >>> >>> Naturally, if you are really paranoid about security, you will run your >>> own Vaultwarden server to avoid the passwords ever going anywhere out of >>> your control. >> I wanted to check out the help info, maybe learn something new. This is >> what I get when trying to find xclip. >> >> >> root@fireball / # xc >> xcam xchm xcircuit >> root@fireball / # >> >> >> There doesn't appear to be a xclip on here, not as a command anyway. >> Could it be some other name? Maybe it changed? I'm sure it is >> something. I just don't know what. >> >> Thanks. >> >> Dale >> >> :-) :-) > x11-misc/xclip > > Or just select some empty space in an application, to overwrite your previous > selection. Well, since it works, something is acting as a clipboard. It doesn't seem to be xclip in my case. Anyway, that's what I been doing is highlighting something else and that makes it paste the new highlighted info instead of previous info. I have no idea if those entries are stored somewhere or when gone, they gone. I'm hoping they are gone. Dale :-) :-) P. S. My new 16TB drive is almost done with the long SMART test. :-D
Re: [gentoo-user] Encrypted drives, password generation and management howto, guide.
On Wednesday, 15 May 2024 11:56:04 BST Dale wrote: > Neil Bothwick wrote: > > On Wed, 15 May 2024 03:44:49 -0500, Dale wrote: > >> I thought that too. I highlighted some text in a Konsole and then > >> looked in the KDE clipboard, what I highlighted was not there. It > >> wasn't there after I pasted it either. It goes to a clipboard somewhere > >> but it appears it only remembers one entry then forgets when you > >> highlight something else. I'm not aware of a way to access it yet. > >> I've looked for it but can't find it. To be honest, I wish there was a > >> way to clear it, wherever it is. I clear my KDE clipboard that is on my > >> desktop pretty regular. I always do so after copying passwords or > >> something important. > > > > xclip manipulates both the standard and X selection clipboards. It works > > with the X selection clipboard by default, so you shold be able to clear > > it with > > > > echo "" | xclip > > > >> I'm wondering if that clipboard is a part of Konsole itself. I've never > >> seen anything in the KDE clipboard that I just highlighted in Konsole. > > > > It's part of X. > > > >> I could use Bitwarden to generate passwords but then I'd need to copy it > >> to my regular clipboard to get it to the Konsole. I wanted to avoid > >> that. > > > > Bitwarden has an option to clear the clipboard after a configurable time, > > much like KeePassXC. > > > > Naturally, if you are really paranoid about security, you will run your > > own Vaultwarden server to avoid the passwords ever going anywhere out of > > your control. > > I wanted to check out the help info, maybe learn something new. This is > what I get when trying to find xclip. > > > root@fireball / # xc > xcam xchm xcircuit > root@fireball / # > > > There doesn't appear to be a xclip on here, not as a command anyway. > Could it be some other name? Maybe it changed? I'm sure it is > something. I just don't know what. > > Thanks. > > Dale > > :-) :-) x11-misc/xclip Or just select some empty space in an application, to overwrite your previous selection. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Encrypted drives, password generation and management howto, guide.
Neil Bothwick wrote: > On Wed, 15 May 2024 03:44:49 -0500, Dale wrote: > >> I thought that too. I highlighted some text in a Konsole and then >> looked in the KDE clipboard, what I highlighted was not there. It >> wasn't there after I pasted it either. It goes to a clipboard somewhere >> but it appears it only remembers one entry then forgets when you >> highlight something else. I'm not aware of a way to access it yet. >> I've looked for it but can't find it. To be honest, I wish there was a >> way to clear it, wherever it is. I clear my KDE clipboard that is on my >> desktop pretty regular. I always do so after copying passwords or >> something important. > xclip manipulates both the standard and X selection clipboards. It works > with the X selection clipboard by default, so you shold be able to clear > it with > > echo "" | xclip > >> I'm wondering if that clipboard is a part of Konsole itself. I've never >> seen anything in the KDE clipboard that I just highlighted in Konsole. > It's part of X. > >> I could use Bitwarden to generate passwords but then I'd need to copy it >> to my regular clipboard to get it to the Konsole. I wanted to avoid >> that. > Bitwarden has an option to clear the clipboard after a configurable time, > much like KeePassXC. > > Naturally, if you are really paranoid about security, you will run your > own Vaultwarden server to avoid the passwords ever going anywhere out of > your control. > > I wanted to check out the help info, maybe learn something new. This is what I get when trying to find xclip. root@fireball / # xc xcam xchm xcircuit root@fireball / # There doesn't appear to be a xclip on here, not as a command anyway. Could it be some other name? Maybe it changed? I'm sure it is something. I just don't know what. Thanks. Dale :-) :-)
Re: [gentoo-user] Encrypted drives, password generation and management howto, guide.
On Wed, 15 May 2024 03:44:49 -0500, Dale wrote: > I thought that too. I highlighted some text in a Konsole and then > looked in the KDE clipboard, what I highlighted was not there. It > wasn't there after I pasted it either. It goes to a clipboard somewhere > but it appears it only remembers one entry then forgets when you > highlight something else. I'm not aware of a way to access it yet. > I've looked for it but can't find it. To be honest, I wish there was a > way to clear it, wherever it is. I clear my KDE clipboard that is on my > desktop pretty regular. I always do so after copying passwords or > something important. xclip manipulates both the standard and X selection clipboards. It works with the X selection clipboard by default, so you shold be able to clear it with echo "" | xclip > I'm wondering if that clipboard is a part of Konsole itself. I've never > seen anything in the KDE clipboard that I just highlighted in Konsole. It's part of X. > I could use Bitwarden to generate passwords but then I'd need to copy it > to my regular clipboard to get it to the Konsole. I wanted to avoid > that. Bitwarden has an option to clear the clipboard after a configurable time, much like KeePassXC. Naturally, if you are really paranoid about security, you will run your own Vaultwarden server to avoid the passwords ever going anywhere out of your control. -- Neil Bothwick Humpty Dumpty DOS - Just a shell of himself. pgpbOlXdjFiN7.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Encrypted drives, password generation and management howto, guide.
Frank Steinmetzger wrote: > Am Tue, May 14, 2024 at 06:28:17AM -0500 schrieb Dale: >> Howdy, >> […] >> remember either, or write notes to remember them. I also wanted to >> avoid the desktop copy and paste, or clipboard, mechanism. I'm not sure >> how that data is stored in the clipboard and how good it is at erasing >> it when I clear it. > The mark-and-middleclick you describe further down is the very same as the > “normal” clipboard. It is just accessed differently. > I thought that too. I highlighted some text in a Konsole and then looked in the KDE clipboard, what I highlighted was not there. It wasn't there after I pasted it either. It goes to a clipboard somewhere but it appears it only remembers one entry then forgets when you highlight something else. I'm not aware of a way to access it yet. I've looked for it but can't find it. To be honest, I wish there was a way to clear it, wherever it is. I clear my KDE clipboard that is on my desktop pretty regular. I always do so after copying passwords or something important. I'm wondering if that clipboard is a part of Konsole itself. I've never seen anything in the KDE clipboard that I just highlighted in Konsole. Now if I highlight and right click to copy, that goes to the KDE clipboard as expected. I'm not sure where the Konsole clipboard info goes. >> First, I needed to generate a password. I googled, a lot. I had >> trouble finding a way to generate the type of passwords I wanted but I >> finally found one. > Care to elaborate regarding the “password you wanted”? There is the obvious > pwgen, which can generate passwords with given character sets and length. > Keepass can do this, too, so I assume, Bitwarden (which you use) has a > similar function. > > And if you don’t like parts of the generated PW, keep the part you like, > generate new and pick the part you like again. Or just let pwgen generate a > big bunch and pick what you like best from the output. > I could use Bitwarden to generate passwords but then I'd need to copy it to my regular clipboard to get it to the Konsole. I wanted to avoid that. Bitwarden is a awesome tool. It's like LastPasss but open source. When LastPass got bought and started limiting basic features, I switched to Bitwarden. Honestly, I wish I had started with Bitwarden to begin with. I like my passwords to have all sorts of characters in as random a order as possible. Most all password tools do a good job of this. The thing I like about the method I posted, I can control exactly what characters are used, individually. I had a website once that allowed some characters, like above the number keys on older keyboards, but didn't allow a few odd ones. LastPass and Bitwarden have the option to turn them off or on as a set but not individually. Luckily that website wasn't something sensitive like a bank or anything but still, some websites do limit what can be used and some are a bit weird. With the command I use, I can easily, in a one time way, leave out anything that I need to but leave the rest. >> […] >> Now that I have a password, how do I keep track of them? I did some >> more searching. I wanted something that was command line not GUI. >> After all, I have BitWarden for websites and such already. Thing is, >> it's GUI since it is a Firefox add-on. I'd need to use the clipboard to >> copy and paste. I want to avoid that remember? I also wanted something >> that is on its own, separate from my main password tool BitWarden. I >> found kpcli in the tree. > I didn’t know about kpcli and it is not available in Arch. So I looked it > up. Turns out it is a non-graphical Keepass client (that’s what the kp > stands for, after all). > > Interestingly, there is also a bitwarden CLI client. > > Did you know Keepass (the graphical one) has an autotype feature? This means > that it simulates the pressing of keys, so it bypasses the clipboard > entirely. Another advantage of that is that you can set up custom key > sequences in the autotype field, so you can for example say “first enter the > username, then press enter, then wait for a second, then enter the password > and press enter again.” Useful for sites that use a dynamic login screen > with animations or non-standard input fields. > I didn't know KeePass had that feature in the GUI version. I did know kpcli was based on KeePass in some way tho. I read that somewhere. Kpcli just fit the need I had and was in the tree to install. Now that I got it setup, it does what I want, no need switching. ;-) >> Then I needed some way to handle if the password file kpcli uses got >> lost or damaged. If I were to lose that file, all drives and the data >> on them is lost. I'd lose everything because there is no way to >> remember the password. > The obvious answer is: backup – encrypted or not. ;-) > My Keepass database is a simple file in my home that is backed up together > with all the other home files by Borg. Meaning I
Re: [gentoo-user] Encrypted drives, password generation and management howto, guide.
Am Tue, May 14, 2024 at 06:28:17AM -0500 schrieb Dale: > Howdy, > […] > remember either, or write notes to remember them. I also wanted to > avoid the desktop copy and paste, or clipboard, mechanism. I'm not sure > how that data is stored in the clipboard and how good it is at erasing > it when I clear it. The mark-and-middleclick you describe further down is the very same as the “normal” clipboard. It is just accessed differently. > First, I needed to generate a password. I googled, a lot. I had > trouble finding a way to generate the type of passwords I wanted but I > finally found one. Care to elaborate regarding the “password you wanted”? There is the obvious pwgen, which can generate passwords with given character sets and length. Keepass can do this, too, so I assume, Bitwarden (which you use) has a similar function. And if you don’t like parts of the generated PW, keep the part you like, generate new and pick the part you like again. Or just let pwgen generate a big bunch and pick what you like best from the output. > […] > Now that I have a password, how do I keep track of them? I did some > more searching. I wanted something that was command line not GUI. > After all, I have BitWarden for websites and such already. Thing is, > it's GUI since it is a Firefox add-on. I'd need to use the clipboard to > copy and paste. I want to avoid that remember? I also wanted something > that is on its own, separate from my main password tool BitWarden. I > found kpcli in the tree. I didn’t know about kpcli and it is not available in Arch. So I looked it up. Turns out it is a non-graphical Keepass client (that’s what the kp stands for, after all). Interestingly, there is also a bitwarden CLI client. Did you know Keepass (the graphical one) has an autotype feature? This means that it simulates the pressing of keys, so it bypasses the clipboard entirely. Another advantage of that is that you can set up custom key sequences in the autotype field, so you can for example say “first enter the username, then press enter, then wait for a second, then enter the password and press enter again.” Useful for sites that use a dynamic login screen with animations or non-standard input fields. > Then I needed some way to handle if the password file kpcli uses got > lost or damaged. If I were to lose that file, all drives and the data > on them is lost. I'd lose everything because there is no way to > remember the password. The obvious answer is: backup – encrypted or not. ;-) My Keepass database is a simple file in my home that is backed up together with all the other home files by Borg. Meaning I even have a versioned backup of my passwords. Needless to say my backup drives are LUKSed with a long passphrase that I have never ever once written down anywhere on paper. I’ve been using it for so long now and on several drives, that it is ingrained in my brain. > The kpcli file itself appears to be encrypted. > So, it protects itself. That's good. I don't need to put the file on > something that is also encrypted, just copy it to a plain file system as > it is. I have a USB stick that I store things on. Things like drive > info, what drives go to what volume group, what drive has the OS on it > etc and the portage world file on it. I also have some scripts in /root > that I don't want to lose either so I copy them to the stick as well. Be mindful that USB sticks aren’t very reliable. The flash chips in them are what is left after quality control deemed them unfit for duty in SSDs (first tier) and memory cards (second tier). So always keep several copies, possibly on different types of storage media (HDDs, SSDs, optical, whatever). > Then one important file, my file that contains frequently used > commands. It is rather lengthy and is 15 years or more of additions. I > copied all that info to a USB stick. It lives in the fire safe. TBH, I wouldn’t put all my horses on one USB stick in a fire safe. (Or however the saying goes) After a flimsy USB stick with questionable flash chips has been subjected to high temperatures for a longer time, chances are you may not be able to access its data ever again. > How I use all this. I do this in a Konsole, within KDE, which has > tabs. Might work on a plain console to tho. If I need to open a > encrypted drive, or set of drives, I open kpcli and get it to show the > password for that drive in one tab. I then run the little script to > open and mount that drive in another tab. When it asks for the > password, I highlight the password from kpcli tab and then switch tabs > and middle click to paste the password in. Since you’ve already scripted most of it, you could possible go the full way. Use the HDD’s UUID as key and either store the password in a file that is named with the UUID, or in keepass with the UUID as entry title. Then you can let the script retrieve the password all by itself without any need for copy-pasting –
Re: [gentoo-user] Encrypted drives, password generation and management howto, guide.
Rich Freeman wrote: > On Tue, May 14, 2024 at 7:28 AM Dale wrote: >> First, I needed to generate a password. > Honestly, I'd stop right there, and think about WHY you're encrypting > your disks, and WHY you need a password to decrypt them. There are > many use cases and threat models to consider. > > I have a whole bunch of encrypted drives on my Ceph cluster, and none > of them have a traditional "password" and I couldn't tell you what any > of them are. They're keys stored in files on the OS drive, and I do > have a backup of them as well. I don't have to go looking up anything > to do anything because the file is referenced in crypttab and so LUKS > just does its thing during boot. > > Obviously anybody who has physical access to the host can decrypt the > drives. The OS disks aren't even encrypted. So why bother? Well, my > threat model is this - I have huge amounts of data on disks, and disks > eventually fail, and they're a real pain to wipe, especially if > they've failed. With my solution, those physical disks are completely > unreadable when separated from the OS drive. There is no risk of > brute-force attacks as there is no memorable passphrase to crack - > they're just random keys, so it is a basic brute force attack on AES > itself. When things need rebooting I don't need to be present to type > anything in, and I don't need any fancy TPM-based solutions to make > that possible either. > > The more traditional approach uses memorable passphrases, and for that > you can use pwgen, or xkcdpass. Or you can just come up with > something memorable but not likely to be guessed, with plenty of > rounds. > > The most common approach (outside of Linux) is to use a TPM to manage > the key with verified boot. This is possible on Linux, but no distro > I'm aware of other than maybe ChromeOS does it (and ChromeOS doesn't > really do it the traditional way). This lets you have a desktop that > makes the disk unreadable when separated from the PC, and it can only > be read if the disk is booted normally. It is a very elegant > solution, assuming you trust the security of the TPM, but without > distro support I probably wouldn't mess with it. On Windows it is > very common, and on ChromeOS it isn't even optional - they all do it. > My concern, someone breaks into my home and steals my drives, and computer too. They get the OS and some general stuff but the stuff I want to protect others from getting or seeing, they need the password. It isn't stored anywhere they can just copy and paste it either. This is why I didn't use files for the keys. If the puter can boot and decrypt the drives with no input from me, well, there's really no point in encrypting it to begin with except as you point out in the event of a drive failure. As it is now, if I lock my drives or shutdown my puter and go to town, my data is safe, from whoever may want to access it, with or without my puter. There may not be many who want to go to all this trouble. There could be some tho. I posted for those who would like to have this setup or it give ideas on a setup that may even work better for their use case. This works well for me. I remember one password. That's it. With that password I can get the passwords, random generated and long ones at that, and open my drives up. To anyone else, it may be doable to crack them but they gonna work for it. I have no idea why a person would put in all that effort for data when they don't even know what is there. If it was known to be a secret formula for turning lead into gold, I could get that. My data, not likely. I suspect most don't want to use this method. That is fine. Not every use case is the same and some may not concern themselves over the same things I do. If someone does have a need for a method like this, they have a way to do it. So far, it's working pretty well. Given I have copies of the kpcli in case one goes bad and gets deleted, I think I'm pretty safe. I figure there is few who would use this but I thought it worth posting given the time and effort I put in researching and figuring out ways to make it work. The Linux way is to come up with things and then share to help others. I've certainly had people share things with me. :-D Dale :-) :-)
Re: [gentoo-user] Encrypted drives, password generation and management howto, guide.
On Tue, May 14, 2024 at 7:28 AM Dale wrote: > > First, I needed to generate a password. Honestly, I'd stop right there, and think about WHY you're encrypting your disks, and WHY you need a password to decrypt them. There are many use cases and threat models to consider. I have a whole bunch of encrypted drives on my Ceph cluster, and none of them have a traditional "password" and I couldn't tell you what any of them are. They're keys stored in files on the OS drive, and I do have a backup of them as well. I don't have to go looking up anything to do anything because the file is referenced in crypttab and so LUKS just does its thing during boot. Obviously anybody who has physical access to the host can decrypt the drives. The OS disks aren't even encrypted. So why bother? Well, my threat model is this - I have huge amounts of data on disks, and disks eventually fail, and they're a real pain to wipe, especially if they've failed. With my solution, those physical disks are completely unreadable when separated from the OS drive. There is no risk of brute-force attacks as there is no memorable passphrase to crack - they're just random keys, so it is a basic brute force attack on AES itself. When things need rebooting I don't need to be present to type anything in, and I don't need any fancy TPM-based solutions to make that possible either. The more traditional approach uses memorable passphrases, and for that you can use pwgen, or xkcdpass. Or you can just come up with something memorable but not likely to be guessed, with plenty of rounds. The most common approach (outside of Linux) is to use a TPM to manage the key with verified boot. This is possible on Linux, but no distro I'm aware of other than maybe ChromeOS does it (and ChromeOS doesn't really do it the traditional way). This lets you have a desktop that makes the disk unreadable when separated from the PC, and it can only be read if the disk is booted normally. It is a very elegant solution, assuming you trust the security of the TPM, but without distro support I probably wouldn't mess with it. On Windows it is very common, and on ChromeOS it isn't even optional - they all do it. -- Rich
[gentoo-user] Encrypted drives, password generation and management howto, guide.
Howdy,
This is more of a howto or rough guide. As most know, I have several
encrypted hard drives, or sets of hard drives using LVM. I don't even
know how much data I have stored here at the moment. I started a thread
a while back about how to come up with and remember passwords. I got
some pretty good ideas. Thing is, those come with problems when you
need to have over half a dozen passwords and each needs to be something
that can not be guessed. I came up with passwords and made little post
it notes with info that helps me remember the passwords. Thing is, if a
person could figure out what was on the note, then they could crack the
password. Some people are smart that way. Online password test tools,
as good or bad as they are, claim it would take centuries or longer to
crack the passwords. However, that little note that helps me remember
it could also help the person trying to crack it. So, ever since I been
trying to come up with a new way to do this. I wanted passwords that
would be virtually impossible to crack but that I didn't have to
remember either, or write notes to remember them. I also wanted to
avoid the desktop copy and paste, or clipboard, mechanism. I'm not sure
how that data is stored in the clipboard and how good it is at erasing
it when I clear it.
First, I needed to generate a password. I googled, a lot. I had
trouble finding a way to generate the type of passwords I wanted but I
finally found one. It gives me a lot of control including on what
characters it uses and length. I can actually change the allowed
characters if something on the receiving end can't use certain
characters. This is what I found, with a few characters added to the
original command:
https://www.howtogeek.com/30184/10-ways-to-generate-a-random-password-from-the-command-line/
I added some characters to the list it filters to have even more of
them. I plan to add all I can, every letter on the keyboard in upper
and lower case, plus any I missed later on. It generates passwords like
this as shown above:
eg@^04f[C@AvTQRWX242
A!q@wSa5TTE?Z2xg9wX{
]rqC^swC#sAza]24F%9B
CA&?]SD+1#&$rbgwD
T8x@cWaEZc##4WDfd!Qv
It is set to do 20 characters but I sometimes increase that. I guess
one could go to a huge number if one wanted too. I'm not sure what the
limit is on cryptsetup but have seen people use files generated by
/dev/random at over 4,000 characters. That is pretty long!! Point is,
try to guess one of passwords generated above.
While typing this, I added some things to the list of allowed characters
in the command above. You have to leave out the ' or single quote,
since the command uses it. I also left out the double quote, ", as
well. New command.
?,.1234567890QWERTYUIOPASDFGHJKLZXCVBNMqwertyuiopasdfghjklzxcvbnm'
| head -c 40; echo ""
It generates passwords like this.
{sVao%ezpr<[B[,b$5C8j(
L_7g{JUh39%Da`l!
