GPG fails to decrypt a message that was encrypted using
- an ECC key with Curve 25519
- AES-128 symmetric encryption
- padded to 40 bytes
The error message is strongly misleading (at least was misleading us for a while):
gpg: public key decryption failed: Wrong secret key used gpg: decryption failed: No secret key
We would like to pad to 40 as allowed by RFC 6637, section 8:
The input to the key wrapping method is the value "m" derived from
the session key, as described in Section 5.1 of [RFC4880], "Public-
Key Encrypted Session Key Packets (Tag 1)", except that the PKCS #1.5
(Public-Key Cryptography Standards version 1.5) padding step is
omitted. The result is padded using the method described in [PKCS5]
to the 8-byte granularity. For example, the following AES-256
session key, in which 32 octets are denoted from k0 to k31, is
composed to form the following 40 octet sequence:
09 k0 k1 ... k31 c0 c1 05 05 05 05 05
The octets c0 and c1 above denote the checksum. 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.Obviously, if the sender MAY pad up to a total of 40 bytes, this means that the recipient MUST take this into account and process such a padding properly. In addition to that, a padding of up to 40 bytes should be possible so the encrypted payload would not broadcast any information about the key size. That is why we consider this a bug in GnuPG.
Let me know if you want me to provide any example data.
Note that it seems this problem has been describe before in https://dev.gnupg.org/T3763 but it seems it wasn't rated a bug under the given circumstances which it should be. Indeed, I must admit that I don't really understand the conclusions made in the other issue as being "a bug in the spec not GnuPG".
Edit:
I should add that GnuPG pads AES-128 to only 24 bytes which, in the light of the above said about not making the key size obvious, IMO should be changed as well.