# How is it possible that these two encryption functions yield the same result?

I opened this post in stackoverflow some time ago where I explained a problem I had about not finding a way that would allow to successfully get the result of a string encrypted with a "aes-256-cbc-hmac-sha256" algorithm.

As seen in the answer, the encrypted string is exactly the same as it had been encrypted with just a "aes-256-cbc" algorithm, I could get advantage of that to successfully do a proper decryption.

Out of curiosity, I'd like to know how something like that is possible. I don't know much about criptography, but, on general terms, I know how all the functions involved in the algorithm work... And, by no means, I see that they could offer the same result, as it happens.

Why are these two different functions yielding exactly the same result?

This is a problem created by the library. Either the HMAC algorithm is skipped entirely, or - more likely - the HMAC authentication tag is generated and then forgotten. The reason is likely the spotty to non-existent handing of authenticated ciphers in the OpenSSL command line and (likely) higher-level functions. The string is recognized by the cipher classes, but the authentication tag output is simply ignored.

The output is 64 Base64 characters without padding chars, corresponding to a $$(64 / 4) * 3 = 48$$ ciphertext in binary. The plaintext is 43 characters/bytes. There is no way that the ciphertext includes the authentication tag of 32 bytes (256 bits, the output size of SHA-256). No, the plaintext is just padded with an additional 5 bytes using PKCS#7 compatible padding and then encrypted... and that's it.

So sorry, no crypto magic happening here, just a bad implementation of a cryptographic library. To any OpenSSL devs out there: this should not be that hard to fix, right? Just whitelist the strings that you have tested, please.

• Just wondering, does anybody put tickets after seeing these kinds of problems. Aug 22, 2020 at 20:32
• Thinking about it a bit more, it could be the wrapper library as well. Still, not very WYCIWYG. Aug 24, 2020 at 20:09