From cad1210fb8a7402cb29e607f8f9680005314120d Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Fri, 11 Nov 2016 16:49:28 +0900
Subject: core: Enable extraction of session keys.

* src/gpgme.c (gpgme_set_export_session_keys): New function.
(gpgme_get_export_session_keys): New function.
* src/gpgme.h.in (struct _gpgme_op_decrypt_result): Add session_key
member.
(gpgme_{set,get}_export_session_keys): Declare new functions.
* src/libgpgme.vers, src/gpgme.def: Export new functions in shared
object.
* src/engine.h: (_gpgme_engine_op_decrypt) Add export_session_key
parameter.
(_gpgme_engine_op_decrypt_verify): Add export_session_key parameter.
* src/engine-backend.h: (struct engine_ops): Change function
pointer declarations to match.
* src/context.h (struct gpgme_context): Add export_session_keys member.
* src/decrypt.c (release_op_data): Free result.session_key.
(_gpgme_decrypt_status_handler): Store a copy of the exported session
key.
(decrypt_start): Pass export_session_keys from the context.
* src/decrypt-verify.c (decrypt_verify_start): Pass
export_session_keys from context.
* src/engine.c (_gpgme_engine_op_decrypt): Pass through
export_session_key flag.
(_gpgme_engine_op_decrypt_verify): Pass through export_session_key
flag.
* src/engine-gpg.c (gpg_decrypt): If export_session_key is set, add
--export-session-key to argument list.
* src/engine-gpgsm.c (gpgsm_decrypt): Ignore export_session_key for
now, since gpgsm offers no such mechanism.
* src/engine-uiserver.c (_uiserver_decrypt): If export_session_key is
set, add --export-session-key flag to cmd.
* doc/gpgme.texi: Document new functions and session_key member of
decrypt_result_t.
* doc/uiserver.texi: Add --export-session-key flag to DECRYPT command.

--

gpg(1) documents session key export as useful for key escrow, and is
rightly dubious of that use case.  However, session key export is also
useful in other use cases.  Two examples from MUA development (where
this functionality would be specifically useful to me right now):

 * If the MUA stores a local copy of the session key upon decrypting
   the message, it can re-decrypt the message without expensive
   asymmetric operations.  When rendering a thread with dozens of
   encrypted messages, this can represent a significant speedup.

 * A user may have expired encryption-capable secret key material,
   along with many messages encrypted to that material.  If she stores
   the session keys for those messages she wants to keep, she can
   destroy her secret key material and make any messages she has
   deleted completely unrecoverable, even to an attacker who gets her
   remaining secret keys in the future.

This patchset makes a two specific implementation decisions that could
have gone in different ways.  I welcome feedback on preferred outcomes.

 0) session key representation: we currently represent the session key
    as an opaque textual string, rather than trying to provide any
    sort of in-memory structure.  While it wouldn't be hard to parse
    the data produced by gpg's --export-session-key, I chose to use
    the opaque string rather than lock in a particular data format.

 1) API/ABI: i've added a member to gpgme_op_decrypt_result_t.  This
    has the potential to cause an out-of-bound memory access if
    someone uses code compiled against the newer verision, but linked
    at runtime against an older version.  I've attempted to limit that
    risk by documenting that users must verify
    gpgme_get_export_session_keys() before accessing this new struct
    member -- this means that code expecting this capability will
    require the symbol at link-time, and will refuse to link against
    older versions.

    Another approach to solving this problem would be to avoid
    modifying gpgme_op_decrypt_result_t, and to introduce instead a
    new function gpgme_op_session_key(), which could be called in the
    same places as gpgme_op_decrypt_result().  Depending on the
    representation of the session key, this might introduce new
    memory-management burdens on the user of the library, and the
    session key is certainly part of a decryption result, so it seemed
    simpler to go with what i have here.

If anyone has strong preferences that these choices should be solved
in a different way, i'm happy to hear them.

Additionally, I note that i'm also still pretty unclear about how the
"UI Server" fits into this whole ecosystem. In particular, I don't
know whether it's kosher to just add an --export-session-key flag to
the DECRYPT operation without actually having implemented it anywhere,
but i don't see where i would actually implement it either :/

If this patch (or some variant) is adopted, i will supply another
patch that permits offering a session key during decryption (e.g. "gpg
--override-session-key"), but I wanted to get these implementation
choices ironed out first.

Gnupg-Bug-Id: 2754
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

On the concern of adding a new field to a structure: It may not be
clearly documented but we don't expect that a user ever allocates such
a structure - those result structure may only be created bu gpgme and
are read-only for the user.  Adding a new member constitutes a
compatible ABI change and thus an older SO may not be used by code
compiled with a header for the newer API.  Unless someone tinkers with
the build system, this should never happen.  We have added new fields
to result structure may times and I can't remember any problems.

 - wk
---
 src/gpgme.def | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'src/gpgme.def')

diff --git a/src/gpgme.def b/src/gpgme.def
index 2f6837da..35f43411 100644
--- a/src/gpgme.def
+++ b/src/gpgme.def
@@ -252,5 +252,7 @@ EXPORTS
     gpgme_op_query_swdb                   @189
     gpgme_op_query_swdb_result            @190
 
+    gpgme_set_export_session_keys         @191
+    gpgme_get_export_session_keys         @192
 ; END
 
-- 
cgit v1.2.3

