Re: ctf-like WKD challenge (was: WKD proper behavior on fetch error)
On Thu, Jan 21, 2021 at 8:02 AM Stefan Claas wrote: > The nice things about OpenPGP amored messages is also that > procmail and friends can be used at providers to filter -BEGIN blah P.S. When Stale Schumacher ran the International PGP Homepage in the 90's people could download PGP for Unix, VAX/VMS, Windows and the Mac (there was no Linux IIRC available at that time) and there was a stealth mode available, e.g. to hide the -BEGIN blah in armored messages. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ctf-like WKD challenge (was: WKD proper behavior on fetch error)
On Thu, Jan 21, 2021 at 12:25 AM Ángel wrote: > Last night, I prepared the domain wkdtest.pgp.16bits.net It is a valid > wkd server. I have just created and uploaded there a new pgp key, and > you have to obtain it: > > > «We have intercepted the following communication sent to an spy using > an undisclosed openpgp implementation. Based on the detected network > traffic, we are sure the key itself was downloaded using wkd, and the > domain of the userid to be ‘wkdtest.pgp.16bits.net’ > > Your mission, should you choose to accept it, is to find out the name > of the spy to which this communication was addressed: > > > -BEGIN PGP MESSAGE- Well, I am not in the spy business, but according to the meta data of the message it is addressed to key owner 0xCD2687BFBB7D2624, if I see it right. Since you write that you have intercepted the comms, you are aware about the following phrase: 'people get assasinated by meta data ...' I guess this is true, because last year China, for example, executed 24 CIA agents. The nice things about OpenPGP amored messages is also that procmail and friends can be used at providers to filter -BEGIN blah So in the end, I would say when one intercepts the communications and according how MTAs work the involved parties should have it not to difficult to figure out to whom the message(s) is intended for. My motto is :TCP/IP where C stands for me for *Control* and P for Protokoll, e.g. protokoll or log everything. ;-) 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
On 2021-01-20 at 20:29 +0100, André Colomb wrote: > Hi all, > > after some more thought I came up with a possible wording to clarify > the > fallback behavior. Assuming that an opportunistic approach is > preferred, so the direct method should be used not only based on the > existence of openpgpkey as a SRV or other record. Here goes: > > > ---SNIP--- (page 3, second paragraph in the current draft version 11) > > There are two variants on how to form the request URI: The advanced > and the direct method. Implementations MUST first try the advanced > method. > If that does not conclude with a successful HTTP response (e.g. > status code 2xx), they MUST fall back to the direct method. If the > required sub-domain exists, but other errors occur during the > connection, they SHOULD output an error message pointing out the > failure reason to the end user. Such other errors include, for > example, invalid, expired or misconfigured TLS certificates and HTTP > failure codes (4xx or 5xx). > > ---SNIP--- Hello André Thanks for contributing Suitable return codes for fetching a key would be 200 (for successful keys) and 404 (the key is not in the server). In both cases, if it is a valid wkd server, the server shouldn't fall back to direct. You could also have a 304 if the client was refreshing a key. Maybe 201 if a web-based submission protocol was added in the future. https://mailarchive.ietf.org/arch/msg/openpgp/f6V8W9wKY6dt2wAq4FBOWk8wtos/ seems to expect that HTTP redirects would work as well (seems reasonable), although it isn't explicitly stated in the document. I think the main status that would bring such trouble would be 401, 403, 5xx, although there could be some exotic cases (e.g. 407). Erroring to the user on any status code the client does not know how to handle seems the safe procedure. > So what do you think? I'm not subscribed to any IETF mailing lists, > but feel free to propose this in the relevant circles. I hereby > renounce my rights on the modified text :-) I think the right venue would be the openpgp wg. This was discussed there in the past, and I hope to see WKD published through it one day. However, although there were interesting ideas on this thread for advancing it (amidst all the generated noise), I am hesitant to open a discussion there about wkd, since openpgp working group was recently rechartered to produce the rfc 4880 bis, and wkd is not covered by its current scope. I don't think there would be opposition for adopting it if rechartering after rfc 4880bis is out, but it's a bit odd to open a discussion about something else before starting the actual chartered work. Maybe other people have an opiniono on this ? Kind regards ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
ctf-like WKD challenge (was: WKD proper behavior on fetch error)
On 2021-01-20 at 08:08 +0100, Stefan Claas via Gnupg-users wrote: > 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. No, no, no. The idea of my previous mail, was *precisely* that there is no point for Mallory to do that. Counting wkd servers can be interesting for statistics, measuring adoption, etc. but that would be of no use for an attacker. Ok, let's frame it a bit different. I will give a game for you. Last night, I prepared the domain wkdtest.pgp.16bits.net It is a valid wkd server. I have just created and uploaded there a new pgp key, and you have to obtain it: «We have intercepted the following communication sent to an spy using an undisclosed openpgp implementation. Based on the detected network traffic, we are sure the key itself was downloaded using wkd, and the domain of the userid to be ‘wkdtest.pgp.16bits.net’ Your mission, should you choose to accept it, is to find out the name of the spy to which this communication was addressed: -BEGIN PGP MESSAGE- hQEMA80mh7+7fSYkAQf+PAyI1VWXZRST42basod3Rk7/44hi8nw+ARdmEy61esdJ qIWQvz2qyPJsmS5if5xfUhwzmGI6itNC+wqIrNNo5AGt+qzkHHYZswuaintmk5IF Wrh6xxHdiH1q2UMgl/SGhEQcPStUy1GdTUcx9wygjmSQwdgQhimezmdbhhoYQ13s hlZ001IhiGkBse8V+qK0g7vhWCO5XTHwMLMr3I1twcRbow4RYtw1BGp4mco1llgm BkRpAL+WFw/CFBp7W7Dn9Yz9wN5q7LDLlyO3sGmWex7IcxD2McHSYNR7roiPjwu8 5ke+MO7CM3VHmMyx1eCAXRJY7RwDvIYaZLJHbtai+owuBAkDAjJqwNFYeYiW6r/E 9KRfCCy/LsKDQW7rWCs0dLW1BM5xswAIk/SzaJDTMNJQAW6yb7Le32ao1MsEfx47 EAwlArtFZTWZvwiICcBHFPbJ8V6+mHRr4qjRKQFIE96zGCLQHnoZfUjhl+Hb5zPb +L3PfKDvYARTEOJvj/4w2Tc= =6hHu -END PGP MESSAGE-» Can you figure this out? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please tackle the Right Thing
On Wed, Jan 20, 2021 at 9:21 PM Stefan Claas wrote: > > On Wed, Jan 20, 2021 at 4:15 PM Stefan Claas > wrote: > > > > On Wed, Jan 20, 2021 at 1:55 PM Werner Koch wrote: > > > > > Broken implementations are not a reason to break correct > > > implementations. > > > > Since 'broken' implementations are available and can handle both cases, > > and this is now generally known, people do *not* need to follow a *draft* > > and can *happily* write code as they please to wish. > > P.S. I would like to inform the community that I installed the lastest > version of Mozilla Thunderbird, a couple of minutes ago, and guess > what ... Thunderbird fetched my github.io pub key properly with their > WKD implemtentation. P.P.S. 78.6.1 from their offical web site and not a nightly build etc. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please tackle the Right Thing
On Wed, Jan 20, 2021 at 4:15 PM Stefan Claas wrote: > > On Wed, Jan 20, 2021 at 1:55 PM Werner Koch wrote: > > > Broken implementations are not a reason to break correct > > implementations. > > Since 'broken' implementations are available and can handle both cases, > and this is now generally known, people do *not* need to follow a *draft* > and can *happily* write code as they please to wish. P.S. I would like to inform the community that I installed the lastest version of Mozilla Thunderbird, a couple of minutes ago, and guess what ... Thunderbird fetched my github.io properly with their WKD implemtentation. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please tackle the Right Thing
Hi all, after some more thought I came up with a possible wording to clarify the fallback behavior. Assuming that an opportunistic approach is preferred, so the direct method should be used not only based on the existence of openpgpkey as a SRV or other record. Here goes: ---SNIP--- (page 3, second paragraph in the current draft version 11) There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. If that does not conclude with a successful HTTP response (e.g. status code 2xx), they MUST fall back to the direct method. If the required sub-domain exists, but other errors occur during the connection, they SHOULD output an error message pointing out the failure reason to the end user. Such other errors include, for example, invalid, expired or misconfigured TLS certificates and HTTP failure codes (4xx or 5xx). ---SNIP--- The last "SHOULD" clause would allow for Sequoia's current behavior to silently switch over, but shows what the Right Way would encompass. Regarding GnuPG, the second "MUST" clause requires a change to fall back after later connection errors. I think that this logic still holds just in case SRV records are to be used again. So what do you think? I'm not subscribed to any IETF mailing lists, but feel free to propose this in the relevant circles. I hereby renounce my rights on the modified text :-) Kind regards André -- Greetings... From: André Colomb signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: make check failed tests
On Wed, Jan 20, 2021 at 6:11 PM wrote: > > On Wed, Jan 20, 2021, mettodo via Gnupg-users wrote: > > > 14 of 20 tests failed when doing "make check" for gnupg 2.2.27. What > > should I do? > > Most certainly you should not tell anyone which OS or compiler > or options you used. > Neither should you include the actual test failures. :-D :-D :-D ... Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: make check failed tests
On Wed, Jan 20, 2021, mettodo via Gnupg-users wrote: > 14 of 20 tests failed when doing "make check" for gnupg 2.2.27. What > should I do? Most certainly you should not tell anyone which OS or compiler or options you used. Neither should you include the actual test failures. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please tackle the Right Thing
On Wed, Jan 20, 2021 at 1:55 PM Werner Koch wrote: > Broken implementations are not a reason to break correct > implementations. Since 'broken' implementations are available and can handle both cases, and this is now generally known, people do *not* need to follow a *draft* and can *happily* write code as they please to wish. 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 Wed, 20 Jan 2021 14:46, Erich Eckner said: > is queried. This resolves to some old address (my DNS configuration > error), which serves the wrong content. Is it right, that this SRV record > should be queried? Should I update it or remove it? Yes, the SRV record is used if there is no openpgpkeys sub-domain. The reason is that the original scheme was to use SRV records but we had to switch to a subdomain due to problems with browser based code. > I assume, this is for debugging *a lot* of gnupg in one place (like your Right. It is also cool to watch the diagnostccs fly by during regular use ;-) 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: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 20 Jan 2021, Werner Koch wrote: On Tue, 19 Jan 2021 17:24, Erich Eckner said: error in the subject when doing `gpg - --locate-external-keys Many -v don't really help here because the actual task is done by the dirmngr process. Thus to debug this put log-file /somewhere/dirmngr.log verbose debug ipc,network,dns into ~/.gnupg/dirmngr.conf and "gpgconf --kill dirmngr". The log file should give you a pretty good insight what's going on. Thank you. I'm always confused by the different parts involved and how to properly increase verbosity :-) - From the log, I see, that _openpgpkey._tcp.eckner.net SRV is queried. This resolves to some old address (my DNS configuration error), which serves the wrong content. Is it right, that this SRV record should be queried? Should I update it or remove it? You may also use log-file socket:// and run in another tty watchgnupg --time-only --force or with older version of gnupg watchgnupg --time-only --force $(gpgconf --list-dirs socketdir)/S.log I assume, this is for debugging *a lot* of gnupg in one place (like your work station, Werner). I'm totally happy with (temporarily) dumping log files in /tmp :-D If we can identify common error patterns in the diagnostics we can convey them to the gpg process to make debugging easier. Ok, I understand. Salam-Shalom, Werner Thank you for your help! Cheers, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAINCAACgkQCu7JB1Xa e1q3sQ/9EuJaERLiHdOqCYEXaqUu+O1Q7Tm7h6h9DLHLHykcJGs+XOK39XStmzTI 1XhHp5CRZJ+f88Dd98eJPSGcGCvnLauHBfyVJwq33TzgQQXzh3D88kpr9RrZjvc1 wLRiaQ3Mx4Jzk26Fmh56qrweQFGOq/RdXzvN45QatM4fSB6hdfB2+sV+RYU6yvpi ABqfFk/RHCnEZGDwI0Du2k6yfbIASgPJozJpVFLsiEv9OmK6IHibyQCOjcjSCBDs RvhRFeS2XrEfpktq+FPYRDuc5t6nnmbvTTk2agdoDaxnmr+LxBZJRSOG3NzcdzXJ Ikg3jOp9KU+Oq9cSijt8E/9wRYT/ukrzehH2j+fEqH62ypqtAU6dtTcX+6tKpZct QxYMxr/A+ovq/H68szfoC4WAZkX7baqj3IF53O8z6XZ4qv5611OA4DN7Tb9B8G97 QuZXu+30pbvrNigyLO/8RsX3KttFfB02md8DF/0NNGT91Ua2iYm1cu650Zl2dtkW TehKWvT6627+1FAL4WrQx5GAPetfiP34pyIXSUZyNhzozLCNAjeXh3RhNoMLgFI+ 5rTh0lwNYf/BqS35QOvHbE7pWR/c7OnzKyOsMDO8AdIPNz7WAXV+HTa9QXa8zrfj 4j7UQETYC9Df4FdLn4LCOpIlD3GuWfkMgvZ3q0lQqHzP4v9AfIU= =CIVf -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please tackle the Right Thing
On Tue, 19 Jan 2021 16:31, Stefan Claas said: > 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 If you do some research on the infrastructure of large providers (which includes talking to them) you may learn that there might be an example.com address which is not under the control of the example company. However, SRV records and sub-domains are under their control. Thus not allowing the direct method if there is a sub-domain or SRV record is important. > 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 An X.509 certifiate used for TLS conenctions in the web must carry the server name. If it does not it is invalid. > WKD implementation. People know now that other OpenPGP apps can > handle my github.io key, from my GitHUb page. Broken implementations are not a reason to break correct implementations. 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: gpg: error retrieving 'er...@eckner.net' via WKD: Connection closed in DNS
On Tue, 19 Jan 2021 17:24, Erich Eckner said: > error in the subject when doing `gpg - --locate-external-keys Many -v don't really help here because the actual task is done by the dirmngr process. Thus to debug this put log-file /somewhere/dirmngr.log verbose debug ipc,network,dns into ~/.gnupg/dirmngr.conf and "gpgconf --kill dirmngr". The log file should give you a pretty good insight what's going on. You may also use log-file socket:// and run in another tty watchgnupg --time-only --force or with older version of gnupg watchgnupg --time-only --force $(gpgconf --list-dirs socketdir)/S.log If we can identify common error patterns in the diagnostics we can convey them to the gpg process to make debugging easier. 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: libgcrypt-1.9.0: 32 bit cross build fails on asm code
Hi! thanks for the report. I opened a ticket for this: https://dev.gnupg.org/T5257 Please check over there for status updates. (I accidently mentioned gnupg-users in the annoucement mail and not gcryypt-devel which would been the right one). 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
make check failed tests
Hey, 14 of 20 tests failed when doing "make check" for gnupg 2.2.27. What should I do? thanks! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
libgcrypt-1.9.0: 32 bit cross build fails on asm code
hello
(my specs are enclosed below)
just tried to cross-build 32 bit libgcrypt-1.9.0 on a 64 bit machine
and getting:
8<
libtool: compile: gcc -m32 -DHAVE_CONFIG_H -I. -I.. -I../src -I../src
-I../mpi -I../mpi -I/usr/include -I/usr/Xorg/include -fvisibility=hidden
-fno-delete-null-pointer-checks -Wall -c rijndael-aesni.c -fPIC -DPIC -o
.libs/rijndael-aesni.o
rijndael-aesni.c: In function 'aesni_ocb_enc':
rijndael-aesni.c:2815:7: error: 'asm' operand has impossible constraints
2815 | asm volatile ("pxor %[tmpbuf0],%%xmm1\n\t"
| ^~~
make[3]: *** [Makefile:1355: rijndael-aesni.lo] Error 1
make[3]: Leaving directory
'/home/balducci/tmp/install-us-d/libgcrypt-1.9.0.d/libgcrypt-1.9.0/cipher'
>8
No problem whatsoever building for native 64 bit.
I get the same error (always for the 32 bit cross build) on two
machines with different cpu's (both AMD, though)
32 bit build succeeds if I run with --disable-asm, but since it has worked
flawlessly for ages (without --disable-asm), I'm just wondering if asm is
not supported any longer for this cross build, or if 1.9.0 needs some
fix (or if I am missing something obvious, of course)
I haven't changed anything in my installation script (since 1.4.6).
thanks in advance for any hint/help
ciao
-gabriele
Configuring with:
--build=x86_64-unknown-linux-gnu
--host=i686-pc-linux-gnu
8<
Libgcrypt v1.9.0 has been configured as follows:
Platform: GNU/Linux (i686-pc-linux-gnu)
Hardware detection module: libgcrypt_la-hwf-x86
Enabled cipher algorithms: arcfour blowfish cast5 des aes twofish
serpent rfc2268 seed camellia idea salsa20
gost28147 chacha20 sm4
Enabled digest algorithms: crc gostr3411-94 md4 md5 rmd160 sha1
sha256 sha512 sha3 tiger whirlpool stribog
blake2 sm3
Enabled kdf algorithms:s2k pkdf2 scrypt
Enabled pubkey algorithms: dsa elgamal rsa ecc
Random number generator: default
Try using jitter entropy: yes
Using linux capabilities: no
Try using Padlock crypto: yes
Try using AES-NI crypto: yes
Try using Intel SHAEXT:yes
Try using Intel PCLMUL:yes
Try using Intel SSE4.1:yes
Try using DRNG (RDRAND): yes
Try using Intel AVX: yes
Try using Intel AVX2: yes
Try using ARM NEON:n/a
Try using ARMv8 crypto:n/a
Try using PPC crypto: n/a
>8
gcc -v:
==
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/stow.d/versions/gcc-10.2.0/usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/home/balducci/tmp/install-us-d/gcc-10.2.0.d/gcc-10.2.0/configure
--prefix=/opt/stow.d/versions/gcc-10.2.0/usr
--libdir=/opt/stow.d/versions/gcc-10.2.0/usr/lib64
--libexecdir=/opt/stow.d/versions/gcc-10.2.0/usr/lib64 --enable-shared
--disable-bootstrap --enable-languages=c,c++,objc,fortran --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)
uname -srvmo:
Linux 5.9.8 #1 SMP Wed Nov 11 08:36:17 CET 2020 x86_64 GNU/Linux
cat /proc/cpuinfo (machine 1):
=
processor : 0
vendor_id : AuthenticAMD
cpu family : 23
model : 113
model name : AMD Ryzen 5 3600 6-Core Processor
stepping: 0
microcode : 0x8701021
cpu MHz : 4155.077
cache size : 512 KB
physical id : 0
siblings: 6
core id : 0
cpu cores : 6
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 16
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf
pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx
f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse
3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext
perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibpb stibp
vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb
sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total
cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock
nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter
pfthreshold avic v_vmsave_vmload vgif umip rdpid overflow_recov succor smca
bugs: sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips
