Hello Stefan, Thanks for your helpful reply!
Stefan Claas writes: > halfdog wrote: > >> Hello list, >> >> I just noticed that gpgv2 packaged for Debian does not include >> the "gpgsplit" and "pgpdump" tools any more. >> >> Is there any replacement available for them, e.g. by option >> to main "gpg" binary? > > As an alternative you may check out the original pgpdump utility > and sequoia pgp for splitting packets. > > http://www.mew.org/~kazu/proj/pgpdump/en/ Oh, interesting. This might have been an inconsistency in my standard procedures as "pgpdump" still seems to be available as a package on Debian Bullseye, but was not installed by the install automation system on the target device in question. I updated the configuration to have it installed during initial setup. > https://docs.sequoia-pgp.org/sq/index.html Oh, seems very nice, but Debian Bullseye is packaging only the verifier at the moment. Packaging is quite useful when wanting it preinstalled and updated automatically on multiple devices. Do you know if there are plans to get it into Debian Bullseye or at least run it via own deb repositories? As you seem to know about both gnupg and Sequoia, may I ask your opinion if it is possible to implement following use case with one of both? There are multiple devices in the field, which cannot efficiently be protected against physical access. These devices contain a number of quite large (MBs to GBs) encrypted files with historic data, which are usually not needed during normal operation. Therefore the decryption key is not available on the device. When something fails, this data might need to be reprocessed. Due to the expensive/slow mobile link it would be painful to transfer the encrypted file to the centralized server to decrypt them here and send back the decrypted data over the slow link. On the other side agent forwarding would keep your private key available to a low-security remote device for a long time until all the files are decrypted and does not give you any realistic control, what is done with your private key when operating on a larger batch of files (some thousand key operations which would be error prone/slow to review and acknowledge all one by one). The old procedure therefore was: 1) Use pgpsplit remotely to split the first KB of each encrypted file to get the encryption header packet. 2) Transfer all those packets over the slow link. 3) Perform some packet check with pgpdump and then extract the session keys from all those packets locally. 4) Send back a text file with all session keys. 5) Slowly decrypt/decompress/process all files remotely using the session keys. 6) Destroy the session keys on the remote tmpfs by overwriting the memory pages. As you can see the procedure did not require any additional software on local/remote while the functions were still available with gpg and allows you to make sure, that you only decrypted exactly the number of session keys you expected from the remote side. It prevented misuse of you key for signing. With remote device compromised it did not protect against decrypting other data from that device (e.g. historic files already deleted and being reinjected by an attacker) or files from another device sharing the same public key for encryption. Later could be easily prevented by using a per-device encryption key. As the two remote attack scenarios were deemed very unlikely and low-impact, there is no protection in place. @PGP-RFC-Devs: Could it be a nice feature for future of PGP (if cryptographically unproblematic) to have some kind of manipulation proof "tag" in the encrypted session-key packet, that can be set, e.g. via --tag-encrypted-data "mytag-$(echo "some-salt $(hostname -f)" | sha256)" to identify encrypted data source and avoid decrypting injected session key packets. Using a signing key per source seems to be impractical here too as it would also require to transfer the whole file beforehand for signature verification. hd _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
