Mailing List Archive: GnuPG: users

pinentry

Index | Next | Previous | View Threaded

auto15963931 at hushmail

Apr 4, 2012, 12:03 PM

Post #1 of 4 (247 views)
Permalink

pinentry

I use gpg on Windows OS. On the command line when I use this
command:

gpg -d filename.asc

a pinentry window pops up requesting my passphrase. If it happens
that the message was encrypted with the option --throw-keyids, then
the pinentry window, not knowing which key was used, starts with
one of my keys arbitrarily and requests the passphrase for it. I
have two questions about this procedure. First, if I know which
key was used and I want to select it, I can click the "Cancel"
button at the time I see the arbitrary key dialogue window, and
then the program will select another key, again apparently
arbitrarily, and so on in succession, until it gets to the one I
want, at which time I can enter the correct passphrase and get the
decrypted result. However, much of the time I find that using this
procedure does not cause the pinentry dialogue to move from one key
to another but instead causes the dialogue window to close after
either the first or second clicking on the cancel button instead of
continuing on down through the complete list of keys I have
available. It just fails to decrypt. This failure occurs mostly
when I first try to use the procedure, but then it starts working
properly after a few tries even though I do exactly the same steps
each time. Why does it fail initially? Is this a known issue?

I have noticed a number of instances of failures during batch
decryption too, even though the pinentry dialogue does not arise of
course. These failures result in the "--status-file" indicating
that the decryption failed although in fact I can find the
decrypted message present.

Secondly, what is the correct way to handle this sort of procedure
under these circumstances so that indeed all the keys would be
tried each time? My initial thought is to include the option "--
try-all-secrets" in order to prevent the failure and premature
closing of the decryption attempts during batch processes. Thanks.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

mailinglisten at hauke-laging

Apr 4, 2012, 7:50 PM

Post #2 of 4 (238 views)
Permalink

Re: pinentry [In reply to]

Am Mi 04.04.2012, 14:03:26 schrieb auto15963931 [at] hushmail:
> I use gpg on Windows OS. On the command line when I use this
> command:
>
> gpg -d filename.asc

> to another but instead causes the dialogue window to close after
> either the first or second clicking on the cancel button

This does not happen here (Linux, though). I don't know how to tell gpg which
key(s) to try first but if you use the command line then there's a work
around: You may call gpg with
--no-default-keyring
--keyring
--secret-keyring
and point it at a file which contains one key only.

I assume that gpg tries the keys in the order in which they are in the
keyring. Thus you may export all keys (secret and public), rename the keyring
files and import the keys in the desired order. This may have to be repeated
after changed to the keys (I don't know how the keyring files work).

Hauke
--
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814

Attachments:

signature.asc (0.54 KB)

ml at kairaven

Apr 5, 2012, 6:27 AM

Post #3 of 4 (248 views)
Permalink

Re: pinentry [In reply to]

Hi,

> This does not happen here (Linux, though). I don't know how to tell gpg which
> key(s) to try first but if you use the command line then there's a work
> around: You may call gpg with
> --no-default-keyring
> --keyring
> --secret-keyring
> and point it at a file which contains one key only.

gpg2 man page:

--try-secret-key name (>= gpg 2.1?)
For hidden recipients GPG needs to know the keys to use for trial
decryption. The key set with --default-key is always tried first...

so, put "default-key key-id" in gpg.conf and this key will be tried first.

--default-key name
Use name as the default key to sign with. If this option is not used,
the default key is the first key found in the secret keyring.

So i think, if you have not a default-key defined in gpg.conf, the first
secret key will be tried.

--
Ciao
Kai

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

auto15963931 at hushmail

Apr 7, 2012, 8:31 AM

Post #4 of 4 (235 views)
Permalink

Re: pinentry [In reply to]

On 4/4/2012 9:50 PM, Hauke Laging wrote:
> This does not happen here (Linux, though).

Hauke, hello. I expect when I get to the bottom of it all, I will find
the fault is caused not by Windows but by my error or need for an
adjustment of some kind. I was hoping that my description would trigger
someone's idea about a similar experience so that they could provide a
pointer to jump start my fixing the issue. Anyway, I have made some
progress.

[snip]

> However, much of the time I find that using this
> procedure does not cause the pinentry dialogue to move from one key
> to another but instead causes the dialogue window to close after
> either the first or second clicking on the cancel button instead of
> continuing on down through the complete list of keys I have
> available. It just fails to decrypt. This failure occurs mostly
> when I first try to use the procedure, but then it starts working
> properly after a few tries even though I do exactly the same steps
> each time. Why does it fail initially? Is this a known issue?

This part of the problem still exists. Individually trying to decrypt a
file encrypted with throw-keyids will fail, often but not always, to try
all the keys before aborting the effort. I can prevent the problem by
using "--try-all-secrets"; but, so far as I can see, this problem arises
only during individual file decryption and not during batch decryption
procedures. At least, this has been my experience up to now.

It is a puzzling phenomenon and not apparent to me what is behind it. It
almost seems like a memory thing or caching issue, but I'm not sure, yet.

>
> I have noticed a number of instances of failures during batch
> decryption too, even though the pinentry dialogue does not arise of
> course. These failures result in the "--status-file" indicating
> that the decryption failed although in fact I can find the
> decrypted message present.

This part I have solved. My batch routine was overwriting the good
output after the routine looped through the files again. I have changed
it now to circumvent the occurences and I get the correct results.

--

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads