Extraction of decryption session key without copying complete encrypted file

[Fiedler Roman]

> Von: Peter Lebbing [mailto:peter at digitalbrains.com]
>
> On 25/08/17 18:40, Fiedler Roman wrote:
> > Idea:
> > 1) Extract all GPG preambles of files to be decrypted to a single file
> > (working)
> > 2) Batch decrypt all preambles from the input file on the trusted
> equipment
> > (not working in batch mode)
> > 3) Decrypt all storage elements with the list of session keys
> (working)
>
> It doesn't sound like you need agent forwarding at all. I would expect
> that you can decrypt with a session key without an agent, since the
> agent is only consulted to get the session key, but you already have it.
>
> Step 2 is not working, but it is all on the system with the private key,
> with a locally running agent. Dit you either gpg-preset-passphrase or
> remove the passphrase from the key?

The keys are currently software-only and have a passphrase consuming at least 
about 2 non-parallelizable CPU-seconds in the KDF for security - thus making 
repeated key entry a little slow. I will try the "gpg-preset-passphrase", 
which could be a valid workaround while all elements are encrypted with the 
same key - what will/should change as soon as new access control zones are 
attached to the system.

> If the agent needs to prompt the
> user with a pinentry, but there is no human since it is batch operation,
> it will error out. So it needs to know the passphrase already or the
> passphrase needs to be removed.

I hoped, that there would be some way to still archive it, as the session key 
extraction script works on a batch of input elements, but the agent is started 
on a separate terminal, where the admin supervising the process can input 
passwords or provide the appropriate hardware tokens in future implementation. 
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.

> I think agent forwarding is an alternative to your idea, not a way to
> implement it. With agent forwarding, the remote system without the
> private key would ask the forwarded agent to decrypt the
> public-key-encrypted-session-key for it and obtain the session key that
> way and that would avoid all the extra steps. Provided it worked :-).

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

LG Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4814 bytes
Desc: not available
URL: </pipermail/attachments/20170828/421f6f16/attachment-0001.bin>