I maintain a PasswordSafe for all my passwords, including Enigmail. This
permits a very randomised passphrase to be generated, but I then have to
make it visible in PasswordSafe and key it in to Enigmail by hand which
I find somewhat tedious and potentially error prone.
I'm sure there's a good reason for lack of pasting support, but I can't
see it from here. Ant ideas?
A secondary problem related to this behaviour is that Enigmail's
dialogue box requesting the passphrase grabs window focus and so
PasswordSafe has to be invoked first and positioned so that Enigmail'
dialogue doesn't overlap. Again, my question is whether this is a bug,
or intended behaviour?
Peter HB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
Hi I've been struggling with this issue of pass phrase and due to the amount of mail I have encrypted, I can't seriously change my pass phrase. please give the possible solution of doing that
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Enigmail version 1.8.2 (20150416-1748) gpg executable /usr/bin/gpg2
I set up Enigmail, in Thunderbird, a couple of days ago, using a horrendously-long pass phrase, which I pasted in from a spread sheet (used for creating these). All went well, and I succeeded with the test message exchange with edward-en(a)fsf.... However, today, upon trying to view the encrypted message (or to do anything else with Enigmail encryption), I found I was presented with a Pinentry form that does not allow pass phrase pasting.
OK, password pasting may be an information security crime, but this seems like entrapment.
The less-authoritarian command prompt afforded a way out. Details were here: http://www.cyberciti.biz/faq/linux-unix-gpg-change-passphrase-command/
.
Guarding against link decay, the magic words are:
gpg --edit-key Your-Key-ID-Here
gpg> passwd
gpg> save
{gpg --version
gpg (GnuPG) 1.4.16
}
A brief explanation (or expression of my understanding):
The pass phrase is used, locally, to encrypt the private PGP key in the computer's storage. It actually has nothing to do with e. mail encryption. If you're using encrypted /home, and never step away from your sessions without locking them, you could be just as happy without having a pass phrase in the mix. Additional note: if you specify “armor” in exporting the private key (i.e. “gpg --armor --export-secret-keys”) the export file carries forward encryption with the pass phrase.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found I was presented with a Pinentry form that does not
allow pass phrase pasting.
This is a GnuPG design decision. We have no influence over it, we
weren't consulted, and we have no ability to change it. Your remarks
should probably be directed to the GnuPG-Users mailing list.
If you're using encrypted /home, and never step away from
your sessions without locking them, you could be just as happy without
having a pass phrase in the mix.
This would give me the heebie-jeebies. An encrypted /home only protects
you from your hard drive being stolen while the power is off. If you
get hit by malware, which is unfortunately commonplace nowadays, then
whoever just hijacked your machine has access to your private certificate.
Passphrases are an extremely good idea and we highly recommend them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually, I'd already read some posts making clear that the thou shalt not paste feature is courtesy of GnuPG, and that resistance is futile. In theory (according to this software engineering titan who has written nothing more substantial than an odd snippet of VBA for about the past decade), Engimail could bypass the restriction (as it's all zeros and ones), but I was entirely undecided as to whether it should, regardless of how trivial that might be – separation of concerns and making a complex system no less simple than it can be. Furthermore, I wouldn't even feel sure of myself in saying GnuPG has made the wrong decision.
So, I was neither berating Enigmail for the pasting inability, nor imploring it to (re-) introduce the feature. Sorry I didn't make a better job of getting my point across.
My point was that there was an inconsistency in the Enigmail user experience between the setting of the pass phrase and the subsequent provision of it. I was able to set a pass phrase I could never, practically speaking, type in, by pasting it, but was left unable to supply it the same way for any subsequent access to the resource.
Now, the inconsistency, at my level of ignorance, may stem from the way Enigmail uses GnuPG, or may be purely internal to GnuPG. In the latter case, I think it would be reasonable for Enigmail to take some steps (or some more obvious step) to try to save the user from the pitfall.
But, conceivably, I have overlooked a critical detail that makes this quite a puny corner case: when I added Enigmail, it showed me a warning about my having version 1.x (my vagueness, not Engimail's; it may have been 1.4 something) of GnuPG. So, I went off and got gnupg2, and restarted Thunderbird. Possibly, however, restarting the application may not have been enough and setting the pass phrase, through pasting, might have proceeded under the outmoded GnuPG version. So, sorry if this is a big WOT.
On your closing point, no argument. I don't know how well hardened the key chain is against malware, but it seems obvious it shrinks the attack surface considerably. It's more that I don't, yet, see malware as much of a threat, on my Ubuntu distributions. I'd said “happy”, not “safe”; it's a trade-off between convenience and security, but I see the speculation over the unknown reader's choices was pretty pointless! I'd brought it up to emphasise that PGP is for providing security of privacy in the jungle of the internet and it places no restrictions upon the choices we make about protecting our data on our own devices.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In theory ... Engimail could bypass the restriction ... but I was
entirely undecided as to whether it should, regardless of how trivial
that might be.
It would be quite difficult, given our current manpower. GnuPG
passphrase dialogs, as of GnuPG 2.x, are called "pinentry programs".
Pinentry programs are native code, which would make things difficult for
us: for years we've been trying to pull native code out of Enigmail
and replacing it with JavaScript, and now we'd have to put it back in.
To make matters worse, Thunderbird has taken a strong stance against
native code in plugins. So we'd have to wrestle with that, too.
In the end, it's just a lot easier -- and a lot better use of our
limited development time -- to go along with GnuPG's pinentry.
So, I was neither berating Enigmail for the pasting inability, nor
imploring it to (re-) introduce the feature. Sorry I didn't make a
better job of getting my point across.
No worries at all. I hope this explanation sheds some light onto why we
made the decision we did. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My point was that there was an inconsistency in the Enigmail user experience between the setting of the pass phrase and the subsequent provision of it. I was able to set a pass phrase I could never, practically speaking, type in, by pasting it, but was left unable to supply it the same way for any subsequent access to the resource.
We are aware of this inconsistency, but again, this is not our decision. GnuPG has decided that for version 2.0 and onwards, passphrase handling should be done by GnuPG and its tools and not with front-ends like Enigmail anymore. We cannot fix this.
We could change the User Interface to accept passwords only from the pinentry-tools provided by GnuPG, but that would lead to an even worse user experience: you'd get twice a password dialog to type your password, without any further explanation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I maintain a PasswordSafe for all my passwords, including Enigmail. This
permits a very randomised passphrase to be generated, but I then have to
make it visible in PasswordSafe and key it in to Enigmail by hand which
I find somewhat tedious and potentially error prone.
I'm sure there's a good reason for lack of pasting support, but I can't
see it from here. Ant ideas?
A secondary problem related to this behaviour is that Enigmail's
dialogue box requesting the passphrase grabs window focus and so
PasswordSafe has to be invoked first and positioned so that Enigmail'
dialogue doesn't overlap. Again, my question is whether this is a bug,
or intended behaviour?
Peter HB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTx//3AAoJEG5Xbr4KyQGc/nwH/RRrMVNLaRuIESPXO9F6NDWB
eFA6tLDVJBxWb5p60jQdzQIanKn9No/Vq002ulRrDhkP3yKXm0cft7ZqFsu0YIds
mndH5dmuus1fc0MscFQpHChcvKWCN4olEc1/SpqMifiawlVPFTIXv04SO5BzLtIx
pP8ChCaRqvPEcJT8Z5hx2S7cCBEloxH34Cgv9buKX9tWF/AG6pVCv74E4Ax4mNwj
M5UcLZjgx9nRWMSPHr44oZvE8pu9Cw9CCVl3H0VqMxYwlSZlrsK6WzedVnJ1Ynp6
Ah2IS2Q469z7b4ibzRpuuHPaIk7DU/kAcwgtkYHuSnpjOmUUo/I2hLiT/Z1vuqA=
=n6Em
-----END PGP SIGNATURE-----
The behavior you describe stems from pinentry which is part of the GnuPG tools (on Windows gpg4win). Enigmail does not influence what pinentry does.
Many thanks for your response. I'll now chase my problems via GnuPG.
Regards
I had the same issue using KeyPassX instead of PasswordSafe. I found a solution here http://blog.jdpfu.com/2011/03/28/making-keepassx-work-with-pinentry-and-enigmail
I don't know if you can solve the problem with PasswordSafe but at least it gives you some extra information. Hope it helps.
Wouter
Hi I've been struggling with this issue of pass phrase and due to the amount of mail I have encrypted, I can't seriously change my pass phrase. please give the possible solution of doing that
Enigmail version 1.8.2 (20150416-1748) gpg executable /usr/bin/gpg2
I set up Enigmail, in Thunderbird, a couple of days ago, using a horrendously-long pass phrase, which I pasted in from a spread sheet (used for creating these). All went well, and I succeeded with the test message exchange with edward-en(a)fsf.... However, today, upon trying to view the encrypted message (or to do anything else with Enigmail encryption), I found I was presented with a Pinentry form that does not allow pass phrase pasting.
OK, password pasting may be an information security crime, but this seems like entrapment.
The less-authoritarian command prompt afforded a way out. Details were here: http://www.cyberciti.biz/faq/linux-unix-gpg-change-passphrase-command/
.
Guarding against link decay, the magic words are:
gpg --edit-key Your-Key-ID-Here
gpg> passwd
gpg> save
{gpg --version
gpg (GnuPG) 1.4.16
}
A brief explanation (or expression of my understanding):
The pass phrase is used, locally, to encrypt the private PGP key in the computer's storage. It actually has nothing to do with e. mail encryption. If you're using encrypted /home, and never step away from your sessions without locking them, you could be just as happy without having a pass phrase in the mix. Additional note: if you specify “armor” in exporting the private key (i.e. “gpg --armor --export-secret-keys”) the export file carries forward encryption with the pass phrase.
This is a GnuPG design decision. We have no influence over it, we
weren't consulted, and we have no ability to change it. Your remarks
should probably be directed to the GnuPG-Users mailing list.
This would give me the heebie-jeebies. An encrypted /home only protects
you from your hard drive being stolen while the power is off. If you
get hit by malware, which is unfortunately commonplace nowadays, then
whoever just hijacked your machine has access to your private certificate.
Passphrases are an extremely good idea and we highly recommend them.
Rob,
Thank you.
Actually, I'd already read some posts making clear that the thou shalt not paste feature is courtesy of GnuPG, and that resistance is futile. In theory (according to this software engineering titan who has written nothing more substantial than an odd snippet of VBA for about the past decade), Engimail could bypass the restriction (as it's all zeros and ones), but I was entirely undecided as to whether it should, regardless of how trivial that might be – separation of concerns and making a complex system no less simple than it can be. Furthermore, I wouldn't even feel sure of myself in saying GnuPG has made the wrong decision.
So, I was neither berating Enigmail for the pasting inability, nor imploring it to (re-) introduce the feature. Sorry I didn't make a better job of getting my point across.
My point was that there was an inconsistency in the Enigmail user experience between the setting of the pass phrase and the subsequent provision of it. I was able to set a pass phrase I could never, practically speaking, type in, by pasting it, but was left unable to supply it the same way for any subsequent access to the resource.
Now, the inconsistency, at my level of ignorance, may stem from the way Enigmail uses GnuPG, or may be purely internal to GnuPG. In the latter case, I think it would be reasonable for Enigmail to take some steps (or some more obvious step) to try to save the user from the pitfall.
But, conceivably, I have overlooked a critical detail that makes this quite a puny corner case: when I added Enigmail, it showed me a warning about my having version 1.x (my vagueness, not Engimail's; it may have been 1.4 something) of GnuPG. So, I went off and got gnupg2, and restarted Thunderbird. Possibly, however, restarting the application may not have been enough and setting the pass phrase, through pasting, might have proceeded under the outmoded GnuPG version. So, sorry if this is a big WOT.
On your closing point, no argument. I don't know how well hardened the key chain is against malware, but it seems obvious it shrinks the attack surface considerably. It's more that I don't, yet, see malware as much of a threat, on my Ubuntu distributions. I'd said “happy”, not “safe”; it's a trade-off between convenience and security, but I see the speculation over the unknown reader's choices was pretty pointless! I'd brought it up to emphasise that PGP is for providing security of privacy in the jungle of the internet and it places no restrictions upon the choices we make about protecting our data on our own devices.
It would be quite difficult, given our current manpower. GnuPG
passphrase dialogs, as of GnuPG 2.x, are called "pinentry programs".
Pinentry programs are native code, which would make things difficult for
us: for years we've been trying to pull native code out of Enigmail
and replacing it with JavaScript, and now we'd have to put it back in.
To make matters worse, Thunderbird has taken a strong stance against
native code in plugins. So we'd have to wrestle with that, too.
In the end, it's just a lot easier -- and a lot better use of our
limited development time -- to go along with GnuPG's pinentry.
No worries at all. I hope this explanation sheds some light onto why we
made the decision we did. :)
We are aware of this inconsistency, but again, this is not our decision. GnuPG has decided that for version 2.0 and onwards, passphrase handling should be done by GnuPG and its tools and not with front-ends like Enigmail anymore. We cannot fix this.
We could change the User Interface to accept passwords only from the pinentry-tools provided by GnuPG, but that would lead to an even worse user experience: you'd get twice a password dialog to type your password, without any further explanation.