Re: WKD proper behavior on fetch error
On Wed, Jan 20, 2021 at 12:41 AM Ángel wrote: > A list of all (well, most) openpgpkey subdomains can be easily created. Yes and I believe that what Neal and you (in your new posting) have explained makes it only worthwhile for Mallory to start his work, because he has such an openpgpkey list created. Anyways, even if creating and maintaining a list also for all domains (direct-method) why give him this opportunity, if it is so easy to do so for openpgpkey subdomains? There is a demand for openpgpkey, so it seems, which I have accepted, but you know my points (which I have outlined) in the whole thread that we should be allowed to have direct-method usage too, with GnuPG and gpg4win, without having cert errors in GnuPG and gpg4win's WKD implementation. Whatever the outcome of this thread will be, as long as other OpenPGP apps work and will hopefully not change, so that this no longer works, people know now what they can do/use. Best regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
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
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On 2021-01-19 at 17:24 +0100, Erich Eckner via Gnupg-users wrote: > What can cause a "Connection closed in DNS" error? (Maybe the error > message can be improved: Doesn't dns use udp by default, which is > connectionless?) I think it means dns.c returned DNS_ECONNFIN [1], which gets converted to GPG_ERR_DNS_CLOSED in dns-stuff.c and is then libgpg-error describes as "Connection closed in DNS" I'm not sure if this error can happen when using UDP, but do note that you can also (and in some cases must) perform DNS queries using tcp. Best regards 1- https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=dirmngr/dns.c;h=3ac6a2d021288bf4124745b6e9567e665e09fe49;hb=93d5d7ea2a8b110b3ad88be25f2f67d706361e44#l360 2- https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=dirmngr/dns-stuff.c;h=cdda86d63086184bf09e8dce7d946989a61d14d0;hb=93d5d7ea2a8b110b3ad88be25f2f67d706361e44#l394 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
On 2021-01-19 at 19:29 +0100, Stefan Claas wrote: > Example: Mallory sitting in the United States likes to prepare > a list (without my consent) and published on a U.S. site, > so that like SKS key server dumps the whole world can > obtain a list of all openpgpkey subdomains. So far so good. > > Mr 'edge case' Stefan knows this and counterstrikes with > his domain radio-eriwan.su (which I own) and set's up for > Mr Mallory a WKD direct-method dir with n dummy keys. > > Good luck Mr Mallory figuring out which domains have real > OpenPGP users keys hosted and which not. > > Best regards > Stefan A list of all (well, most) openpgpkey subdomains can be easily created. However, there is no need for or dummy keys. Mallory sees that radio-eriwan.su supports WKD (this is immediate, it doesn't matter if it uses the advanced or direct method). However, it can't ask for all keys it stores. Mallory will need to ask for every possible key: Do you have an OpenPGP key for a...@radio-eriwan.su ? Do you have an OpenPGP key for b...@radio-eriwan.su ? Do you have an OpenPGP key for c...@radio-eriwan.su ? … Do you have an OpenPGP key for z...@radio-eriwan.su ? Do you have an OpenPGP key for a...@radio-eriwan.su ? Do you have an OpenPGP key for a...@radio-eriwan.su ? and so on until zzz zzz zzz zz...@radio-eriwan.su even if Mallory only checks email addresses with lowercase letters (although they are not the only allowed characters in an email address), he would need to ask for 5.8×10³³⁶ email addresses. Just for radio-eriwan.su This can be optimized by checking instead the full space of sha-1 hashes, to "only" perform 1.46×10⁴⁸ requests (assuming the server doesn't validate the local part on WKD requests). Anyway, such attack is completely unrealistic. In order to get all keys Mallory would either need access to the server files (e.g. it compromised the server, or the contents are published in github), or the web server to have been (mis?)configured with Directory Listings. Best regards ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On Tue, Jan 19, 2021 at 11:01 PM Erich Eckner via Gnupg-users wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > I checked the manual, and there is even a non-permanent solution: > > - --export-filter keep-uid="mbox = ..." > > lets you filter the exported uids :-) Cool :-) , I did not know this. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 19 Jan 2021, Stefan Claas wrote: On Tue, Jan 19, 2021 at 6:28 PM Stefan Claas wrote: On Tue, Jan 19, 2021 at 6:26 PM Erich Eckner via Gnupg-users wrote: Advanced method is set up, direct method is not. The key has multiple UIDs (one for each of my email addresses). Or did I do something wrong when exporting the key to the WKD? Should I have removed the other UIDs there? (how?) Hi Erich, No, not wrong, but then WKD users would know your other email addresses as well, I would say. In case you like to avoid that I would check GnuPG for editing the key, e.g. removing the unwanted UIDs and then save and then export for WKD. gpg [Optionen] --edit-key user-id [commands] I checked the manual, and there is even a non-permanent solution: - --export-filter keep-uid="mbox = ..." lets you filter the exported uids :-) Regards Stefan regards, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAHLfEACgkQCu7JB1Xa e1rmjBAAvqUdx+hoqtg3lDWPUqQE69QtmmUgnxBSXPo4VJbFLQKccsog270mzJXh ccGbqYLHHpj5X0BfFWcIn/7UII7QRfscp8/lvt+IM7I5pHvGpGky21jrMgVhm6h7 VrnioKV97MgHZcFG1ihCOLI5txVL81efSulaS9akUkhB096nJy6j8G05L1ZUlLkJ q/ZwXaqdBH2aG9moHh0zCC0a7081FfwmBf120c9ZH9MmBHM47TPqDauI2/ECgi52 wB7LzaGPyvbQngGrxsD3aUTftOE+dq7XChp4kuiuIA4o5+rmJ/0umwdm8IBr324R mW9Cs/iSJcVA/XXuAIWSe5uFLgg2ZrqdeMA2HHQF90ElxnRsCeKYs9Bq3HIBqqEn zJ3DR5J87uUgsgLxEZfStCSVMz0nC5jpcP2Ycyv0qKpZ8zu15wBYl0GuUZ7SLQS8 Db21TerHsDr2RFvLj3K/YfVIIRxFJD7hZtP3hGW0+cuqQcyAGtbHbJm9Id5h0G2f 5EvpJGn4d6b6w2nsGGP5hQOQ99WYTnJGpjiUvQvOd+f06IQ76BgIZdMIlwENFlSt nY6du0KZKMHhiUOp5+nBFRIzqWpoI4NGvZAnHR16ClJVKNymIdMm6R/SsYlM5XHt rv6LtEotIF4b72pMhwAgckEOcAl2NM4UTLIOeWa5ZME03oKMypc= =g12g -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
On Tue, Jan 19, 2021 at 7:06 PM Stefan Claas wrote: > > On Tue, Jan 19, 2021 at 1:14 PM Werner Koch via Gnupg-users > wrote: > > > > On Tue, 19 Jan 2021 09:28, Neal H. Walfield said: > > > > > When you look up the openpgpkey.example.org domain, you are revealing > > > to anyone snooping DNS traffic that you are using OpenPGP and are > > > looking for a key related to example.org. That's a privacy issue. > > > > No, it isn't. The next thing you do is to send the mail and get a > > reply. Get real. > > I share the same sentiments as Neal, why? > > I am aware that the whole WWW can be scraped or searched in about > a couple of minutes and let's say in my GitHub case I could imagine > that for an explicit openpgpkey subdomain it could be possible to > get all WKD directories, with an openpgpkey subdomain part, in > case GitHub would do this (which they will hopefully not do.) > > And at least we have the direct-method for usage without an > openpgpkey sub or sub-sub domain part. So why give WKD > enthusiast not this option and out of curiousity please try to > explain to us why the current draft say MUST and not MAY > or SHOULD? I like to learn, because WKD is freaking cool > with OpenPGP apps, like sequoia-pgp or Mailvelope etc. Example: Mallory sitting in the United States likes to prepare a list (without my consent) and published on a U.S. site, so that like SKS key server dumps the whole world can obtain a list of all openpgpkey subdomains. So far so good. Mr 'edge case' Stefan knows this and counterstrikes with his domain radio-eriwan.su (which I own) and set's up for Mr Mallory a WKD direct-method dir with n dummy keys. Good luck Mr Mallory figuring out which domains have real OpenPGP users keys hosted and which not. Best regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
On Tue, Jan 19, 2021 at 1:14 PM Werner Koch via Gnupg-users wrote: > > On Tue, 19 Jan 2021 09:28, Neal H. Walfield said: > > > When you look up the openpgpkey.example.org domain, you are revealing > > to anyone snooping DNS traffic that you are using OpenPGP and are > > looking for a key related to example.org. That's a privacy issue. > > No, it isn't. The next thing you do is to send the mail and get a > reply. Get real. I share the same sentiments as Neal, why? I am aware that the whole WWW can be scraped or searched in about a couple of minutes and let's say in my GitHub case I could imagine that for an explicit openpgpkey subdomain it could be possible to get all WKD directories, with an openpgpkey subdomain part, in case GitHub would do this (which they will hopefully not do.) And at least we have the direct-method for usage without an openpgpkey sub or sub-sub domain part. So why give WKD enthusiast not this option and out of curiousity please try to explain to us why the current draft say MUST and not MAY or SHOULD? I like to learn, because WKD is freaking cool with OpenPGP apps, like sequoia-pgp or Mailvelope etc. Best regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Re: WKD proper behavior on fetch error
On Tue, Jan 19, 2021 at 5:16 PM Stefan Claas wrote: > > On Tue, Jan 19, 2021 at 5:05 PM Stefan Claas > wrote: > > > A policy file could look like this, with remark lines at the > > beginning: > > > > # WKD policy for sac001.github.io (WRONG) > # WKD policy file for https://sac001.github.io > > # Maintainer: Stefan Claas, ste...@sac001.github.io > > # Updated: current date of last update. > > fingerprint #1 > > fingerprint #2 > > etc. And I guess Alice or Bob would be quite happy that this looks GDPR compatible, e.g. only putting the fingerprints in the policy file ... :-) Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On Tue, Jan 19, 2021 at 6:28 PM Stefan Claas wrote: > > On Tue, Jan 19, 2021 at 6:26 PM Erich Eckner via Gnupg-users > wrote: > > > Advanced method is set up, direct method is not. The key has multiple UIDs > > (one for each of my email addresses). Or did I do something wrong when > > exporting the key to the WKD? Should I have removed the other UIDs there? > > (how?) > > Hi Erich, > > No, not wrong, but then WKD users would know your other email addresses > as well, I would say. In case you like to avoid that I would check GnuPG for > editing the key, e.g. removing the unwanted UIDs and then save and then > export for WKD. gpg [Optionen] --edit-key user-id [commands] Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On Tue, Jan 19, 2021 at 6:26 PM Erich Eckner via Gnupg-users wrote: > Advanced method is set up, direct method is not. The key has multiple UIDs > (one for each of my email addresses). Or did I do something wrong when > exporting the key to the WKD? Should I have removed the other UIDs there? > (how?) Hi Erich, No, not wrong, but then WKD users would know your other email addresses as well, I would say. In case you like to avoid that I would check GnuPG for editing the key, e.g. removing the unwanted UIDs and then save and then export for WKD. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Stefan, thanks for your answer. On Tue, 19 Jan 2021, Stefan Claas wrote: On Tue, Jan 19, 2021 at 5:24 PM Erich Eckner via Gnupg-users wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I'm playing around with my WKD setup (guess, why) and encountered the error in the subject when doing `gpg - --locate-external-keys er...@eckner.net`. Retrieving via curl and the manually-constructed url works fine, also I cannot find any problems in dns on that box. A second box shows the same behaviour, but on a third machine, it works. All three run the latest arch linux :-/ What can cause a "Connection closed in DNS" error? (Maybe the error message can be improved: Doesn't dns use udp by default, which is connectionless?) I did a quick check and according to Wiktor's WKD checker the direct-method says that key is missing and the advanced method seems to be ok. sq.exe can fetch your key and when I do a gpg --locate-keys er...@eckner.net it fetches also a couple of others from you (with differrent email addresses , which I must admit I do not understand why and would probably not need when communicating with you. Yes, this is the proper behaviour (which I also see on one machine of the three mentioned machines): Advanced method is set up, direct method is not. The key has multiple UIDs (one for each of my email addresses). Or did I do something wrong when exporting the key to the WKD? Should I have removed the other UIDs there? (how?) However, on two machines, I only get this strange "Connection closed in DNS" error. Ah, wait, I checked again, and one box says: "gpg: error retrieving 'er...@eckner.net' via WKD: Permission denied" Something is oddly wrong :-/ Regards Stefan regards, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAHFXgACgkQCu7JB1Xa e1rSvBAAttQc553QJAWAsjmSMEDAYp21pOiRLGcPEGInkhcF2DvQaLpW2Y4WQZR+ Xj+m8hOf3IbYPHs7k07Xqu35oD0KrXh//lPkZ0kben/EkY2TMzMjuwvZhW9KN9do QMiZJ8DfEiD2E88EliwqTDZoLsjpjtZLEfMjd0Cp/nk2r1LqPmLzYCDvjh2kxhyt 1W16B/xsnB9ITsb3odDcuGxRA4dPuWwuX9z1qIiInXqBFP39P4W/6Fi3aKPm1aOq Dir0uygAWDKytV7XNZlFsKqGc4ndOmj398LWHS0dSIg/EYOOS4O8ja/SGiacNKu+ l26DkWiECZk7FQDvKZuzCZbxbdSIej8fPa1m4adTCB0nR9XZCimg0EZHKlzfK/7A 88IPNq1UuMsTDimimROh0wR8ZZFRLFkEdMf/IB5pGE9nfOFhOc0sXIsmnO60ZoJa pmstR0mjuicDd0bsPHl3QDx9zTjqz5448MOCGfelBgfbxWVB4TmSKQxLqoqTmVyB 1z+fuDq+IjUzHt3RyjwebMOMZlwRuZjEvdwOFwz/+NdjqEHpX6z4sWpRlrZmyq7w vIL4lrdBUuOqCxZmkIbMZMVQOu+ZMoRzA44cvMZAIMhYoTvmL5NjzL6LWlMv0jRo pSk+QMFMnxoVFr/8ntlJN+vSjVuTHVgSUXrb1YltsWLfR2Uy4wg= =YNH1 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On Tue, Jan 19, 2021 at 5:24 PM Erich Eckner via Gnupg-users wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, > > I'm playing around with my WKD setup (guess, why) and encountered the > error in the subject when doing `gpg - --locate-external-keys > er...@eckner.net`. Retrieving via curl and the manually-constructed url > works fine, also I cannot find any problems in dns on that box. A second > box shows the same behaviour, but on a third machine, it works. All three > run the latest arch linux :-/ > > What can cause a "Connection closed in DNS" error? (Maybe the error > message can be improved: Doesn't dns use udp by default, which is > connectionless?) I did a quick check and according to Wiktor's WKD checker the direct-method says that key is missing and the advanced method seems to be ok. sq.exe can fetch your key and when I do a gpg --locate-keys er...@eckner.net it fetches also a couple of others from you (with differrent email addresses , which I must admit I do not understand why and would probably not need when communicating with you. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD Checker
On Tue, Jan 19, 2021 at 9:51 AM Neal H. Walfield wrote: > > On Mon, 18 Jan 2021 17:12:56 +0100, > Stefan Claas wrote: > > I repeat here once again GitHub has a *valid* SSL cert. > > You're right. github has a valid TLS certificate. But that valid TLS > certificate is not valid for openpgpkey.sac001.github.io. That's just > the way it is, sorry. Hi Neal, you don't have to say sorry ... because it is the way GnuPG and gpg4win handles this required openpgpkey subdomain part in their WKD advanced-method implementation, while I personally like the direct-method to use only, which according to Wiktor's WKD checker is properly set-up for my github.io page and most important it is working with sequoia-pgp and Mailvelope etc. :-) Best regards Stefan Best regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I'm playing around with my WKD setup (guess, why) and encountered the error in the subject when doing `gpg - --locate-external-keys er...@eckner.net`. Retrieving via curl and the manually-constructed url works fine, also I cannot find any problems in dns on that box. A second box shows the same behaviour, but on a third machine, it works. All three run the latest arch linux :-/ What can cause a "Connection closed in DNS" error? (Maybe the error message can be improved: Doesn't dns use udp by default, which is connectionless?) Cheers, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAHB6QACgkQCu7JB1Xa e1o5EBAAlwWivpw2CYX+FgWfFOqCVEy26uHpX6vbcUjG5F5hM54pxs7OUw+iFvOr i9lAWpIaFFpE9zE98U02caycNmrV6JvazrXb/NvmIxiAwVTbXGjoJxWF1+GzMow5 xhaUeeac+TzYDEC+4XdB1crWmWbe1EHbXuWzq6UGjCisaTKEqRk7Wtvj+XeeVbrH hjEHLySG53s5BmC8WlAzM7h+AeY6q6asmnMDPxtYSUAvErDsjtT/9X+UsVHp+Qrg JSfrLriVHEmTmJBpCsil/B7PIaOV4BhBy4+1qCWrytE/DZav+nz97TI+z6ZP40LC RCxEK1SHbSGNDrOoIzv8WddMRM3wpjlU1lDPlecgykKCWsu0X/Js64mpq1Ext6RV vEF94I399odyb2qJOv1icg8l7770BJyjqvgcIBV3QBPEKkSVpHCN3Pi8m2rO1Ahc hTHsBAeyDM4uqWHjfK+8UWxXe1464u6vyQ3SseWDqdFPVHXS4IkmUfEV9MUpAr0y UOfPEWID4Awmp/ZMs2pad4GSYhhY/Mqzy1WN3DAHs3O5WtZ9gTwHYnJOT8e3DE/V i3gRUmUBjCNIByq2cCTc764TK7B6q+J1No5euLy4QYqH/ZeHTqBEm35wqdae6SQs VorbRIhlXTHpMvR8vvr1xG2gnV2uA4s/3lOsaxv/5HLOFWpIyMY= =6cGU -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Re: WKD proper behavior on fetch error
On Tue, Jan 19, 2021 at 5:05 PM Stefan Claas wrote: > A policy file could look like this, with remark lines at the > beginning: > > # WKD policy for sac001.github.io (WRONG) # WKD policy file for https://sac001.github.io > # Maintainer: Stefan Claas, ste...@sac001.github.io > # Updated: current date of last update. > fingerprint #1 > fingerprint #2 > etc. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
[Announce] Libgcrypt 1.9.0 relased
Hello! We are pleased to announce the availability of Libgcrypt version 1.9.0. This release starts a new stable branch of Libgcrypt with full API and ABI compatibility to the 1.8 series. Over the last 3 or 4 years Jussi Kivilinna put a lot of work into speeding up the algorithms for the most commonly used CPUs. See below for a list of improvements and new features in 1.9. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in Libgcrypt 1.9.0 - * New and extended interfaces: - New curves Ed448, X448, and SM2. - New cipher mode EAX. - New cipher algo SM4. - New hash algo SM3. - New hash algo variants SHA512/224 and SHA512/256. - New MAC algos for Blake-2 algorithms, the new SHA512 variants, SM3, SM4 and for a GOST variant. - New convenience function gcry_mpi_get_ui. - gcry_sexp_extract_param understands new format specifiers to directly store to integers and strings. - New function gcry_ecc_mul_point and curve constants for Curve448 and Curve25519. [#4293] - New function gcry_ecc_get_algo_keylen. - New control code GCRYCTL_AUTO_EXPAND_SECMEM to allow growing the secure memory area. Also in 1.8.2 as an undocumented feature. * Performance: - Optimized implementations for Aarch64. - Faster implementations for Poly1305 and ChaCha. Also for PowerPC. [b9a471ccf5,172ad09cbe,#4460] - Optimized implementations of AES and SHA-256 on PowerPC. [#4529,#4530] - Improved use of AES-NI to speed up AES-XTS (6 times faster). [a00c5b2988] - Improved use of AES-NI for OCB. [eacbd59b13,e924ce456d] - Speedup AES-XTS on ARMv8/CE (2.5 times faster). [93503c127a] - New AVX and AVX2 implementations for Blake-2 (1.3/1.4 times faster). [af7fc732f9, da58a62ac1] - Use Intel SHA extension for SHA-1 and SHA-256 (4.0/3.7 times faster). [d02958bd30, 0b3ec359e2] - Use ARMv7/NEON accelerated GCM implementation (3 times faster). [2445cf7431] - Use of i386/SSSE3 for SHA-512 (4.5 times faster on Ryzen 7). [b52dde8609] - Use 64 bit ARMv8/CE PMULL for CRC (7 times faster). [14c8a593ed] - Improve CAST5 (40% to 70% faster). [4ec566b368] - Improve Blowfish (60% to 80% faster). [ced7508c85] * Bug fixes: - Fix infinite loop due to applications using fork the wrong way. [#3491][also in 1.8.4] - Fix possible leak of a few bits of secret primes to pageable memory. [#3848][also in 1.8.4] - Fix possible hang in the RNG (1.8.3 only). [#4034][also in 1.8.4] - Several minor fixes. [#4102,#4208,#4209,#4210,#4211,#4212] [also in 1.8.4] - On Linux always make use of getrandom if possible and then use its /dev/urandom behaviour. [#3894][also in 1.8.4] - Use blinding for ECDSA signing to mitigate a novel side-channel attack. [#4011,CVE-2018-0495] [also in 1.8.3, 1.7.10] - Fix incorrect counter overflow handling for GCM when using an IV size other than 96 bit. [#3764] [also in 1.8.3, 1.7.10] - Fix incorrect output of AES-keywrap mode for in-place encryption on some platforms. [also in 1.8.3, 1.7.10] - Fix the gcry_mpi_ec_curve_point point validation function. [also in 1.8.3, 1.7.10] - Fix rare assertion failure in gcry_prime_check. [also in 1.8.3] - Do not use /dev/srandom on OpenBSD. [also in 1.8.2] - Fix test suite failure on systems with large pages. [#3351] [also in 1.8.2] - Fix test suite to not use mmap on Windows. [also in 1.8.2] - Fix fatal out of secure memory status in the s-expression parser on heavy loaded systems. [also in 1.8.2] - Fix build problems on OpenIndiana et al. [#4818, also in 1.8.6] - Fix GCM bug on arm64 which troubles for example OMEMO. [#4986, also in 1.8.6] - Detect a div-by-zero in a debug helper tool. [#4868, also in 1.8.6] - Use a constant time mpi_inv and related changes. [#4869, partly also in 1.8.6] - Fix mpi_copy to correctly handle flags of opaque MPIs. [also in 1.8.6] - Fix mpi_cmp to consider +0 and -0 the same. [also in 1.8.6] - Fix extra entropy collection via clock_gettime. Note that this fallback code path is not used on any decent hardware. [#4966, also in 1.8.7] - Support opaque MPI with gcry_mpi_print. [#4872, also in 1.8.7] - Allow for a Unicode random seed file on Windows. [#5098, also in 1.8.7] * Other features: - Add OIDs from RFC-8410 as aliases for Ed25519 and Curve25519. [also in 1.8.6] - Add mitigation against ECC timing attack CVE-2019-13626. [#4626] - Internal cleanup of the ECC implementation. - Support reading EC point in compressed format for some curves. [#4951] For a list of interface changes and
Re: Re: WKD proper behavior on fetch error
On Tue, Jan 19, 2021 at 2:36 AM Ángel wrote: > > On 2021-01-17 at 23:43 +, Stefan Claas via Gnupg-users wrote: > > I encountered only one MITM attack a couple of years ago so far, from an > > SKS user. He was a retired police officer from Austria, who contacted me. > > But what you say I was thinking about as well. My proposal was to include > > in the policy file fingerprint(s) of key(s) and generate an .ots file, from > > opentimestamps.org, from the policy file and put that .ots file somewhere. > > In the old days it was common, prior starting encrypted comms to compare > > fingerprints over other channels. > > If you can safely publish that ots file, you could as well publish your > openpgp key in the same place. > > And if you are exchanging fingerprints over a separate, secure channel, > you can use that to directly verify/fetch the key. > > > (It often makes sense to publish it in many redundant ways, but > strictly it _shouldn't_ be needed) My thinking is the following, if there would be a consensus for this by the OpenPGP community, after discussing this, while currently not breaking the specs, it could be arranged like thisl: The submitting part of an policy file, containing the fingerprint(s) can be done even on a compromised online computer, because the policy file is immediately accepted by opentimestamps.org and others and then included in the Bitcoin blockchain. As suggestion, for easy implementation,, for WKD clients, could be that then the policy.ots file is placed in the same directory the policy file resides. A policy file could look like this, with remark lines at the beginning: # WKD policy for sac001.github.io # Maintainer: Stefan Claas, ste...@sac001.github.io # Updated: current date of last update. fingerprint #1 fingerprint #2 etc. A WKD client could then fetch with an additional --all parameter all three files and save them in the current working directory, e.g pub key, policy file and policy.ots, thus allowing a WKD users to quickly check, if desired, to compare the downloaded data with the sha256 hash at opentimestamp.org and others. To make it for Mallory harder to exchange the whole directory a WKD user could for example put in his MUA/NUA .signature file the following: WOH sha256 hash. instead of gpg pub key availabe at etc. WOH = WKD-OTS-Hash And a WKD client could do this as CLI app: wkd get [--all] al...@example.com Well, only a proposal. Best regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please tackle the Right Thing (was: WKD Checker)
On Tue, Jan 19, 2021 at 11:15 AM Werner Koch wrote: > > Stefan, > > It has been mentioned several time here that the use of the openpgpkey > sub-domain is required to allow implementation of the Web Key Directory > in browsers. This is a real world use case and pretty important for web > mailers like protonmail. > > I would suggest that you put your energy on a useful task instead of > confusing people here with crude arguments why we should support invalid > X.509 certificates for TLS connections. > > Thus go for Google and Mozilla and convince them that SRV records are > important for many applications. That is not just for the Web Key > Directory but also for XMPP clients in a browser and many other modern > protocols. After that as been achieved we can eventually migrate back > to SRV records. Hello Werner, What you or maybe other people here do not get, I accept that there is for the advanced-method a requirement to use an openpgpkey subdomain part, which a) is triggered first and b) as understood by Damien's reply was asked for by some JavaScript programmers. This is perfectly fine! *But* when there exists also a direct-method in you current draft, which people like to use, when low on budged or which like to avoid, for whatever privacy reasons they have, the openpgpkey subdomain part, they should be IMHO allowed to use the direct-method only or at least GnuPG and gpg4win should fallback to this method, if a cert error, according to GnuPG's or gpg4win's WKD implementation occurs. I guess this would be a <5 minute quick fix in your codebase. Please try also to not use the term invald cert, if a cert is valid and only is 'invalid' in the current way of how GnuPG and gpg4win handles your WKD implementation. People know now that other OpenPGP apps can handle my github.io key, from my GitHUb page. Best regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
On Tue, 19 Jan 2021 09:28, Neal H. Walfield said: > When you look up the openpgpkey.example.org domain, you are revealing > to anyone snooping DNS traffic that you are using OpenPGP and are > looking for a key related to example.org. That's a privacy issue. No, it isn't. The next thing you do is to send the mail and get a reply. Get real. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fundraising
On Mon, 18 Jan 2021 16:29, Lars Noodén said: > Yes, but that did not stop the bank's payment web interface from > requiring the name and address for payments to other countries. For Okay, I added our address to the SEPA page. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Please tackle the Right Thing (was: WKD Checker)
Stefan, It has been mentioned several time here that the use of the openpgpkey sub-domain is required to allow implementation of the Web Key Directory in browsers. This is a real world use case and pretty important for web mailers like protonmail. I would suggest that you put your energy on a useful task instead of confusing people here with crude arguments why we should support invalid X.509 certificates for TLS connections. Thus go for Google and Mozilla and convince them that SRV records are important for many applications. That is not just for the Web Key Directory but also for XMPP clients in a browser and many other modern protocols. After that as been achieved we can eventually migrate back to SRV records. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD Checker
On Mon, 18 Jan 2021 17:12:56 +0100, Stefan Claas wrote: > I repeat here once again GitHub has a *valid* SSL cert. You're right. github has a valid TLS certificate. But that valid TLS certificate is not valid for openpgpkey.sac001.github.io. That's just the way it is, sorry. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
On Mon, 18 Jan 2021 16:47:38 +0100,
Ángel wrote:
> So, while in the first case a bad certificate would be a critical
> failure, in the second the right thing would be to fetch the key
> *even if the certificate was invalid*, as it is used purely for
> discovery.
When you look up the openpgpkey.example.org domain, you are revealing
to anyone snooping DNS traffic that you are using OpenPGP and are
looking for a key related to example.org. That's a privacy issue.
When you send the HTTP GET request, you reveal what email address you
are interested in (yes, it is obfuscated by the hash, but that can
often be broken using a dictionary attack). That's an even bigger
privacy issue.
Given how easy it is to get a valid TLS certificate using Let's
Encrypt, I think it is better to flatout reject invalid TLS
certificates.
> - Should the client attempt to detect openpgpkey wildcard records and
> ignore the advanced method in such case? (this also covers ISP
> hijacking NXDOMAIN, which I also thought in)
> While it's easy to detect when this seems to be the case, that's still
> an heuristic, and why should I be prevented from serving WKD from a
> wildcard dns record if I want to ?
It's an interesting idea. But I'm afraid that it really complicates
the WKD client's implementation for marginal security improvements.
> - An idea that seems worth considering, inspired by the way flowcrypt
> does its check, is to fall back to the direct method if the openpgpkey
> subdomain exists but it doesn't serve a policy file.
>
> This would solve the issue of non-malicious NXDOMAIN hijackings or DNS
> wildcards (assuming the certificate was valid).
That's a neat idea.
> How do you envision the users to use WKD? I would generally expect key
> retrieval to be a manual action, performed either from command line or
> a GUI client, but in both cases it would be possible to show a
> diagnostic about the non-working WKD.* And, even if the MUA was
> configured to automatically fetch the recipients key every time, it
> still needs a way to report back whether the message will be sent
> encrypted, there is no key or it isn't trusted. Unless OpenPGP is being
> used in a purely opportunistic way.
First, I'd regularly refresh keys in the background using all
available methods (WKD, multiple keyservers, gpg sync-style key lists)
using something like parcimonie:
https://github.com/EtiennePerot/parcimonie.sh
Second, for key discovery, there are two main types of users. For
security-sensitive users (people whose threat model includes dying if
this type of information is revealed), we should probably make key
discovery via WKD a manual operation. For privacy-sensitive users,
I'd just transparently, and automatically look for a key when the user
types in an email address. For a bit more privacy, one could wait
until the user presses send so that any WKD lookup will normally
immediately be followed by an SMTP connection to the same domain. If
key discovery fails, the MUA could show an error ("can't encrypted,
because..."), or just send the message unencrypted, like Signal.
:) Neal
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
On Tue, 19 Jan 2021 10:11, raf said: > And it's discovery that begins with an email address. I > still can't work out what functionality WKD provides in > a situation that isn't email-related. The Web Key Directory maps mail addresses to a key. Mail addresses are universal identifiers and thus they can be used in most context where you need to lookup a key which is not under the control of your organization. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
