Re: [PATCH v2 04/21] crypto: use stashed session-key properties for decryption, if available

[David Bremner]

Daniel Kahn Gillmor  writes:

> On Thu 2017-11-30 03:59:29 -0500, Daniel Kahn Gillmor wrote:
>> +hexidecimal representation of the algorithm-specific key.  For
>
> ugh, this should be hexadecimal, not hexidecimal.
>
> This is fixed in my gitlab session-keys branch [0], but doesn't seem
> worth re-posting the entire series for. :)
>

I've amended it by hand, but for future reference the usual convention
is to post an amended patch as a reply, and to mark the original as
obsolete in nmbug

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v2 04/21] crypto: use stashed session-key properties for decryption, if available

[Daniel Kahn Gillmor]

On Thu 2017-11-30 03:59:29 -0500, Daniel Kahn Gillmor wrote:
> +hexidecimal representation of the algorithm-specific key.  For

ugh, this should be hexadecimal, not hexidecimal.

This is fixed in my gitlab session-keys branch [0], but doesn't seem
worth re-posting the entire series for. :)

  --dkg

[0] https://gitlab.com/dkg/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v2 04/21] crypto: use stashed session-key properties for decryption, if available

[Daniel Kahn Gillmor]

When doing any decryption, if the notmuch database knows of any
session keys associated with the message in question, try them before
defaulting to using default symmetric crypto.

This changeset does the primary work in _notmuch_crypto_decrypt, which
grows some new parameters to handle it.

The primary advantage this patch offers is a significant speedup when
rendering large encrypted threads ("notmuch show") if session keys
happen to be cached.

Additionally, it permits message composition without access to
asymmetric secret keys ("notmuch reply"); and it permits recovering a
cleartext index when reindexing after a "notmuch restore" for those
messages that already have a session key stored.

Note that we may try multiple decryptions here (e.g. if there are
multiple session keys in the database), but we will ignore and throw
away all the GMime errors except for those that come from last
decryption attempt.  Since we don't necessarily know at the time of
the decryption that this *is* the last decryption attempt, we'll ask
for the errors each time anyway.

This does nothing if no session keys are stashed in the database,
which is fine.  Actually stashing session keys in the database will
come as a subsequent patch.
---
 doc/man7/notmuch-properties.rst | 31 +++
 lib/index.cc|  2 +-
 mime-node.c | 13 ++---
 util/crypto.c   | 39 ++-
 util/crypto.h   |  3 ++-
 5 files changed, 82 insertions(+), 6 deletions(-)

diff --git a/doc/man7/notmuch-properties.rst b/doc/man7/notmuch-properties.rst
index 68121359..49602b73 100644
--- a/doc/man7/notmuch-properties.rst
+++ b/doc/man7/notmuch-properties.rst
@@ -74,6 +74,35 @@ of its normal activity.
 **notmuch-config(1)**), then this property will not be set on that
 message.
 
+**session-key**
+
+When **notmuch-show(1)** or **nomtuch-reply** encounters a message
+with an encrypted part and ``--decrypt`` is set, if notmuch finds a
+``session-key`` property associated with the message, it will try
+that stashed session key for decryption.
+
+Using a stashed session key with "notmuch show" will speed up
+rendering of long encrypted threads.  It also allows the user to
+destroy the secret part of any expired encryption-capable subkey
+while still being able to read any retained messages for which
+they have stashed the session key.  This enables truly deletable
+e-mail, since (once the session key and asymmetric subkey are both
+destroyed) there are no keys left that can be used to decrypt any
+copy of the original message previously stored by an adversary.
+
+However, access to the stashed session key for an encrypted message
+permits full byte-for-byte reconstruction of the cleartext
+message.  This includes attachments, cryptographic signatures, and
+other material that cannot be reconstructed from the index alone.
+
+The session key should be in the ASCII text form produced by
+GnuPG.  For OpenPGP, that consists of a decimal representation of
+the hash algorithm used (identified by number from RFC 4880,
+e.g. 9 means AES-256) followed by a colon, followed by a
+hexidecimal representation of the algorithm-specific key.  For
+example, an AES-128 key might be stashed in a notmuch property as:
+``session-key=7:14B16AF65536C28AF209828DFE34C9E0``.
+
 SEE ALSO
 
 
@@ -83,5 +112,7 @@ SEE ALSO
 **notmuch-insert(1)**,
 **notmuch-new(1)**,
 **notmuch-reindex(1)**,
+**notmuch-reply(1)**,
 **notmuch-restore(1)**,
+**notmuch-show(1)**,
 ***notmuch-search-terms(7)**
diff --git a/lib/index.cc b/lib/index.cc
index 19d03456..6eb60f30 100644
--- a/lib/index.cc
+++ b/lib/index.cc
@@ -548,7 +548,7 @@ _index_encrypted_mime_part (notmuch_message_t *message,
}
 }
 #endif
-clear = _notmuch_crypto_decrypt (crypto_ctx, encrypted_data, NULL, );
+clear = _notmuch_crypto_decrypt (message, crypto_ctx, encrypted_data, 
NULL, );
 if (err) {
_notmuch_database_log (notmuch, "Failed to decrypt during indexing. 
(%d:%d) [%s]\n",
   err->domain, err->code, err->message);
diff --git a/mime-node.c b/mime-node.c
index ae3ebef6..daaae9f8 100644
--- a/mime-node.c
+++ b/mime-node.c
@@ -198,9 +198,16 @@ node_decrypt_and_verify (mime_node_t *node, GMimeObject 
*part,
 GMimeDecryptResult *decrypt_result = NULL;
 GMimeMultipartEncrypted *encrypteddata = GMIME_MULTIPART_ENCRYPTED (part);
 
-node->decrypt_attempted = true;
-if (! node->decrypted_child)
-   node->decrypted_child = _notmuch_crypto_decrypt (cryptoctx, 
encrypteddata, _result, );
+if (! node->decrypted_child) {
+   mime_node_t *parent;
+   for (parent = node; parent; parent = parent->parent)
+   if (parent->envelope_file)
+   break;
+
+   node->decrypt_attempted = true;
+