Hello all First, I agree with Neal in considering there is a privacy leak in using WKD (with no analysis/mitigations).
dkg has already provided an excelent explanation about this, and seems material directly usable into the Security Considerations section. As noted, the openpgpkey server sysadmin has direct access to the full email address being requested, not just because it would be trivial for them to undo the hashing for all the they have, but the local part is there ?l= query string (this was requested by protonmail in order to process the actual email). However, a network eavesdropper could as well obtain information about the keys being fetched. For a practical example, watch the (encrypted traffic) while you request the following keys: alice.miss...@wkdtest.pgp.16bits.net alice....@wkdtest.pgp.16bits.net alice....@wkdtest.pgp.16bits.net The TLS 1.2 *encrypted* reply by the server is 250, 1474, 554. >From a recipient privacy point of view, you would ideally be connecting to a server which has many users (a domain with a single-user would immediately betray the recipient) which have openpgp keys (in this sense, a public keyserver accessed via hkps are great), and also that their keys are somewhat similar (e.g. all RSA 2048), so that they are not distinguishable on the wire. In this context, there would be a possible attack by tricking the user into making their key recognizable. If the aforementioned regime wanted to detect people writing to dissenting-newsr...@popularmailprovider.com, but not to anyone else at @popularmailprovider.com (let's assume mail clients now automatically perform WKD, so requesting a key from popularmailprovider.com is not a signal by itself), they could send an agent to provide to the people of dissenting-newsr...@popularmailprovider.com their key with his signature (or signed by all his friends), so that it stands out when requested. Of course, it would have been preferable for them to sign up at popularmailprovider.com with an account name which collides with dissenting-newsroom so they end up in the same bucket, and so they would be able to add content there at will. But SHA-1 preimage resistance makes that infeasible. A WKD server operator could protect from this by padding the result with other keys so that the actual key size is concealed. In order to simplify this, I would recommend stating that WKD clients must ignore a trailing block of nuls (not part of a pgp packet, obviously) so that keys can easily be padded without calculating openpgp packets. You can test this by requesting alice.padd...@wkdtest.pgp.16bits.net (gnupg chokes on this, since it is expecting a valid packet) Note that doing this requires that the files are server with no compression, as otherwise padding with nuls wouldn't really be effective. Best regards PS: dkg email doesn't seem to have reached the list yet (only the one from Jan 15 appear in the archives), although later messages are already there. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
