unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Sebastian Spaeth <Sebastian@SSpaeth.de>
Cc: notmuch <notmuch@notmuchmail.org>
Subject: Re: PGP/MIME signature verification
Date: Wed, 22 Dec 2010 14:11:36 -0500	[thread overview]
Message-ID: <4D124D68.6060300@fifthhorseman.net> (raw)
In-Reply-To: <87mxnx3mb9.fsf@SSpaeth.de>

[-- Attachment #1: Type: text/plain, Size: 2986 bytes --]

On 12/22/2010 09:38 AM, Sebastian Spaeth wrote:
>>> "sigstatus": [{"status": "error","keyid": "ED34CEABE27BAABC", "errors":
>>> 2}]
>>> (perhaps due to me not having your key???)
>>
>> yup, that is why you get that error.
> 
> Is there a possibility to squeeze a nicer error message out of it? :-)

that's a good question -- i'm not sure libgmime gives us much else to
work with (it is itself calling out to gpg, which in turn might not give
*it* much to work with), but i'll see if there's anything we can do
about that.

One potential concern with this kind of reporting is that (due to the
dirty details of the OpenPGP data signature format), differentiating
"you don't have this key in your keyring" from "you have this key, but
the signature is bad" is not fully possible.

For those who want the details:

 0) an OpenPGP signature contains the signature data itself, plus an
indicator of what key made the signature (the "issuer"):

  https://tools.ietf.org/html/rfc4880#section-5.2.3.5

 1) The indicator is the lower 64-bits of the OpenPGP fingerprint of the
signing key.

 2) OpenPGP fingerprints themselves are SHA-1 sums of (some fiddly
concatenation of) the creation time of the key and the public key
material itself:

  https://tools.ietf.org/html/rfc4880#section-12.2

However, the 64 bits of the key ID (while longer than the 32-bit pattern
commonly expressed like "0xDEADBEEF") isn't really a big-enough search
space to resist collision attacks by moderately-well-resourced adversaries.

That is, it's currently possible to have a computer farm powerful enough
to crank through the search space to create a valid OpenPGP key with any
chosen 64-bit key ID.

So if Alice has her legitimate key with key ID 0x0000DECAFBAD0000, and
Eve has a big computer, Eve can create a new OpenPGP key with the same
Key ID.  If Eve convinces Bob to load her own key into his keyring, then
what happens when Bob receives a signed message from Alice?

Bob's verifier will look at the message, see that it's signed by a key
with key ID 0x0000DECAFBAD0000, and then check the signature against his
copy of Eve's key.  But the signature doesn't verfiy!  This is actually
because Bob doesn't have Alice's key, of course, but his client has no
way of knowing that -- it just sees that it has a matching key that
doesn't verify.

So an attacker can convert a "you don't have this key" to a "you have
this key but the signature doesn't validate" without even tampering with
the message in transit (of course, an attacker who can tamper with the
message in transit can *also* make a signature fail to validate, just by
flipping a bit or two in either the message or the signature).

(note: don't despair!  the full 160-bit OpenPGP fingerprint space is not
currently under threat; only the 64-bit "key ID" has the above problem,
given our current understanding of cryptanalysis and the power of our
computing hardware).

	--dkg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

  reply	other threads:[~2010-12-22 19:11 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-27 19:35 PGP/MIME signature verification Daniel Kahn Gillmor
2010-11-27 21:24 ` Jameson Rollins
2010-12-13 22:02 ` David Bremner
2010-12-13 22:11   ` Daniel Kahn Gillmor
2010-12-13 22:10 ` David Bremner
2010-12-13 22:14   ` Daniel Kahn Gillmor
2010-12-20 18:22 ` Jameson Rollins
2010-12-21  9:51   ` Sebastian Spaeth
2010-12-21 15:36     ` Daniel Kahn Gillmor
2010-12-22 14:38       ` Sebastian Spaeth
2010-12-22 19:11         ` Daniel Kahn Gillmor [this message]
2011-01-27  1:13   ` Jameson Rollins
2011-02-03  1:18     ` new "crypto" branch providing full PGP/MIME support Jameson Rollins
2011-02-03 16:25       ` micah anderson
2011-02-03 19:52         ` Daniel Kahn Gillmor
2011-02-03 20:34           ` Jameson Rollins
2011-02-03 21:03             ` always encrypting messages to self [was: Re: new "crypto" branch providing full PGP/MIME support] Daniel Kahn Gillmor
2011-02-04 13:04               ` Sebastian Spaeth
2011-02-04 17:30                 ` Jameson Rollins
2011-02-04 16:59           ` new "crypto" branch providing full PGP/MIME support micah anderson
2011-02-04 17:30             ` Daniel Kahn Gillmor
2011-02-03 17:48       ` Daniel Kahn Gillmor
2011-02-03 20:42       ` Darren McGuicken
2011-02-03 21:02         ` Jameson Rollins
2011-02-04 12:09           ` Darren McGuicken
2011-02-04 17:32             ` Jameson Rollins
2011-02-05 14:50               ` Darren McGuicken
2011-02-04 21:07           ` Jameson Rollins
2011-04-25 22:35             ` Jameson Graef Rollins
2011-02-04 12:24       ` David Bremner
2011-02-04 17:24         ` Jameson Rollins
2011-02-04 17:12       ` David Bremner
2011-02-04 18:10         ` Jameson Rollins
2011-02-27  0:45       ` [Review] " David Bremner
2011-02-27 10:41         ` Darren McGuicken
2011-02-28 13:24           ` Sebastian Spaeth
2011-02-28 13:52             ` Ross Glover
2011-02-28 18:25               ` Jameson Rollins
2011-02-28 18:59                 ` Daniel Kahn Gillmor
2011-02-28 19:56                   ` Jameson Rollins
2011-02-28 20:08                     ` Daniel Kahn Gillmor
2011-03-01  2:49                       ` Jameson Rollins
2011-03-01  3:16                         ` Rob Browning
2011-03-01  3:31                           ` Jameson Rollins
2011-03-05  8:26                             ` signed/encrypted tagging in crypto branch [was: Re: [Review] Re: new "crypto" branch providing full PGP/MIME support] Jameson Rollins
2011-03-06 19:15                               ` signed/encrypted tagging in crypto branch Jameson Rollins
2011-04-14  7:48                                 ` Florian Friesdorf
2011-04-16 15:27                                 ` Pieter Praet
2011-03-01 19:32             ` [Review] Re: new "crypto" branch providing full PGP/MIME support Simon Fondrie-Teitler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D124D68.6060300@fifthhorseman.net \
    --to=dkg@fifthhorseman.net \
    --cc=Sebastian@SSpaeth.de \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).