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 <spec@spec.org>"
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
method.
``
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.
I've used following keys for testing:
```
-----BEGIN PGP PRIVATE KEY BLOCK-----
lHcEWm+ISRMIKoZIzj0DAQcCAwS8ry5JK28SHCOIV/U65rWYcroSk00rRwPW9NO5
rFLa2VesQpeh0p+TC5TcIrTB0xgNlmazxlxM/arwQh0IURjBAAEA+bS1EdgIKvSQ
wkbSAo/k1O9za50dJq7h+AbIOANv+CgQ8bQcc3BlY3NwZWNzcGVjIDxzcGVjQHNw
ZWMub3JnPoiQBBMTCAA4FiEEDSIFj7dkKS2I85vD33O8CxinHFcFAlpviEkCGwMF
CwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQ33O8CxinHFdBvwEA9kbbp35XB3DT
1jgkYwfdmyvmnyOksMcYrY5naLY3uTMBALCAWGaCS0Q4QM6PmaWZA1djhlY/ds9J
WmigNpYDeRRcnHsEWm+ISRIIKoZIzj0DAQcCAwR2VxlPZbTCMeP4YI4/KHCm22ls
qQFB01IFu69Um3kgjk5GknLa0uIn7WsEyfezC6BqMMNvkU1nwKY7Db/m+5U+AwEI
BwAA/A4ZrxfEdI5EeEqP1POeadXUvN5NiyKLQBxlS0nesbY+ELKIeAQYEwgAIBYh
BA0iBY+3ZCktiPObw99zvAsYpxxXBQJab4hJAhsMAAoJEN9zvAsYpxxXmBMA/RYi
sloISjvn5tVd1rKeScFXEwHnBxjLfMr9ocNxx8ljAPoCPLR1C+j2eg7SO6RsR17P
F9wCzfzESMtSv/S5sW9Wng==
=k6hE
-----END PGP PRIVATE KEY BLOCK-----
```
and data which suppose to decrypt to "Plaintext data"
```
-----BEGIN PGP MESSAGE-----
Version: rnp 0.8.0~
wW4DLXF56BAYd+4SAgME2cQ9TLmzpli64K0mdwTAS8CqqZNC1g1W+xvB/kb61uuuOjiqEl2VUc1O
QnvRQLAZrIPnfaI7FWi958HyOGWfbiB4Vv4lDEOaiXeOxnrLr7xsBizDlp91Gfvxy8eE59+A49I/
AZq8FkIA6K8vuR+T65S/MUCLiFJepkZ7PTG54rvixz6nFIqibJb8PhDRNfqbypgLDdr4bcjAmE2H
Dtmm1q3w
=XjBJ
-----END PGP MESSAGE-----
```
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 8 bytes).