[PATCH v4 0/7] emacs: Improve the cited message included in replies
[notmuch-archives.git] / 69 / 317da7aaf7f24dd4a2cb4dabb1987a21625e50
1 Return-Path: <nagydani@epointsystem.org>\r
2 X-Original-To: notmuch@notmuchmail.org\r
3 Delivered-To: notmuch@notmuchmail.org\r
4 Received: from localhost (localhost [127.0.0.1])\r
5         by olra.theworths.org (Postfix) with ESMTP id CAFC3431FB6\r
6         for <notmuch@notmuchmail.org>; Tue, 18 Jan 2011 02:01:08 -0800 (PST)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -0.7\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
13 Received: from olra.theworths.org ([127.0.0.1])\r
14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
15         with ESMTP id BuqwooiSfE1Z for <notmuch@notmuchmail.org>;\r
16         Tue, 18 Jan 2011 02:01:08 -0800 (PST)\r
17 Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com\r
18         [209.85.214.53])\r
19         by olra.theworths.org (Postfix) with ESMTP id C4FC7431FB5\r
20         for <notmuch@notmuchmail.org>; Tue, 18 Jan 2011 02:01:07 -0800 (PST)\r
21 Received: by bwg12 with SMTP id 12so3644117bwg.26\r
22         for <notmuch@notmuchmail.org>; Tue, 18 Jan 2011 02:01:04 -0800 (PST)\r
23 Received: by 10.204.45.150 with SMTP id e22mr3019021bkf.125.1295344864413;\r
24         Tue, 18 Jan 2011 02:01:04 -0800 (PST)\r
25 Received: from [192.168.55.151] ([213.163.35.18])\r
26         by mx.google.com with ESMTPS id b6sm2522506bkb.22.2011.01.18.02.01.02\r
27         (version=TLSv1/SSLv3 cipher=RC4-MD5);\r
28         Tue, 18 Jan 2011 02:01:03 -0800 (PST)\r
29 Message-ID: <4D3564E4.1010203@epointsystem.org>\r
30 Date: Tue, 18 Jan 2011 11:01:08 +0100\r
31 From: "Daniel A. Nagy" <nagydani@epointsystem.org>\r
32 Organization: ePoint Systems Ltd.\r
33 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;\r
34         rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7\r
35 MIME-Version: 1.0\r
36 To: IETF OpenPGP Working Group <ietf-openpgp@imc.org>\r
37 Subject: Re: including the entire fingerprint of the issuer in an OpenPGP\r
38         certification\r
39 References: <4D34F133.3000807@fifthhorseman.net>\r
40 In-Reply-To: <4D34F133.3000807@fifthhorseman.net>\r
41 X-Enigmail-Version: 1.1.2\r
42 Content-Type: multipart/signed; micalg=pgp-sha1;\r
43         protocol="application/pgp-signature";\r
44         boundary="------------enig29B4C3D13C4C40618B3DA1EA"\r
45 X-Mailman-Approved-At: Tue, 18 Jan 2011 12:27:11 -0800\r
46 Cc: notmuch <notmuch@notmuchmail.org>\r
47 X-BeenThere: notmuch@notmuchmail.org\r
48 X-Mailman-Version: 2.1.13\r
49 Precedence: list\r
50 List-Id: "Use and development of the notmuch mail system."\r
51         <notmuch.notmuchmail.org>\r
52 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
53         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
54 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
55 List-Post: <mailto:notmuch@notmuchmail.org>\r
56 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
57 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
58         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
59 X-List-Received-Date: Tue, 18 Jan 2011 10:01:09 -0000\r
60 \r
61 This is an OpenPGP/MIME signed message (RFC 2440 and 3156)\r
62 --------------enig29B4C3D13C4C40618B3DA1EA\r
63 Content-Type: text/plain; charset=UTF-8\r
64 Content-Transfer-Encoding: quoted-printable\r
65 \r
66 On 01/18/2011 02:47 AM, Daniel Kahn Gillmor wrote:\r
67 > i believe collisions of the low 64 bits of SHA1 are within reach today,=\r
68 \r
69 > i'd love to be corrected if this is not the case\r
70 \r
71 I'd suggest using the entire fingerprint as a reference and leaving the\r
72 creation date out of the fingerprint calculation for v5 for the\r
73 following reasons:\r
74 \r
75 Yes, generating two keys with identical long key ID's is feasible (and\r
76 not even particularly expensive on 64-bit machines with dozens of\r
77 gigabytes of RAM), but generating a new key with the same 64-bit key ID\r
78 as an existing key is on the very far end of the realm of feasibility.\r
79 Given the dubious gains from success, I would rule out this attack as\r
80 impractical.\r
81 \r
82 Another problem with fingerprints and key IDs is that they are generated\r
83 over the key and the creation date, meaning that the same key can have\r
84 different key ID's. Since the signature subpacket with the reference is\r
85 not part of the hashed data, one can change both the key ID and the\r
86 reference and keep the signature valid. Again, I don't know what the\r
87 practical value of such an attack might be, but just like in the first\r
88 case, it creates an odd situation potentially undermining the trust in\r
89 the security of the system. When arguing in front of a non-expert judge,\r
90 such quirks erode the claims of rock-solid evidence very badly.\r
91 \r
92 The key ID itself (especially the long one) is not a bad idea, however.\r
93 It is a nice compromise in the middle of Zooko's triangle (almost\r
94 memorable, almost globally unique and almost secure). In order to make\r
95 it more useful, I'd suggest using 20-digit decimal identifiers (like\r
96 credit card numbers) instead of 16-digit hexadecimal ones.\r
97 \r
98 Regards,\r
99 \r
100 --=20\r
101 Daniel\r
102 \r
103 \r
104 --------------enig29B4C3D13C4C40618B3DA1EA\r
105 Content-Type: application/pgp-signature; name="signature.asc"\r
106 Content-Description: OpenPGP digital signature\r
107 Content-Disposition: attachment; filename="signature.asc"\r
108 \r
109 -----BEGIN PGP SIGNATURE-----\r
110 Version: GnuPG v1.4.10 (GNU/Linux)\r
111 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\r
112 \r
113 iEYEARECAAYFAk01ZOgACgkQ28D1wCI06YWaKACffiStcNXJhiUxxNBCwpXK9Pg2\r
114 3LYAnjEnlPZ4Nxb6HrEFihVD72//UIWh\r
115 =7Gg2\r
116 -----END PGP SIGNATURE-----\r
117 \r
118 --------------enig29B4C3D13C4C40618B3DA1EA--\r