AW: Seperate Session Key and Encrypted Data
cloehle at linutronix.de
Fri Oct 2 10:10:16 CEST 2015
Thanks for your reply(and all the others of course).
Personally I'm going to use non-pgp AES probably, although I'm not quite
content with that. As I said, this seems like a feature that would make
sense, I might work on it myself if I find the time.
On 10/01/2015 07:29 PM, Daniel Kahn Gillmor wrote:
> On Thu 2015-10-01 07:52:51 -0700, Christian Loehle wrote:
>> That's what I would do if I had no other choice. The real downside is
>> that it doesn't follow a standard(like openpgp) and I will have to write
>> more code on the client side, compared to a standard openpgp solution.
>> It just seems like there is no reason why separating the session key and
>> the data wouldn't be supported, but I couldn't find anything about it.
> The OpenPGP standard leaves this sort of approach open. GnuPG
> facilitates some part of it, but not everything.
> First, take a look at --show-session-key and --override-session-key --
> this makes it possible to extract a session key from an existing PKESK
> or SKESK packet, and to use a known session key to decrypt a packet.
> You should be able to use the gpgsplit tool to take a stream of packets
> and split it into individual files. You can use /bin/cat to collect a
> set of individual files and reassemble them into an OpenPGP packet
> So the only functionality GnuPG is missing to assemble the workflow
> you're describing would be a new GnuPG command named something like
> --generate-pkesk-with-session-key. If that command was available, the
> full workflow described by the original poster would be something you
> could probably cobble together with a couple shell scripts.
> Note: this is *not* something i'd want people to do as part of the
> normal user interface of GnuPG. This is a feature that would be useful
> for GnuPG as an OpenPGP programming toolkit. The fact that GnuPG is
> widely used as both a user-facing tool and as a programming toolkit is
> one of the things that makes it less convenient for both use cases :(
More information about the Gnupg-users