PGP/MIME signature verification

[Daniel Kahn Gillmor]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101222/67d7c099/attachment.pgp>