From 6e02c242ae284cc6970fd153b3c308ba06d3afd2 Mon Sep 17 00:00:00 2001 From: Jameson Graef Rollins Date: Sun, 6 Apr 2014 12:09:32 +1700 Subject: [PATCH] Re: Feature suggestion. Indexing encrypted mail? --- 22/523690ad4ec80094aada4aea2874bdaf03c046 | 131 ++++++++++++++++++++++ 1 file changed, 131 insertions(+) create mode 100644 22/523690ad4ec80094aada4aea2874bdaf03c046 diff --git a/22/523690ad4ec80094aada4aea2874bdaf03c046 b/22/523690ad4ec80094aada4aea2874bdaf03c046 new file mode 100644 index 000000000..c5cccbe5a --- /dev/null +++ b/22/523690ad4ec80094aada4aea2874bdaf03c046 @@ -0,0 +1,131 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id F3F21431FB6 + for ; Sat, 5 Apr 2014 12:09:45 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -0.525 +X-Spam-Level: +X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_MED=-2.3, URIBL_BLACK=1.775] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id syYfQM4BJGfF for ; + Sat, 5 Apr 2014 12:09:39 -0700 (PDT) +Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu + [131.215.239.19]) + by olra.theworths.org (Postfix) with ESMTP id 62DC6431FAF + for ; Sat, 5 Apr 2014 12:09:39 -0700 (PDT) +Received: from fire-doxen.imss.caltech.edu (localhost [127.0.0.1]) + by fire-doxen-postvirus (Postfix) with ESMTP id B813532820C; + Sat, 5 Apr 2014 12:09:36 -0700 (PDT) +X-Spam-Scanned: at Caltech-IMSS on fire-doxen by amavisd-new +Received: from finestructure.net (cpe-107-185-189-81.socal.res.rr.com + [107.185.189.81]) (Authenticated sender: jrollins) + by fire-doxen-submit (Postfix) with ESMTP id 464F63280C3; + Sat, 5 Apr 2014 12:09:35 -0700 (PDT) +Received: by finestructure.net (Postfix, from userid 1000) + id C095260124; Sat, 5 Apr 2014 12:09:34 -0700 (PDT) +From: Jameson Graef Rollins +To: David Bremner , john.wyzer@gmx.de, + notmuch@notmuchmail.org +Subject: Re: Feature suggestion. Indexing encrypted mail? +In-Reply-To: <878urj1z3j.fsf@maritornes.cs.unb.ca> +References: <86k3b3ybo6.fsf@someserver.somewhere> + <878urj1z3j.fsf@maritornes.cs.unb.ca> +User-Agent: Notmuch/0.17+174~gaa1f476 (http://notmuchmail.org) Emacs/24.3.1 + (x86_64-pc-linux-gnu) +Date: Sat, 05 Apr 2014 12:09:32 -0700 +Message-ID: <87txa7pp8z.fsf@servo.finestructure.net> +MIME-Version: 1.0 +Content-Type: multipart/signed; boundary="=-=-="; + micalg=pgp-sha256; protocol="application/pgp-signature" +Cc: Daniel Kahn Gillmor +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Sat, 05 Apr 2014 19:09:46 -0000 + +--=-=-= +Content-Type: text/plain +Content-Transfer-Encoding: quoted-printable + +On Sat, Apr 05 2014, David Bremner wrote: +> john.wyzer@gmx.de writes: +> +>> Would it be possible to add the configurable option to also decrypt +>> encrypted messages on the fly while indexing to make them searchable, +>> too? +>> +>> That would be really great for people that consider gnupg mainly an +>> encryption for transport or have their complete hard drive encrypted... +> +> As far I understand an attacker could reconstruct the message from the +> index, so one question is whether the extra complexity in notmuch is +> worth the minimal extra security over decrypting on delivery and storing +> plaintext on the (presumably encrypted) disk. Of course decrypting on +> delivery may be inconvenient (or impossible). I have CCed the two people +> who have implemented most of the crypto related stuff in notmuch so they +> can comment. + +Indexing encrypted email is a bit of a foot-gun, since, as David +mentions, it is apparently possible to reconstruct encrypted messages +From=20the index. It therefore needs to be approached with care. + +I think decrypting on "delivery" (or mail fetch or whatever) sounds +difficult and unwieldy. In either event, it seems out of the scope of +notmuch. If a user figured out how to have that done, no changes to +notmuch would be needed afaict. +=20 +I don't think it would be difficult modify notmuch new to decrypt at +indexing time. Given that gnupg agent would be used for accessing the +users private key for decryption, the interface would be fairly +straightforward. + +A couple of decryption options could be added to notmuch new: + +* don't decrypt: don't attempt to decrypt and index any encrypted + message (default) + +* decrypt always: fail if any encrypted message could not be decrypted + +* decrypt opportunistically: attempt to decrypt, but continue indexing + if an encrypted message could not be decrypted + +If something like this is enabled, we should make sure we make the +dangers clear to the users. + +jamie. + +--=-=-= +Content-Type: application/pgp-signature + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1 + +iQIcBAEBCAAGBQJTQFTsAAoJEO00zqvie6q83QkQAJ17ZJ60k5CrPZotnd/hx5L/ +/Qe4ovlLCKECK+P10bK7YmlH350ujnX5YsgO00QEbvaS09nTDofRpvE9zZiWvlPr +MTdqnJ5p9iz6+LsELRerDEMMxEgLtUgSD/tNVCZWJJ5sUC3TwznJMCLLdkYmwRRe +EflzG0ASIb4ooL6oeyDcsbtir2A11232bPd+AL+WZFzfXXvBEBvbqGX8fwujZ6IY +95xd3bT9IpVgk8TbKdY5Smor6K5nZfmm5TM2/O8fjt4bwKUJAhj2OCkUbEgpw+RP +VeYV9+2B5iEAYQFKNEDdLr1vumln2p30WcnvJpEFwzE6nwtRzbW0VZ2BfJsl40qn +FpXYOyudOhh3cwDgXDcv1ubvILuys+nu5vWsx2xdn8Lg7EDYIsA33NHr1rH9Laj0 +kliU4ySLdwOrHUKvr63aVXMt+FwhfBWdR6CtQa+m5nZIR6tUC8MxyU4ROxtK37EA +7s15rIqce/dvyyskKv57a0V79bTARICPR8xERIwANcSlVv8LH9iAC1R23UoSaT8J +7XEKicuMcsQawkDcIJYEYu+FUOtfb8DqRrMZ5WaWYYu9FRuYEG5Uuq9otu49IIEG +ePkDUreFfEBs0Pu/1PU8r+sjmK41pcuHhd7SuqzrCzpwf9+v6q7kHMsZywhrRfbk +MtNEBcRJujCfQZ/QZIzv +=4Tws +-----END PGP SIGNATURE----- +--=-=-=-- -- 2.26.2