From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/85070 Path: news.gmane.org!not-for-mail From: Jens Lechtenboerger Newsgroups: gmane.emacs.gnus.general Subject: Re: Default encryption for Message Date: Thu, 02 Oct 2014 18:51:26 +0200 Message-ID: <86wq8iife9.fsf@informationelle-selbstbestimmung-im-internet.de> References: <86wq8xffpv.fsf@informationelle-selbstbestimmung-im-internet.de> <864mvx5bw9.fsf@informationelle-selbstbestimmung-im-internet.de> <86y4t7vfkm.fsf@informationelle-selbstbestimmung-im-internet.de> <871tqw1tvq.fsf-ueno@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1412268762 26571 80.91.229.3 (2 Oct 2014 16:52:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Oct 2014 16:52:42 +0000 (UTC) Cc: ding@gnus.org To: Daiki Ueno Original-X-From: ding-owner+M33314@lists.math.uh.edu Thu Oct 02 18:52:34 2014 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XZjcH-0008Ej-DA for ding-account@gmane.org; Thu, 02 Oct 2014 18:52:34 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1XZjbV-0004eb-NN; Thu, 02 Oct 2014 11:51:45 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1XZjbT-0004eE-Bx for ding@lists.math.uh.edu; Thu, 02 Oct 2014 11:51:43 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1XZjbP-0007CD-JK for ding@lists.math.uh.edu; Thu, 02 Oct 2014 11:51:40 -0500 Original-Received: from mx1.mailbox.org ([80.241.60.212]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1XZjbM-0002qI-Ne for ding@gnus.org; Thu, 02 Oct 2014 18:51:36 +0200 Original-Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 2C137424F9; Thu, 2 Oct 2014 18:51:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Original-Received: from smtp1.mailbox.org ([80.241.60.240]) (using TLS with cipher AES256-GCM-SHA384) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTPS id AwvrAM8FEF6i; Thu, 2 Oct 2014 18:51:27 +0200 (CEST) OpenPGP: id=0xA142FD84; url=http://www.informationelle-selbstbestimmung-im-internet.de/A142FD84.asc Mail-Followup-To: Daiki Ueno , ding@gnus.org In-Reply-To: <871tqw1tvq.fsf-ueno@gnu.org> (Daiki Ueno's message of "Sun, 28 Sep 2014 09:16:57 +0900") User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3.94 (gnu/linux) X-Spam-Score: -2.9 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:85070 Archived-At: On 2014-09-28, Daiki Ueno wrote: > Jens Lechtenboerger writes: > > So, maybe improving the documentation of mml2015-encrypt-to-self would > be a good start? Yes, there is room for improvement ;) Maybe that variable should not be t or nil but instead a list of key IDs (empty by default). >> (1) Friend Bob wants to send a message to Alice and is supposed to >> choose the correct key B (but neither A nor C). >> >> (2) Alice wants to send an encrypted message to colleague Charlie, >> and she wants to make sure that the message is encrypted to her key >> A (but neither B nor C) in addition to Charlie=E2=80=99s key. >> >> For (1), my code sets mm-encrypt-option to 'guided to enforce a >> manual choice so that Bob learns about the existence of those three >> public keys in the first place. (Ted Zlatanov suggested to save >> that choice.) > > I don't think this is a good idea. I know some people ("security" fans) > like this kind of verbose behavior, but others don't even want to > remember key IDs and are prone to choose wrong keys. > > There are criticisms about a related topic: > http://www.superlectures.com/guadec2013/more-secure-with-less-security Thank you for the link. The idea of using intentions is a good one. I don=E2=80=99t see how to specify intentions without questions in this case, though. Maybe I just didn=E2=80=99t get the point of the video. Bob=E2=80=99s intention is simple: Encrypt a message to Alice. However, in the scenario outlined by you, Alice=E2=80=99s intention is much more complex: Have different parties use different keys in messages sent to her. How do those parties and their software learn about her intention? As you just pointed out, Bob quite likely does not know about key IDs. In contrast, his software does. I think of a question like this (to be answered by Bob): =E2=80=9CMultiple encryption keys for are available. Which one(s) would you like to use? (Type ?/a/c/m; ? for help.)=E2=80=9D ? displays explanation for the other keys: - a: Abort. I don=E2=80=99t know what that means, and I=E2=80=99ll ask the recipient offline. - c: Continue. I don=E2=80=99t know what that means. Use the default key and insert a question for the recipient. (This would insert a customizable text like the following into the message: =E2=80=9CP.S. My software told me that I could use several encryption keys, namely , but I don=E2=80=99t know how to choose. Please explain your intention.=E2=80= =9D) - m: Menu. Display a menu (see mm-encrypt-option 'guided), where Bob chooses. Once Bob has chosen, he is asked whether he=E2=80=99d like to choose anew for every message sent to Alice or to record this choice permanently. >> Besides, what is the intended meaning for signatures if >> mml2015-signers contains multiple keys? > > This is certainly for the case when one wants to sign a message with > multiple keys. My fault. I wasn=E2=80=99t aware of that idea. I don=E2=80=99t see why pe= ople would do this, but it works. Best wishes Jens