Re: Odd error

2020-12-01 Thread Todd Zullinger via Gnupg-users
Hi,

Werner Koch wrote:
> I looked at the Fedora Libgcrypt source and noticed that they ship
> libgcrypt with the nistp192 and all brainpool curves removed.  I have
> not yet build this version but given that one of your keys has brainpool
> curves this might be the culprit.
> 
> I can understand that they remove nistp192 for security policy reasons.
> But I do not understand why the brainpool curves are removed.  The
> general statement in the spec file is that curves need to be removed due
> to patent rasons.  However, Brainpool curves are less prone to patent
> claims for fast multiplication than the NIST curves and we actually use
> the very same code for all those Weierstrass curves. 

FWIW, I noticed that someone recently asked about the status
of the ECC Brainpool curves on the Fedora Legal list:

https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/WUQNAB4EPWSJMMVECL2TZGKB5KIDESII/

With luck, a fresh review by the Red Hat legal folks will
result in those curves becoming accessible in the Fedora
libgcrypt packages.

Cheers,

-- 
Todd

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Odd error

2020-12-01 Thread Werner Koch via Gnupg-users
On Mon, 30 Nov 2020 22:20, Werner Koch said:

> I'll build with the Fedora patches in the next days.  If the missing
> curves are really the reason, we can fix that.

Yes, the disabled Brainpool curves lead to the import problem.  I'll see
what we can do.  See https://dev.gnupg.org/T5162


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: Odd error

2020-11-30 Thread Werner Koch via Gnupg-users
Hi!

I looked at the Fedora Libgcrypt source and noticed that they ship
libgcrypt with the nistp192 and all brainpool curves removed.  I have
not yet build this version but given that one of your keys has brainpool
curves this might be the culprit.

I can understand that they remove nistp192 for security policy reasons.
But I do not understand why the brainpool curves are removed.  The
general statement in the spec file is that curves need to be removed due
to patent rasons.  However, Brainpool curves are less prone to patent
claims for fast multiplication than the NIST curves and we actually use
the very same code for all those Weierstrass curves. 

I'll build with the Fedora patches in the next days.  If the missing
curves are really the reason, we can fix that.


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: Odd error

2020-11-30 Thread Werner Koch via Gnupg-users
On Mon, 30 Nov 2020 09:25, Robert J. Hansen said:

> I'll send the keyring onto you privately.

Thanks.  Unfortunately i was not able to replicate the bug on my Devuan
box.  I tried using the same Libgcrypt version but with some libraries
different.  Should not matter, though.

> * Libgcrypt 1.8.7 ()

This is a somehow patched version, it should read

* Libgcrypt 1.8.7 (04c156a4)

which gives the commit id of the release.  As you know, patching a
version is quite common and not a problem.  However, given the error
message, this is the first place where I need to look.  I don't have any
Fedora running here but it is a good opportunity to install a VM for
testing.  But not this evening anymore.


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: Odd error

2020-11-30 Thread Robert J. Hansen via Gnupg-users

The first one is the real error.  We can't compute the keygrip for the
public key.  If you can build gpg yourself please apply this patch:


It's a standard Fedora GnuPG, so although I'm sure a source RPM is 
available I'm not enough of an RPM surgeon to know how to modify the 
.rpmspec to apply the patch.


I'll send the keyring onto you privately.


or send me your sample key.  In any case please also run our new 2.2.24
command to see how libgcrypt has been built:

   gpgconf --show-versions



* GnuPG 2.2.25 (40f75823d)
GNU/Linux

* Libgcrypt 1.8.7 ()
version:1.8.7:10807:1.37-unknown:12500:
cc:100201:gcc:10.2.1 20201016 (Red Hat 10.2.1-6):
ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20:
pubkeys:dsa:elgamal:rsa:ecc:
digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2:
rnd-mod:linux:
cpu-arch:x86:
mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S:
hwflist:intel-cpu:intel-bmi2:intel-ssse3:intel-sse4.1:intel-pclmul:intel-aesni:intel-rdrand:intel-avx:intel-avx2:intel-fast-vpgather:intel-rdtsc:
fips-mode:n:n:
rng-type:standard:1:201:1:

* GpgRT 1.37-unknown (000)

* Libassuan 2.5.3 (4de3154)

* KSBA 1.3.5 (?)

* GNUTLS 3.6.15

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Odd error

2020-11-30 Thread Werner Koch via Gnupg-users
Hi!

On Mon, 30 Nov 2020 04:16, Robert J. Hansen said:

> gpg: kbx: error computing keygrip
> gpg: error writing keyring '/home/rjh/.gnupg/pubring.kbx': General error

The first one is the real error.  We can't compute the keygrip for the
public key.  If you can build gpg yourself please apply this patch:

--8<---cut here---start->8---
diff --git a/kbx/keybox-openpgp.c b/kbx/keybox-openpgp.c
index 6d6ed77dc..345af0164 100644
--- a/kbx/keybox-openpgp.c
+++ b/kbx/keybox-openpgp.c
@@ -240,6 +240,7 @@ keygrip_from_keyparm (int algo, struct keyparm_s *kp, 
unsigned char *grip)
 
   if (!err && !gcry_pk_get_keygrip (s_pkey, grip))
 {
+  gcry_log_debugsxp ("pubkey:", s_pkey);
   log_info ("kbx: error computing keygrip\n");
   err = gpg_error (GPG_ERR_GENERAL);
 }
--8<---cut here---end--->8---

or send me your sample key.  In any case please also run our new 2.2.24
command to see how libgcrypt has been built:

  gpgconf --show-versions
  


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

