Latest, up-to-date Fedora, KDE version and Firefox.

Sorry - this might get lengthy. I've been exploring the use of the passff extension of Firefox to store and encrypt logins and passwords securely for sites I visit. This was prompted by a recent lxer article than led me here. I'm not particularly new to this stuff (or with linux in particular), but the way this article and the whole process wrapped me around the axle has me rating this article (and perhaps github's idea of "good software") as a -1 on a scale of 1 to 5. It would be useful for someone to mention which processes are done as root and which are done from the user account, and even more useful if instructions were either dated or kept up to date. Sigh.

I apologize for that rant. Now that I've successfully (if accidentally) fixed the "No public key" error that qtpass kept generating, I see that the extension allows someone to store logins and passwords in encrypted files. I see that the files can be easily edited, saved and backed up. But I don't understand how the concept of public and private keys works when I re-install my Fedora from, say, a live iso (which is done frequently with Fedora's short release cycle). Will I lose my keys and have to re-introduce my passwords and logins from scratch?

If so, why is this superior to just putting my info in an .odt file password protected by libreoffice (and saving it on a thumbdrive, of course)?

I'm not particularly paranoid about someone finding my password to linuxquestions, but I do go to the trouble of having individual, lengthy mixed-case-and-national-chars passwords for any site that has any of my account information. I'm on the fence about needing gpg to encrypt this info for me, and I'm worried it'll be lost after the next installation of my OS.

Suggestions? Thanks.

If you re-install your system and ask to format your /home, then yes, you lose your key and every logins. Same thing happens with your odt file if you don't save it.
So, you can re-install your system without wiping your /home and you have to backup your key and logins.

Of course, it is a good idea to save your encrypted logins anywhere you want, and for security matters to save your key separately on a secure device/location. Because nobody should be able to read your key.

Using key is superior to a odt file only if you save your key in a secure way and nobody except you can read it. Because that way you can copy your logins wherever you want nobody can read them without your key.
In some way, it is like having a safe, you can leave it anywhere, only you have the key to open it and you don't have to carry the whole safe.

Not sure I am helping

Well, I think you have been helpful, lougavulin (and thanks).

But I'm not sure I fully understand, and perhaps you or someone could explain. In the future I'd like to save the keys as well as the passwords/logins, and have the ability to restore them, but it's not clear how that's done. Are the keys in a file I can save? Export/Import? The idea of public and private keys is probably at the root of my confusion! (And yes, I'm probably overthinking the whole concept.) Clearly, I'm not sure where or how anything concerning encryption is saved.

Good point about leaving the /home partition intact between builds. As it is, though, I'm likely to replace my hard drive with an SSD just about the time Fedora comes out with a new version. So I'll need to restore or start from scratch in any case. It's not a huge amount of extra work, but I'm really doing this exercise to understand pass, qtpass, kpgp and encryption in general.

It's a learning experience!

When we use a GPG key, in fact there is two parts, called private key and public key.
They are stored in files and can be found in your home under :
.gnupg/
Saving this directory can be enough to save your keys.
But you also can export and import them. For example, exports :
Import use the same kind of syntax and same command.
The private key as its name say have to stay private. If you export it, this is the file to save separately. And from your private key you can export your public key, so you don't need to save both.
The public key can be share with anyone and this is its purpose to be shared. Because gpg purpose is to provide encrypted secured communication between people mainly through emails. You give your public key to a friend, your friend gives you his public key, and you can write encrypted emails to each others which only you two could read.

As you see we can use gpg key to encrypted files and emails.

Public key encryption uses the property of multiplication that it is very easy to multiply two numbers together, but it is very difficult to determine after the fact--from the product--exactly which two numbers were originally multiplied together to obtain that product.

So, this allows for two keys: one for each operand in the multiplication: one to encrypt, and a different one to decrypt. As lougavulin has described, the encryption key (public key) can be uploaded to a key server where absolutely anyone can get a hold of it. It is only used to encrypt. If the public key is lost, it can be recovered using the private key.

The private key is used only to decrypt. It is different from the public key. Once the data is encrypted using the public key, it cannot be decrypted by the public key. It can only be decrypted with the private key. Not only is the algorithm for public key encryption ingenious, but it is highly technical. And implementing it securely in software is also quite difficult.

So, encrypting with the public key is a one-way process. The 'private key' is generally protected by a passphrase, just in case it is stolen it's still quite difficult to use. Without the private key it is essentially impossible to crack the encryption, except by blind luck. But if the private key is stolen, a computer program can attempt to guess the passphrase.

Computer passwords are all hashed. That means there is a limit to how many possible values there are. For a 32-bit hash there are about 9 billion possible hash values. You can program a computer to build a table of passwords that will yield 99% of the possible hash values, called a 'rainbow table'. Once you have the rainbow table, a password cracker can guess 99% of all passwords in a few seconds.

But every private-key passphrase represents a unique number. Even if the same passphrase is used with different private keys, the resulting numeric equivalent will be different for the two keys. So, the only way to break a passphrase use in public-key encryption is by trial and error; quite secure if one uses a long passphrase.

The main problem with public key encryption is trust. You must have trust that the public key your are using actually belongs to the person you think it does. Otherwise, you might be encrypting data that someone else can decrypt!

Therefore, there is a function within gpg to sign other public keys as trusted using your own public key. The more signatures of trust (and there are three levels of trust possible in a signature) a key has, the more it can be trusted to belong to the proposed owner.

Gpg keys are stored in a keyring in the /home/usr directory. They're just computer files. You can back them up, copy them, give them permissions, delete them, just like any other files. As for the qtpass file, yes it is files. They are stored in ~/.password-store.

It should also be mentioned that Fedora has a very good updater for new versions to save having to re-install all the time. Read DNF_system_upgrade

And thanks for that explanation, Awesome.

Now my problem/question is becoming a rant about the implementation and the lack of documentation for passff, pass, zx2c4, qtpass, the "host application" for all of this at github and with github itself. Clearly, no one involved has ever had to write an implementation manual. I have. What I've seen here is ambiguous, incomplete and in some cases, incorrect. Oh - and at least one example uses a jpeg showing an out of date version of pass. That's not rare. But not dating the information should invoke the death penalty^h^h^h^h^h^h^h be discouraged.

Sigh. I sorta-kinda have it working. I think. Even that's not clear because I need to verify it with sites that I don't have an account for (yet). Then I need to try again after a reboot to see if I can still login. Firefox may be restoring the info for me instead of passff on sites I use often.

And just to add to my frustrations, passff itself doesn't seem to work consistently from one session to the next. It's not particularly intuitive and like I've already said, it's not particularly well documented.

I agree sysgOO. I backup my /home partition routinely, though. I've got a pretty decent set of installation scripts for my own use, so it's pretty quick and easy to re-install everything from a live cd these days too.