Mailing List Archive

On Wed, 12 Dec 2001, Len Sassaman wrote:

> Any idea what would prompt this error?
>
> gpg: Ohhhh jeeee: no decrypt() for 17
> secmem usage: 2016/10528 bytes in 4/6 blocks of pool 10752/16384
> Aborted

Sent that too fast. I'm using 1.0.6, trying to decrypt a message encrypted
to my public key 09AC0A6A.


--Len.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 13 December 2001 03:56, you wrote:
> On Wed, 12 Dec 2001, Len Sassaman wrote:
> > Any idea what would prompt this error?
> >
> > gpg: Ohhhh jeeee: no decrypt() for 17
> > secmem usage: 2016/10528 bytes in 4/6 blocks of pool 10752/16384
> > Aborted
>
> Sent that too fast. I'm using 1.0.6, trying to decrypt a message
> encrypted to my public key 09AC0A6A.

I guess the 17 refers to the key algorithm. From doc/DETAILS:
17 = DSA (sometimes called DH, sign only)

So it seems that someone managed to encrypt a message with your
_signing_ key. But as a signing key is not intended to be used for
encryption gpg can't decrypt the message because there is no decrypt()
for algorithm 17.

Regards,
Ingo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8GUKKGnR+RTDgudgRAtMjAJ4r19kKaKtw0ovjuLsAtj/JEst3DACgzgmb
I3ySi+Jq70mMzIMSLhT5Hsc=
=2EaD
-----END PGP SIGNATURE-----

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.

> 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:2010000:1:

* GpgRT 1.37-unknown (0000000)

* 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

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.

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.

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.

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/legal@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