Change Details

GPG fails to decrypt a message that was encrypted using - an EdDSA key - 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".

GPG fails to decrypt a message that was encrypted using - an EdDSA key - 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.

GPG fails to decrypt a message that was encrypted using - an EdDSA key - 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.