Stephan Beck wrote: >Carola Grunwald: >> Peter Lebbing wrote: >>>> You mean --try-secret-key doesn't overrule the key parameter that comes >>>> along with the encoded material? >>> >>> No, it specifies which keys to try for a hidden recipient. This is easy >>> to investigate if you create a few test private keys and create some >>> test messages. I did that earlier, and I could see no overruling >>> behaviour or even a preference to --default-key or --try-secret-key. >> >> You're right, unbelievable. I specify --try-secret-key with a >> >> [GNUPG:] ENC_TO 0000000000000000 18 0 >> >> message and gpg still tries out two dozen WME keys with a passphrase not >> valid for them. What a waste of time! > >If you knew the cacheIDs of all cached passphrases you could use > >"2.6.8 Remove a cached passphrase >-------------------------------- > >Use this command to remove a cached passphrase. > > CLEAR_PASSPHRASE [--mode=normal] <cache_id> > > The '--mode=normal' option can be used to clear a CACHE_ID that was >set by gpg-agent." > >for removing all passphrases but one (the one you would like to be used).
Removing all cached passphrases sounds great. But does that mean I have to invoke the agent directly using the Assuan protocol? And what would be the way to get a list of all valid cache_ids? > > >If you'd want to make sure that the right passphrase is provided, why >don't you use --pinentry-mode loopback >"Use a loopback pinentry. This fakes a pinentry by using > inquiries back to the caller to ask for a passphrase." That's what I actually do: | G:\MyGnuPG\gpg\gpg.exe --pinentry-mode loopback --no-default-recipient --no-default-keyring --keyring "G:\MyGnuPG\key\rcp.kbx" --status-fd 2 [...] --decrypt --command-fd 0 --try-secret-key F69A3C70E1A93A2A --passphrase "DNJwzwnRaUzhEr0Ys3XpnSY309DpXdk/Nu4f+sFPdQM" --output "G:\MyGnuPG\gpg\tmp\txt_clr.906" "G:\MyGnuPG\gpg\tmp\txt_enc.906" There's the id of a secret key with its passphrase, but if decoding doesn't succeed with that key-passphrase combination or if the key doesn't exist there are decryption attempts with all other secret keys in the private-keys-v1.d folder, which only waste time: | [GNUPG:] ENC_TO 0000000000000000 18 0 | [GNUPG:] KEY_CONSIDERED B5A49F253CE924DD2978A2C1F69A3C70E1A93A2A 0 <- the targeted one | [GNUPG:] KEY_CONSIDERED 5A2915D0E26A7FD3301A35D82F1E01D95F23CBA9 0 | [GNUPG:] KEY_CONSIDERED A2C2DA81C60217BA9FC60295F021F62304A579D2 0 | [GNUPG:] KEY_CONSIDERED ... AFAICS it always uses the same given passphrase with all the keys, which is good: | gpg: DBG: chan_0x0000009c <- INQUIRE PASSPHRASE | gpg: DBG: chan_0x0000009c -> D DNJwzwnRaUzhEr0Ys3XpnSY309DpXdk/Nu4f+sFPdQM What I need here is the restriction to just the given key. > > >Sorry, I can't reproduce your environment for now and only have these >"dispersed notes" exposed here (but found your description of your >system very instructive and largely followed it). I merely point you to >options the usefulness of which you are more experienced to assess. I appreciate every hint I can get on my way back to a fully operational stable system. :-) Many thanks and kind regards Caro _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