Odd error

2020-11-30 Thread Robert J. Hansen via Gnupg-users
This should not be happening, but is.  From a completely clean 
installation, importation of legitimate OpenPGP keys results in strange 
general failures.  The system is an x64 Fedora 33 box running GnuPG 
2.2.24 on libgcrypt 1.8.6.


I'm happy to provide the keys.asc file to any GnuPG dev who needs it to 
look into this problem.


=

[rjh@localhost ~]$ gpgconf --kill gpg-agent
[rjh@localhost ~]$ rm -rf .gnupg
[rjh@localhost ~]$ gpg --import Downloads/keys.asc
gpg: directory '/home/rjh/.gnupg' created
gpg: keybox '/home/rjh/.gnupg/pubring.kbx' created
gpg: /home/rjh/.gnupg/trustdb.gpg: trustdb created

[snip]

gpg: key 1DCBDC01B44427C7: public key "Robert J. Hansen 
" imported

gpg: kbx: error computing keygrip
gpg: error writing keyring '/home/rjh/.gnupg/pubring.kbx': General error
gpg: error reading 'Downloads/keys.asc': General error
gpg: no valid OpenPGP data found.
gpg: import from 'Downloads/keys.asc' failed: General error
gpg: Total number processed: 5
gpg:   imported: 5
gpg: no ultimately trusted keys found

=

Let's try again on a higher verbosity level.  (I have to say I saw 
nothing of use here.)


=

[rjh@localhost ~]$ gpgconf --kill gpg-agent
[rjh@localhost ~]$ rm -rf .gnupg
[rjh@localhost ~]$ gpg -vvv --import Downloads/keys.asc
gpg: using character set 'utf-8'
gpg: directory '/home/rjh/.gnupg' created
gpg: keybox '/home/rjh/.gnupg/pubring.kbx' created
gpg: armor: BEGIN PGP PUBLIC KEY BLOCK
# off=0 ctb=99 tag=6 hlen=3 plen=269

[snipping successfully imported public keys]
[leaving in debugging lines from other GnuPG components]
[some data anonymized, because it's not mine]

gpg: pub  rsa2048/ 2010-10-18  
gpg: writing to '/home/rjh/.gnupg/pubring.kbx'
gpg: /home/rjh/.gnupg/trustdb.gpg: trustdb created
gpg: using pgp trust model
gpg: key : public key "" imported
gpg: no running gpg-agent - starting '/usr/bin/gpg-agent'
gpg: waiting for the agent to come up ... (5s)
gpg: connection to agent established
gpg: pub  rsa2048/ 2012-05-24  
gpg: writing to '/home/rjh/.gnupg/pubring.kbx'
gpg: key : public key "" imported
gpg: pub  rsa4096/ 2013-09-13  
gpg: writing to '/home/rjh/.gnupg/pubring.kbx'
gpg: key : public key "" imported
gpg: pub  rsa4096/ 2016-10-04  
gpg: writing to '/home/rjh/.gnupg/pubring.kbx'
# off=10553 ctb=99 tag=6 hlen=3 plen=397
:public key packet:
version 4, algo 1, created 1437075659, expires 0
pkey[0]: [3072 bits]
pkey[1]: [17 bits]
keyid: 1DCBDC01B44427C7
gpg: key : public key "" imported
# off=10953 ctb=b4 tag=13 hlen=2 plen=35
:user ID packet: "Robert J. Hansen "
# off=10990 ctb=89 tag=2 hlen=3 plen=446
:signature packet: algo 1, keyid 1DCBDC01B44427C7
version 4, created 1437078058, md5len 0, sigclass 0x13
digest algo 8, begin of digest cf aa
hashed subpkt 2 len 4 (sig created 2015-07-16)
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 11 len 11 (pref-sym-algos: 10 13 9 12 8 11 7 4 3 1 2)
hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 3)
hashed subpkt 22 len 3 (pref-zip-algos: 3 1 2)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
subpkt 16 len 8 (issuer key ID 1DCBDC01B44427C7)
data: [3070 bits]
# off=11439 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid DB1187B9DD5F693B
version 4, created 1437210170, md5len 0, sigclass 0x13
digest algo 10, begin of digest 8b 3c
hashed subpkt 2 len 4 (sig created 2015-07-18)
subpkt 16 len 8 (issuer key ID DB1187B9DD5F693B)
data: [4095 bits]
# off=11982 ctb=b4 tag=13 hlen=2 plen=38
:user ID packet: "Robert J. Hansen "
# off=12022 ctb=89 tag=2 hlen=3 plen=449
:signature packet: algo 1, keyid 1DCBDC01B44427C7
version 4, created 1467479780, md5len 0, sigclass 0x13
digest algo 8, begin of digest 34 63
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 11 len 11 (pref-sym-algos: 10 13 9 12 8 11 7 4 3 1 2)
hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 3)
hashed subpkt 22 len 3 (pref-zip-algos: 3 1 2)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
hashed subpkt 2 len 4 (sig created 2016-07-02)
hashed subpkt 25 len 1 (primary user ID)
subpkt 16 len 8 (issuer key ID 1DCBDC01B44427C7)
data: [3072 bits]
# off=12474 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid DB1187B9DD5F693B
version 4, created 1437210170, md5len 0, sigclass 0x13
digest algo 10, begin of digest a8 e5
hashed subpkt 2 len 4 (sig created 2015-07-18)
subpkt 16 len 8 (issuer key ID DB1187B9DD5F693B)
data: [4096 bits]
# off=13017 ctb=b4 tag=13 hlen=2 plen=41