> Von: Matthias Apitz [mailto:g...@unixarea.de] > > El día viernes, agosto 04, 2017 a las 01:59:57p. m. +0200, Werner Koch > escribió: > > > On Wed, 2 Aug 2017 15:52, roman.fied...@ait.ac.at said: > > > > > How to decrypt large files, e.g. gpg-encrypted backups, without > copying them to the machine with the GPG private key? > > > > With GnuPG 2.1 this is easy: You use ssh's socket forwarding feature > to > > forward gpg-agent's restricted remote socket, for example > > > > /run/user/1000/gnupg/S.gpg-agent.extra > > > > to the host and there you run gpg which will then connect back to the > > agent on your desktop. For details see > > > > https://wiki.gnupg.org/AgentForwarding > > But this implies that everyone with priv access on the remote host could > abuse your secret key on your localhost, especially when a GnuPG-card is > used and you entered the PIN to unlock the secret key. I'm wrong?
Of course, that is why, I want to get rid of the private keys after some time, probably using measures as depicted in [1]. >From the risk analysis view: If the attacker is already on the source >machines, just monitoring admin behaviour, he is likely to learn how the >session key exchange procedure will work and may manipulate the procedure in >such a way, that I will decrypt messages for him anyway. So that first >incident cannot be mitigated in any way - the drawback of performing just any >operation on an untrusted computer system. The only difference would be: a) using the agent-port might be more stealthy, especially when the agent does not display information, how many decryption request were processed. Hence [1] to perform a single decryption request at most before user interaction is needed. b) interfacing the agent port might be easier than understanding a 25 line shell script and manipulating it in such a way, that it replaces the data to be decrypted before forwarding it. After that first incident, risk of agent port is higher: with the port, attacker can continue to send more sign/decrypt requests. Without that, admin would notice, that the session key produced by the decryption procedure was not correct to decrypt the target file, thus some manipulation has occurred. If fast, he might even disconnect the VM network adapter of the affected machine before the attack could have decrypted and transferred the whole file (unless he did not transfer it beforehand and just stole the session key the moment it was provided). LG Roman [1] https://lists.gnupg.org/pipermail/gnupg-users/2017-August/058834.html
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
