I had some trouble using my existing private keys together with the pEp-engine - it kept generating new keys directly after I enforced pep mode. Finally I solved it. Here are some hints if someone has similar problems:
1.) pEp seems to have trouble with some keys having passphrases. So it will generate new keys. Solution: Remove the passphrase from your keys:
gpg --edit-key FINGERPRINTOFTHEKEY passwd
When GnuPG prompts for the new passphrase, just hit enter.
Unfortunately, I wasn't able to remove the passphrase from some keys on debian. An error ocurred:
gpg Fehler beim Ändern der Passphrase: Keine Passphrase angegeben
gpg Error changing passphrase: No passphrase given.
Probably some bug or issue with gnupg.conf or pinentry. As a workaround I removed the password on a windows machine with kleopatra and imported it again in linux.
2.) pEp is not able to work with two accounts using the same key, even if both adresses are written as UID on the key. It will bind the first account and it's adress to the key ... and for the second account it will generate a new key. Solution: Not really - you have to switch back to classic mode or remove the second account. I ended up removing one account and set up the second email adress as alias adress in the email provider settings. pEp accepts the second email adress, if it is used within the account and entered on the key. Primary Email on they key MUST be email adress of the account.
3.) pEp is not at all able to work with multiple instances/profiles of thunderbird running at the same time (using the -P flag or the profile manager). While encrypting an email it asks for the passphrase of a totally different key from another profile and then sends the email unencrypted. Solution: Integrate all you email accounts into one profile.
Hope this helps and those things get fixed soon - unfortunately no bug tracker available on the pep site :-(
Last edit: Furlong 2018-07-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks for posting this! I think it's a good starting point for people who want to switch to pEp from another kind of pgp setup.
pEp has a limited compatibility with pgp / gnupg generated keys and does not intend to change that - to limit scope and complexity. This results in some of the behaviour you describe which will not change.
1.) To make things usable pEp does not allow passphrases - it sees the burden with the system setup (FDE!) and the operating system (applications in their own world. Think Android/iOS. I know that sucks on classic OSs :/) to keep your key safe.
2.) pEp has the concept of not telling your communication partners of your other identities (in this case, email-addresses) - that's something the user should decide. So as a consequence, no multiple uids on one key
3.) sounds like a bug indeed. Unclear to me where in the software stack the bug is. If it's on the pEp side of things, pEp might consider it wontfix (at least in the near future),
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the insight, but I'm still not sure if you are right in all points:
1.) The draft states:
"Passphrases to protect a user's private key MUST be supported by pEp
implementations, but SHALL NOT be enforced by default. That is, if a
pEp implementation finds a suitable (i.e., secure enough)
cryptographic setup, which uses passphrases, pEp implementations MUST
provide a way to unlock the key." https://tools.ietf.org/html/draft-birk-pep-02#section-5.3
So, passphrase should work. It did indeed work in one setup, but I had problems with some other keys - could be though this occured because of other problems.
2.) That makes sense ... but mails to a second ID on the key get decrypted just fine. At the moment, the two-account-setup is the only part not working.
I'm fine with possible restrictions, that make it easy for newcomers. But it would be nice to have precise information about the process of key validation done by the pep engine - at least in the enigmail protocol. Took me some days to find out those problems by try and error.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1.) Hm, that seems to be a difference between between the standard draft and the actual implementation :/ On platforms with gpg-agent it might just work because pEp doesn't touch that moch, but there are definitely applications that don't work with encrypted keys (pEp for Android, which uses gpg but doesn't have gpg-agent, and I guess pEp for iOS - but that's off topic for this forum)
2.) that actually makes sense even without pEp: on sending the MUA decides which key it uses for signing - and there it takes the one with the matching UID. In enigmail/classic you can also explicitely configure one. On receiving, the MUA looks for a private key with which to decrypt a message - and there's no need for an email account / alias to be associated with that. Think for example of a mailing list for which there is a gpg-key so third parties can contact the people forming the mailing list encrypted.
Very sorry about hearing you've spend that much time on that. And yes, there's a lack of documentation - on the other Hand pEp tries to make things easy enough that on new setups things just work. Which obviously doesn't hold for all "old" pgp-setups. There's also a forum dedicated to pEp: pEp community
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had some trouble using my existing private keys together with the pEp-engine - it kept generating new keys directly after I enforced pep mode. Finally I solved it. Here are some hints if someone has similar problems:
1.) pEp seems to have trouble with some keys having passphrases. So it will generate new keys. Solution: Remove the passphrase from your keys:
Probably some bug or issue with gnupg.conf or pinentry. As a workaround I removed the password on a windows machine with kleopatra and imported it again in linux.
2.) pEp is not able to work with two accounts using the same key, even if both adresses are written as UID on the key. It will bind the first account and it's adress to the key ... and for the second account it will generate a new key. Solution: Not really - you have to switch back to classic mode or remove the second account. I ended up removing one account and set up the second email adress as alias adress in the email provider settings. pEp accepts the second email adress, if it is used within the account and entered on the key. Primary Email on they key MUST be email adress of the account.
3.) pEp is not at all able to work with multiple instances/profiles of thunderbird running at the same time (using the -P flag or the profile manager). While encrypting an email it asks for the passphrase of a totally different key from another profile and then sends the email unencrypted. Solution: Integrate all you email accounts into one profile.
Hope this helps and those things get fixed soon - unfortunately no bug tracker available on the pep site :-(
Last edit: Furlong 2018-07-26
Hi furlong and everyone,
thanks for posting this! I think it's a good starting point for people who want to switch to pEp from another kind of pgp setup.
pEp has a limited compatibility with pgp / gnupg generated keys and does not intend to change that - to limit scope and complexity. This results in some of the behaviour you describe which will not change.
1.) To make things usable pEp does not allow passphrases - it sees the burden with the system setup (FDE!) and the operating system (applications in their own world. Think Android/iOS. I know that sucks on classic OSs :/) to keep your key safe.
2.) pEp has the concept of not telling your communication partners of your other identities (in this case, email-addresses) - that's something the user should decide. So as a consequence, no multiple uids on one key
3.) sounds like a bug indeed. Unclear to me where in the software stack the bug is. If it's on the pEp side of things, pEp might consider it wontfix (at least in the near future),
Thanks for the insight, but I'm still not sure if you are right in all points:
1.) The draft states:
2.) That makes sense ... but mails to a second ID on the key get decrypted just fine. At the moment, the two-account-setup is the only part not working.
I'm fine with possible restrictions, that make it easy for newcomers. But it would be nice to have precise information about the process of key validation done by the pep engine - at least in the enigmail protocol. Took me some days to find out those problems by try and error.
1.) Hm, that seems to be a difference between between the standard draft and the actual implementation :/ On platforms with gpg-agent it might just work because pEp doesn't touch that moch, but there are definitely applications that don't work with encrypted keys (pEp for Android, which uses gpg but doesn't have gpg-agent, and I guess pEp for iOS - but that's off topic for this forum)
2.) that actually makes sense even without pEp: on sending the MUA decides which key it uses for signing - and there it takes the one with the matching UID. In enigmail/classic you can also explicitely configure one. On receiving, the MUA looks for a private key with which to decrypt a message - and there's no need for an email account / alias to be associated with that. Think for example of a mailing list for which there is a gpg-key so third parties can contact the people forming the mailing list encrypted.
Very sorry about hearing you've spend that much time on that. And yes, there's a lack of documentation - on the other Hand pEp tries to make things easy enough that on new setups things just work. Which obviously doesn't hold for all "old" pgp-setups. There's also a forum dedicated to pEp: pEp community