Hi, On 28/05/2020 06:20, halfdog wrote: > 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.
What about solving your entire use-case with an explicit two-step process: There's an encrypted, signed OpenPGP file with just a cryptographically secure random number. It is signed by a per-source signing key and encrypted to the secure machine. There's another file with symmetrically encrypted data using the tool of preference (could be GnuPG with --symmetric encryption) which actually contains the bulk of the data. The "passphrase" or encryption key is the cryptographically secure random number from the OpenPGP file. So every time you would now create a public-key encrypted file with the historic data, you explicitly generate a fresh "session key". You encrypt the data symmetrically with that key, and also public-key encrypt and sign that "session key". When you need to recover the historic data, the device sends only all the public-key encrypted "session keys" to the secure machine. That checks all these are signed by the device in the field, and if so, returns all "session keys". It's basically a duplication of the OpenPGP session key, and indeed, internally you are using a session key to encrypt a "session key". So it needs twice the randomness, which might be a problem on embedded systems. But it prevents needing packet surgery and inspection, instead just using default mechanisms. HTH, Peter. -- 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>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
