Re: [gmime-devel] [PATCH 6/6] Support extraction of session keys during decryption.

[Jeffrey Stedfast <fejj gnome org>]

On 12/2/2016 3:31 PM, Daniel Kahn Gillmor wrote:
> On Fri 2016-12-02 10:37:38 -0500, Jeffrey Stedfast wrote:
> > I just read the man page for gpg's --show-session-key and
> > --override-session-key.
> >
> > It looks like the gpg authors advise against using it unless you need to
> > (while providing what they feel is a valuable use-case).
> >
> > So I guess that answers my question.
> I think the way to think about this is that the session key is a bit of
> secret key material, capable on its own of decrypting the secret
> message.  If a user deletes the resultant cleartext MIME part but
> somehow fails to delete the DecryptResult, then someone who gets access
> to the DecryptResult can decrypt the ciphertext again.  That seems like
> "opt in" behavior to me.

Right.

> (and hm, actually, maybe that means we should be zeroing the RAM before
> releasing the stored session key; i can make that change if that sounds
> good to you)

Yes, please :)

> the other advantage for keeping this command is that it makes it clearer
> in the API which cryptocontexts are capable of this kind of operation.
> Would it be better to make this function part of the GMimeCryptoContext
> API instead of the GMimeGpgContext, though?

If the plan is to also add it to the S/MIME context, then yes.

> > However, I have another question which is: Do we want to have an API to
> > allow the use of a session-key when decrypting?
> yes, ultimately, we'll want something like that, but it's something
> that'd belong in a follow-on patch.  just extracting the session key
> data is the first step.
>
> What API would you prefer for a "try-this-session-key" approach?  I see
> two mechanisms:
>
> (a) give the session key to the context for any number of subsequent
>      decryptions until it is cleared or re-set:
>
>          g_mime_gpg_context_set_session_key_for_decryption()
>          g_mime_gpg_context_clear_session_key_for_decryption()
>
>      This is a bit awkward, though: what should happen if the wrong
>      session key is given; should it fall back to trying to use the
>      available public keys?  if so, then we'd need to do some fancy
>      footwork, because gpg simply fails to decrypt if you give it the
>      wrong session key.
>
>
> (b) have some variation on g_mime_multipart_encrypted_decrypt() or
>      g_mime_crypto_context_decrypt(), which has an additional parameter
>      of "session_key".

(b) makes the most sense.

Perhaps g_mime_crypto_context_decrypt_session?

I really wish C allowed method overloading :(

Jeff