Extraction of decryption session key without copying complete encrypted file

[Peter Lebbing]

On 28/08/17 09:57, Fiedler Roman wrote:
> But it seems, that the gpg-decryption process attempts to trigger the 
> pinentry, not the agent and so the access to the correct controlling TTY 
> fails.

The gpg process communicates its TTY to the agent so the pinentry knows
where to pop up. This is a feature, not a bug. But when you deliberately
want to pop it up elsewhere...

I almost had it working in a test:

- Start an x-terminal, invoke "tty" and see that it is /dev/pts/7.

Start another x-terminal and:

$ unset DISPLAY
$ export GPG_TTY=/dev/pts/7
$ echo test | gpg -o /dev/null -s

And indeed the pinentry-curses popped up on the other terminal. BUT: a
few of my keystrokes went to the bash shell that was running there
instead of the popped up pinentry. So the passphrase I entered in the
pinentry was missing characters, and those characters were typed as part
of a command on the command line.

So my idea that GPG_TTY would override the terminal was correct, but it
didn't actually work in the end.

It seems that it's easier if you use a graphical pinentry, by just
overriding DISPLAY in the session where the batch runs.

> Yes, that should work also. The different Linux-Distributions, GPG versions on 
> the various machines might be a permanent source of trouble

Well, agent forwarding to access a remote private key only works on
GnuPG 2.1 (and later, once later exists). In general, mixing versions is
not a good idea, no, not even between minor versions. But possibly this
restriction is less stringent for the forwarded socket, because I expect
there it will be common to mix versions. It might have been designed to
account for this.

> and also the 
> process is not that straight forward: one should still extract all required 
> session keys at once and use them later on - otherwise the admin holding the 
> keys and the admin using the data have to work coordinated for hours until all 
> elements are decrypted and used (e.g. restored). With session keys, the key 
> holder performs the session key extraction on the list of requested elements 
> (15min with connecting, selecting the elements, ...) and then forward the list 
> of keys to the user.

You should consider whether you should use a passphrase at all. Usually,
with unattended decryption, it's just bothersome. The passphrase
protects the key at rest. If you're worried about attackers getting
access to a backup, you could do the gpg-preset-passphrase dance. If an
attacker that gets the privileges to read the contents of your private
key dir is not part of your threat model (for instance, because it's
game over), you might as well remove the passphrase and be done with
this bothersome pinentry stuff, as FAQ entry 8.20 [1] says.

The admin that is submitting a list of PKESK packets already effectively
has unfettered access to your decryption key as far as usage is
concerned, no need to worry about them. And using just a forwarded agent
connection, they still have no access to the key material.

HTH,

Peter.

[1] <https://www.gnupg.org/faq/gnupg-faq.html#automated_use>

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170828/310d9b81/attachment.sig>