It seems gpg (GnuPG) 2.3.0-beta190 (libgcrypt 1.9.0-beta14) fails in following scenario
- Create ECDSA+ECDH key
- Encrypt data as according to rfc 4880 bis 04 *and obfuscate the size of the symmetric encryption key* (see below for more details)
- 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 keyRegarding 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.
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:
-----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 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)