> Von: Peter Lebbing [mailto:pe...@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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
