Adding support for fetching GPG key using WKD protocol
Wiktor Kwapisiewicz
wiktor at metacode.biz
Sat Jul 7 06:18:01 UTC 2018
Hi, Derek,
> Another way to look at this: Mutt likes to relegate tasks to an
> application which is designated for that task. In this case, gnupg
> (or whatever) is the application relegated to managing PGP keys. As
> such the user should configure THAT application, to the extent
> possible, to do what they want with keys, and Mutt should ignore the
> problem.
Yes, I like that approach. But consider that I can send encrypted
message with key retrieval from command line: (as WKD is enabled by
default since GnuPG 2.1 and kernel.org uses WKD):
echo "message" | gpg -ear torvalds at kernel.org | mail -s "Subject"
torvalds at kernel.org
But I cannot do so from Mutt (an e-mail client)! That's because Mutt
requires keyID... if it only passed the e-mail verbatim to gpg, gpg
would do what gpg does and retrieve the key.
> That's a big part of the danger here... You could retrieve a key that
> you think is for someone you know, when the request has actually been
> intercepted by, say, someone operating part of AT&T's backbone, and
> served a key of the attacker's making.*I* would not fall into such a
> trap, because I will not rely on the privacy of encryption to such a
> key until I have personally verified it, and it seems as though you
> would not fall into it either, based on at least web of trust... But
> I'm extremely confident that a percentage of users would be fooled by
> such an attack, and may in the process give away the keys to the
> store, so to speak.
WKD is done only through HTTPS, that eliminates a lot of attack vectors
and is more secure than just looking at matching keys on the keyservers.
> However the mere revelation of who is receiving my messages can be
> just as dangerous, depending on the type of correspondence I'm having.
> For example, if I were a political refugee trying to secure my safe
> passage to a different locale with a more friendly regieme, the
> unexpected automatic key retrieval, intercepted by the people I were
> running from, could be enough for them to find me and kill me. This
> is an extreme example, but this is one of the things which might
> genuinely justify the use of encryption.
Encryption can be used for variety of purposes. I'm thinking of stopping
passive surveillance, that is a fact, by having keys be easier and more
secure to discover.
Your hypothetical political refugee, if they wanted to be most secure,
would post --throw-keyids encrypted messages, without Version and
Comment headers [0] to alt.anonymous.messages through several remailers
and over Tor. They also would use stronger keys than 1024 DSA/RSA [1].
I guess this is not your usual mutt user?
WKD actually makes it easier to do the thing properly as it retrieves
the key only over secure HTTPS connection and only from one place.
Contrast this with keyservers that can be accessed using unencrypted
HTTP and everyone can add a key with any name and e-mail. (everyone can
also add any UID to *your* key [2], fake-revoke it, and they can also
render any key unusable [3]).
Kind regards,
Wiktor
[0]:
https://www.csoonline.com/article/2904395/microsoft-subnet/mistakes-that-betrayed-anonymity-of-former-dea-agent-and-silk-road-investigator.html
[1]: https://knowledge.digicert.com/generalinformation/INFO1684.html
[2]: https://bitbucket.org/skskeyserver/sks-keyserver/issues/41
[3]: https://bitbucket.org/skskeyserver/sks-keyserver/issues/60
--
https://metacode.biz/@wiktor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mutt.org/pipermail/mutt-dev/attachments/20180707/e6e69eb0/attachment-0001.asc>
More information about the Mutt-dev
mailing list