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

[Daniel Kahn Gillmor <dkg fifthhorseman net>]

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.

(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)

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?

> 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".

Any other suggestions?

    --dkg