0
$\begingroup$

This might sound like a naive question (And maybe it is (It's an early morning Saturday thought, so there might be some clarity of thought missing)).

Suppose we havea protocol that sends messages as follows: Encrypt(<Message><Padding*>Hash(<Message>))

*Padding is optional, but if present pads out the message to the nearest 16 bytes either with NULL or with Random (happy to consider either option). Padding is not included in the Hash.

Does the presence of the hash compromise the security of the exchange? I tend to think that sending any redundancy in a predicatable format tends to open attack vectors - but am I overthinking this one?

NB: I assume the question is Algorithm independent, but if it's not he encryption as AES and the Hash ash SHA256

NB2: I'm interested whether it reduces security at all - I get that "reducing security" and making something feasaibly breakable are 2 different things. So I'm ok with an answer of "theoretically it makes it marginally less secure, but it's still good enough for all intents and purposes"....

$\endgroup$
2

1 Answer 1

0
$\begingroup$

Does the presence of the hash compromise the security of the exchange? I tend to think that sending any redundancy in a predictable format tends to open attack vectors - but am I overthinking this one?

If the IV may be repeated during encryption then the hash can be used to give more information to an adversary when a chosen plaintext attack is performed. I'd be mainly worried about plaintext oracles. If you use a mode that requires padding then there already is an attack vector called padding oracles, which is a type of plaintext oracles. Other such oracles probably exist within the plaintext message itself.

However, if the encryption scheme and implementation is secure then in principle any message should be equally well protected. So it really depends on the encryption function and systems used.


AES is a block cipher. It can only permute blocks of plaintext into a block of ciphertext. The block size is 16 bytes. It is not a generic cipher, you need a mode of operation to turn it into one. So just specifying "AES" is not enough.

The hash is not a keyed hash. You'll get about the same attack vectors whichever hash is used as it doesn't really provide all that much security if the cipher is insecure.


If we want to provide semantic transport security then using an authenticated cipher such as GCM should be preferred.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.