Feature request: handle multiple encryption subkeys on different smart cards intelligently

[Naftuli Tzvi Kay]

Thank goodness! I'm glad I was on to something here, moreso glad that I'm
not hearing "it's not a bug, it's a feature™" as is unfortunately common to
hear these days.

I've yet to try using the --try-all-secrets in --batch mode, I'm not sure
if that will help remedy the problem. Do note that I'm using GnuPG 1, as
it's in an initramfs setting. Would that setting help remedy the problem in
the interrim?

I don't know what my options are in initramfs for using GnuPG without
piping the password in with the cryptsetup askpass command; I assume that
askpass does some magic to grab keyboard input that the gpg binary itself
probably wouldn't be able to do. If I'm able to get gpg working
interactively instead of reading the passphrase from STDIN, I can just
endure having to press 'c' several times until everything is right in the
world and it finds the right decryption key in hardware.

Thanks,
 - Naftuli Tzvi

On Tue, Jun 9, 2015 at 5:57 AM, NIIBE Yutaka <gniibe at fsij.org> wrote:

> Hello,
>
> Thank you for detailed report.  It helps me a lot to understand your
> situation.
>
> Let me explain current GnuPG implementation.
>
> Basically, current implementation processes OpenPGP packets one by
> one.
>
> On 06/09/2015 07:16 AM, Naftuli Tzvi Kay wrote:
> > The process it seems to use is like this:
> >
> >  1. Check if $ENC_SUBKEY_A's secret key is present: it's not.
> >  2. Complain about the card not being present:
> >     Please remove the current card and insert the one with serial number:
> >         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> >     Hit return when ready or enter 'c' to cancel
> >  3. Hit c until it gets to the right key and prompts for the smart
> >     card PIN. This can take a while, as I have 3 cards per identity.
>
> Correct.  Note that this behavior is not for smartcard only, it also
> applies to private keys on file system.
>
> > What it /should/ do is this:
> >
> >  1. Examine the file and determine which keys can decrypt it. _If_ a
> >     smart card is present _and_ the smart card's secret key stub in
> >     secring.gpg can decrypt the file, immediately defer to using that
> >     card.
> >  2. If no card is present or the file is --hidden-recipient, try
> >     decrypting with any present keys in the keyring whose smart card is
> >     present.
> >  3. If there are no present keys, the present key can't decrypt the
> >     file, or the present key failed to decrypt the file, then start
> >     prompting to "insert the key known as ...".
>
> Yes, I agree.
>
> From the implementation viewpoint, it will be something like:
>
>    (1) gpg frontend parses all packets for ESK (Encrypted Session Key)
>        sequence.
>
>    (2) Then, talks to gpg-agent for available private keys to decide
>        which private key to decrypt.
>
>    (3) Asks gpg-agent to decrypt.
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150609/5747ed1d/attachment.html>