The OpenSSL AEAD primitives with the allowed one-byte tag are also exposed in many programming languages (Ruby, PHP, NodeJS, Erlang/Elixir, Rust) and those don't set a secure default tag length for decryption. Instead, they use whatever the length of the provided tag is... At least, NodeJS will force a secure default on the next major release. It's "nice" to see this footgun has hit OpenSSL itself (and other libs)...
Note that aside from the possible forgery with accepted one-byte tags, this gives an attacker everything needed to get a nonce reuse (and everything that goes with it). Basically, if you've patched the one-byte bug (that could have been exploited) without changing your encryption keys, you're still in trouble...
RFC 6476, which specifies Authenticated-Enveloped-Data used with standard MACs, gets this right, it authenticates the ContentEncryptionAlgorithmIdentifier data alongside the enveloped data so that an attacker can't manipulate the crypto parameters, and uses the full-sized MAC and nothing else:
The EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier must be
protected alongside the encrypted content; otherwise, an attacker
could manipulate the encrypted data indirectly by manipulating the
encryption algorithm parameters
This is very much the exception though, extreme examples being RSA-PSS and RSA-OAEP which make every single (completely unnecessary) parameter for the algorithm an unauthenticated, attacker-controlled attribute so that it's possible to manipulate the processing arbitrarily in order to exploit weaknesses in implementations.
>it authenticates the ContentEncryptionAlgorithmIdentifier data alongside the enveloped data so that an attacker can't manipulate the crypto parameters, and uses the full-sized MAC and nothing else:
I don't see how that's a valid vulnerability, it seems like an airtight-hatchway problem: If you're encrypting, or in this case decrypting, with an attacker-controlled key then all bets are off no matter what you do. In the case of CMS, why would someone decrypting (say) an email, so CMS in S/MIME form, be using an attacker-controlled key? In the linked case it was a (giant) bug in the way AWS' KMS worked, not anything to do with the crypto.
The OpenSSL AEAD primitives with the allowed one-byte tag are also exposed in many programming languages (Ruby, PHP, NodeJS, Erlang/Elixir, Rust) and those don't set a secure default tag length for decryption. Instead, they use whatever the length of the provided tag is... At least, NodeJS will force a secure default on the next major release. It's "nice" to see this footgun has hit OpenSSL itself (and other libs)...
I wrote a blog post on the topic if you're curious: https://sideni.xyz/posts/exploiting_openssl_api/
Note that aside from the possible forgery with accepted one-byte tags, this gives an attacker everything needed to get a nonce reuse (and everything that goes with it). Basically, if you've patched the one-byte bug (that could have been exploited) without changing your encryption keys, you're still in trouble...
RFC 6476, which specifies Authenticated-Enveloped-Data used with standard MACs, gets this right, it authenticates the ContentEncryptionAlgorithmIdentifier data alongside the enveloped data so that an attacker can't manipulate the crypto parameters, and uses the full-sized MAC and nothing else:
The EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier must be
protected alongside the encrypted content; otherwise, an attacker
could manipulate the encrypted data indirectly by manipulating the
encryption algorithm parameters
This is very much the exception though, extreme examples being RSA-PSS and RSA-OAEP which make every single (completely unnecessary) parameter for the algorithm an unauthenticated, attacker-controlled attribute so that it's possible to manipulate the processing arbitrarily in order to exploit weaknesses in implementations.
>it authenticates the ContentEncryptionAlgorithmIdentifier data alongside the enveloped data so that an attacker can't manipulate the crypto parameters, and uses the full-sized MAC and nothing else:
This sounds wrong. We discussed why here: https://blog.calif.io/i/202473094/even-keyid-ciphertext-can-go-wrong.
I don't see how that's a valid vulnerability, it seems like an airtight-hatchway problem: If you're encrypting, or in this case decrypting, with an attacker-controlled key then all bets are off no matter what you do. In the case of CMS, why would someone decrypting (say) an email, so CMS in S/MIME form, be using an attacker-controlled key? In the linked case it was a (giant) bug in the way AWS' KMS worked, not anything to do with the crypto.