Re: AW: Seperate Session Key and Encrypted Data

2015-10-03 Thread Werner Koch
On Sat, 3 Oct 2015 18:16, d...@fifthhorseman.net said: > Do you mean "more generalized" than generate-pkesk-with-session-key? Do > you have a spec for what you want this command to be? Can we open a - Add new PKESK packets to an encrypted message - Add new SKESK packets to an encrypted message

Re: AW: Seperate Session Key and Encrypted Data

2015-10-03 Thread Daniel Kahn Gillmor
On Fri 2015-10-02 04:10:16 -0400, Christian Loehle wrote: > 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. AES is a cipher for a single block. For files larger than the block size, you'll need t

Re: AW: Seperate Session Key and Encrypted Data

2015-10-03 Thread Daniel Kahn Gillmor
On Fri 2015-10-02 02:39:07 -0400, Werner Koch wrote: > On Thu, 1 Oct 2015 19:29, d...@fifthhorseman.net said: > >> 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 th

Re: AW: Seperate Session Key and Encrypted Data

2015-10-02 Thread Christian Loehle
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. -- Christian Loehle On 10/01/2015 07:29 PM, Da

Re: AW: Seperate Session Key and Encrypted Data

2015-10-02 Thread Werner Koch
On Thu, 1 Oct 2015 19:29, d...@fifthhorseman.net said: > 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 A more generalized version w

Re: AW: Seperate Session Key and Encrypted Data

2015-10-01 Thread Daniel Kahn Gillmor
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

Re: AW: Seperate Session Key and Encrypted Data

2015-10-01 Thread Christian Loehle
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 wo