Beginning the process with PGP-Key in Seahorse – what are the initial actions?
Beginning the process with PGP-Key in Seahorse – what are the initial actions?
g day dear experts here - hello dear Community, i need to get started with seahorse on Linux. Well i have to get a rapid start into this pgp-encryption method that supports pgp secured mail traffic with my friend. so first of all i have installed SeaHorse on my Notebook a older ( a very old ) Ubuntu-Notebook ubuntu@T420s:~$ sudo apt-get install seahorse [sudo] Password for ubuntu: Reading package lists... Done Building dependency tree... Done Reading status information... Done seahorse is already the latest version (43.0-1build1). seahorse was set as manually installed. The following packages were installed automatically and are no longer needed: grub-pc-bin libevent-2.1-7a Use sudo apt autoremove to remove them. 0 updated, 0 newly installed, 0 to remove and 1 not updated. ubuntu@T420s:~$ hmm - i hope that this went all right and i hope that i now am able to get the thing started. well if so - then i think i can start to use it - and then i want to start using GnuPG keys. Hmm - for this purpose: do i have to install someting extra - eg. gnupg !? isnt it suffice if i have the graphical interface seahorse. A friend told me that i have to do like so: first i need to select a new PGP-Key in seahorse - hmm to generate a new key. Well what I'm a little bit curios about is the following idea: The generate key, is this just the private one? Hmm in other words: Is it correct, that the first key i generate - is just a private key? If so, how do I create now a suitable public one? Can you give some helping hand here!? I need - this is at least the procedure in my mind - i need always to generate a whole keypair. Can this be done with the SeaHorse?! i really really look forward to a hint from you experts regards update: well i guess it worked ubuntu@T420s:~$ seahorse -v seahorse 43.0 GNUPG: /usr/bin/gpg (2.2.40) ubuntu@T420s:~$ and now i have to dive into all that!!
Private key is applied to secure your files or email, while the public key will handle decryption—just share the public key with the recipient. For details on configuring Seahorse GPG keys for email encryption, see this guide: https://www.linux.com/topic/desktop/how-...-seahorse/
Not exactly. It functions as both open and closed. The PGP "key" is actually a set of one or more key pairs, though I’ll try to simplify. Please bear with me, hoping I can clarify this. This group of keys is called a PGP identity. A key pair (often just called "key") consists of a private key and its matching public key. The public key is generated from the private key, which is why they always appear together as they are mathematically linked. To stay consistent with tools like Seahorse, any mention of "key" refers to a "key pair". When you first create a new PGP identity, it sets up a "master" key with at least the "Certify" function. There are four functions a key can perform: Certify © – reserved for the master key, used to approve changes to the identity. Encrypt (E) – typically for securing emails, files, etc. Sign (S) – mainly for digital signatures that confirm who sent the message and that it remains intact. Authenticate (A) – generally for verifying your own identity, such as when using a PGP key over SSH. Depending on system settings, the master key might also get the Sign and Encrypt features. Or, as usual, it could assign Sign to the master key while keeping a separate sub-key with only Encrypt. You can inspect the full structure in Seahorse or via the CLI with gpg, though it usually resembles this format: pub ed25519/0xDCBEC421827B0F27 2025-03-16 [SC] Key fingerprint = A273 F4F5 3F38 637B CC0E B4D5 DCBE C421 827B 0F27 uid [ultimate] Alice <[email protected]> sub cv25519/0x0F4CCC4C1D7D452E 2025-03-16 [E] In this case, the master key holds the shortened fingerprint (key ID) 0xDCBEC421827B0F27 and carries both Certify and Sign. The sub-key has only Encrypt. No Authenticate key is present here. The "uid" reflects the public identifier linked to the identity, such as Alice’s name and email. When sharing her identity, she distributes just the public keys for the master and any sub-keys. PGP actions are carried out using the appropriate (sub-)key based on its capabilities. For example, if Bob wants to send a private message to Alice, he uses her public identity and his own PGP tool with the matching sub-key fingerprint. Alice, in turn, can share her identity with others, distributing only the public keys. PGP operations rely on the (sub-)key that matches the required function. Sharing: Encryption goes to the key with E capability; signing uses the key with S. Authentication requires the key with A. Depending on defaults, some keys may also hold Sign and Encrypt. The exact layout can be checked in Seahorse or via the gpg command, though it generally displays something like this. This process enables secure, verified exchanges between parties like Alice and Bob.
G day hello @NoLeafClover and @C2dan88. Thanks for your prompt response and clear guidance. I’m really glad to be part of the forums now. Your explanations have made a big difference in understanding key pairs and PGP encryption. Just to confirm: when I create a new PGP identity in Seahorse, it generates both a private and public key as part of a pair. The main key often includes Certify © and possibly Sign (S), while an encryption sub-key with Encrypt (E) is usually added for that purpose. When sharing my public key, I’m actually distributing the public portion of my identity, including all related keys. For secure exchanges, both parties need their respective keys. A quick question: should I keep signing and encryption keys separate, or can I use the same key for both? Your detailed breakdown has really helped clarify things! Have a great evening.
You're welcome Yes. Yes, that's correct and is the most common case. The master key will certainly have the Certify © capability. The Encrypt (E) capability is usually not allowed on the master key by most PGP tools, though I'm not sure if it is or isn't according to the actual PGP spec. Yes. Yes This is an excellent and very astute question. I did think of adding some info on that but didn't want to make my reply too overwhelming. The short answer is - there is no widely agreed "best practice". But there is some good general advice. What would be most prudent is to set the main/master key to have only Certify © capability and use one or more subkeys for Sign (S) and Encrypt (E). Because the © key is the most important, as it can be used to make any changes to the whole PGP identity, the ideal scenario would be to only use it for actions that require © and nothing else. This means that, in a more advanced set up, you can strip the private key of the © key pair, back it up somewhere safe, and never have it see the light of day until it's needed. Then, for encryption and signing, both options are perfectly reasonable. There may be merit in having one subkey for signing and one for encryption. This way if one of them gets compromised (i.e. somebody who is not you finds out the private key) you only revoke this one key and can continue to use the other. This would be my personal recommendation. Here's what this set up might look like: pub ed25519/0x9FB35461E5CEC81E 2025-03-17 [C] Key fingerprint = 6986 CF24 CFCC B296 5638 243C 9FB3 5461 E5CE C81E uid [ultimate] Alice <[email protected]> sub cv25519/0xCCBF596FDB3EA3B2 2025-03-17 [E] sub ed25519/0xE357CD347D153305 2025-03-17 [S] It's also good practice to create a revocation certificate right at the start and keep it safe alongside the main private key. This allows you to quickly revoke the whole PGP identity if it's ever compromised. A PGP identity also supports multiple UIDs, so you can technically associate multiple email addresses with it. It is best, however, to keep a single uid per PGP identity to reduce the possible damage as a result of a compromised identity. Note, however, that while PGP encryption is secure, there are still caveats: The exchange of public keys between parties should, ideally, be done over a secure channel. Otherwise anyone can technically generate a PGP identity on behalf of any user identifier (e.g. name and email address). PGP itself does not provide for this. This is not an issue unique to PGP, but is worth keeping in mind. A commonly used public directory exists at OpenPGP.org which allows you to upload your public key and verify its ownership over email (uid email has to match). [Deprecated] PGP has a thing called the "web of trust" where people can verify each other's public keys and certify them with their own key, with the attestation becoming part of their public PGP identity. However, this is no longer in use due to common attacks that would flood a PGP identity with fake trust signatures making the PGP identity grow to a huge size, effectively making it unusable. PGP does not support forward secrecy, i.e. if a key or subkey is compromised then all previous as well as subsequent messages encrypted with the compromised key are effectively compromised too. Rotating keys or even whole identities is one possible solution but is cumbersome to manage and previous expired or revoked private keys will still need to be kept to allow access to previously encrypted data. Revocation relies on a well known place, e.g. a public directory such as the above, to inform people that a given key has been revoked. Key expiry dates and revocations are indicative. If detected, PGP tools will warn that a key has been revoked or expired but will not stop operations to be performed with this key. So while there is nothing "wrong" with PGP, and is still widely used in some use cases, there are legitimate concerns that may or may not be relevant depending on your so called "threat model". These are only some aspects as to why PGP isn't widely adopted everywhere. That said, there is no such thing as perfect security - it's always a balance. With good practice and awareness PGP can still be used effectively for end-to-end encryption between parties.