Page MenuHome GnuPG

ECDH - encryption with obfuscated size of the symmetric key
Closed, DuplicatePublic


It seems gpg (GnuPG) 2.3.0-beta190 (libgcrypt 1.9.0-beta14) fails in following scenario

  1. Create ECDSA+ECDH key
  2. Encrypt data as according to rfc 4880 bis 04 *and obfuscate the size of the symmetric encryption key* (see below for more details)
  3. GnuPG fails to decrypt such packets, displaying following error message;
gpg: encrypted with 256-bit ECDH key, ID 2D7179E8101877EE, created 2018-01-29
      "specspecspec <>"
gpg: public key decryption failed: Wrong secret key used
gpg: decryption failed: No secret key

Regarding symmetric key obfuscation, in "13.5. EC DH Algorithm (ECDH)" the spec says

This encoding allows  the sender to obfuscate the size of the symmetric encryption key used
 to encrypt the data.  For example, assuming that an AES algorithm is
 used for the session key, the sender MAY use 21, 13, and 5 bytes of
 padding for AES-128, AES-192, and AES-256, respectively, to provide
 the same number of octets, 40 total, as an input to the key wrapping

In scenario above I'm using AES-128 key and my padding has 21 bytes (so size of the key before wrapping is 40 bytes).

When debugging decryption I've noticed that after AES-unwrap I'm getting following data:

gpg: DBG: ecdh decrypted to : 03 FF 26 7F 3B 14 0A 82 34 AA 3D E7 72 82 5C 6B B8 06 F4 15 15 15 15 15

It seems that part of the padding is removed (bug?) which would mean that unpadding fails.

Everything works OK if data before AES-wrap is padded with PKCS5 (so that size of this data is rounded up to multiple of 8 bytes)

I've used following keys for testing:



and data which suppose to decrypt to "Plaintext data"

Version: rnp 0.8.0~


From the other hand - I'm not sure if "key size obfuscation" brings much value from security point of view. Also spec mentions PKCS5, which obviously should be PKCS7 as PKCS5 is limited to padding up to 8 bytes. So it may be that's a bug in the spec not GnuPG (PS: yes I know it was copied from RFC 6637)

Event Timeline

neurohenry updated the task description. (Show Details)
neurohenry updated the task description. (Show Details)
neurohenry renamed this task from ECDH - encryption with obfuscated key to ECDH - encryption with obfuscated size of the symmetric key.Jan 29 2018, 10:25 PM
werner added a project: gnupg (gpg23).
werner added a subscriber: werner.

I also don't think that key size obfuscation is useful, after all the preferences of the key demand a certain key size.

We need to check rfc-4880bis for the PCKS5/7 reference - I doubt that we should have such a reference at all in OpenPGP.

gniibe added a subscriber: gniibe.

Your example data is malformed, I suppose.

# off=0 ctb=c1 tag=1 hlen=2 plen=110 new-ctb
:pubkey enc packet: version 3, algo 18, keyid 2D7179E8101877EE
	data: [515 bits]
	data: [264 bits]

The second data is 264-bit = 33-byte, which should be 41-byte.

It seems that the reference to PKCS#5 is correct. It is an issue of how to describe the case of more than 8-byte padding in OpenPGP.

I don't think PKCS #7 allows longer padding for 40-byte packet (in the context of 8-byte boundary).

I have run into an interoperability issue between BouncyCastle PGP (Java) library and gpg which seems to caused by key obfuscation.

BouncyCastle by default obfuscates the session key when encrypting data using ECDH and AES. If the data is encrypted with AES, gpg cannot decrypt it and the following error is shown:

"public key decryption failed: Wrong secret key used"

It works with AES256. This seems exactly the same issue as discussed on this bug report. Decryption works if I replace the ofuscation by PKCS5 padding.

Are there plans to support key obuscation in gpg? Or is this issue caused by something else?

If there are no plans to support key obfuscation, wouldn't it be better to remove key obfuscation from RFC 4880bis? especially since gpg is the de facto standard.

BouncyCastle bug report:

@mbrinkers : I think that it was fixed in GnuPG 2.2.21 by T4908: ECDH with AES-128 decryption failure when fully padded.
It was unfortunate that this bug report didn't work to solve problem, with malformed data and discussion went to unrelated thing.

Anyway, I believe that the problem has gone. Please confirm with GnuPG 2.2.21.

Since it was handled in T4908, this task is merged into that.