Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Is it a weakness to use a single shared secret for protecting messages using a Encrypt-then-MAC scheme?

Assuming a system is using AES-256-CBC and a SHA1-HMAC and the same secret key for both operations. Upon intercepting one of these messages and attacker could brute force this secret key by trying to solve the HMAC or by successfully decrypting the first block of the ciphertext.

Performing a decryption on a single block of AES-256 should be a lighter operation than performing a SHA1-HMAC on a potentially large message. Therefore AES-256 is ideal for a massively parallel brute-force attack and the use of the SHA1-HMAC doesn't hurt the system.

Is this approach sound, or is there an attack that has not been taken into consideration?

share|improve this question

2 Answers 2

Clearly, if you had been using AES-256-CBC for confidentiality and AES-256-CBC-MAC for authentication, it would not be secure to use the same key for both confidentiality and authentication. Hence, using the same key for confidentiality and authentication cannot generally be secure; you need additional premises to arrive at that conclusion. In your case it would be that the algorithms are "too different" for any related key attack to be feasible. This assumption is usually considered to be a bit too shaky for safety, which is why the established practice, in cases similar to yours when you start with a single shared secret key, is to derive different keys for confidentiality and authentication from that shared secret. If you do that the security of your construct will rest on the assumption that the KDF you use is a PRF and not on the assumed difference of the confidentiality algorithm and MAC algorithm.

share|improve this answer

Brute forcing the key would hardly be an issue: 128-bit keys (assuming they have been properly generated) are in a space which is way too large to be successfully explored by brute force; and 256-bit keys (the kind you put in AES-256) are even more larger. Whether AES is "faster" than HMAC or not does not make such brute force more feasible: even if each key try was as simple as a simple bit flip, 128-bit keys would still be too large for any practical attacker.

Said otherwise, if "massively parallel brute-force attacks" are relevant, then your key is not properly generated (bad PRNG, bad key exchange algorithm, bad password-to-key derivation...), and that is your problem, not the reuse of the same key for both AES and HMAC. If you reach the point where the relative slowness of AES vs HMAC/SHA-1 is how you envision protection, then things have gone sour upstream.


Potential problems with using the same key for encryption and MAC would be structural; @Henrick's example is CBC-MAC, which is indeed identical to CBC encryption, except that you only use the last encrypted block as MAC. CBC-MAC works fine as long as you do not give to the attacker access to pairs (p,c): p is a plaintext block, c is the corresponding ciphertext block, for the key k which you use for CBC-MAC. But if you use the same key k for encrypting the data, then you are giving to the attacker a lot of such blocks.

With HMAC vs AES, no such interference is known. The general feeling of cryptographers is that AES and SHA-1 (or SHA-256) are "sufficiently different" that there should be no practical issue with using the same key for AES and HMAC/SHA-1. However, simply defining that "difference" with any kind of scientific rigor would be hard, and it is not a much explored security feature. So that's one of these constructions which can be qualified as "no urgency to fix it, but don't do it if you can avoid it". A much "safer" way (in the sense of: "we know what characteristics of the involved algorithms we are exercising") is to take your master key K, and derive from it, with a good one-way Key-Derivation Function, a sub-key for encryption and another sub-key for the MAC. This can be as simple as applying SHA-256 on K and splitting the 256-bit result into two 128-bit keys.

There are some MAC and encryption algorithms which intrinsically support sharing the same key. This is exactly what happens in GCM.

share|improve this answer
    
I recommend HKDF as the KDF when you want to derive multiple keys (for example encryption and MAC) from a single high-entropy master key(not a password). –  CodesInChaos Apr 23 '13 at 11:26
    
@Thomas: I don't have a security.stackexchange account, and I think (security.stackexchange.com/questions/34821/…) you're highly overestimating the cost of such a supercomputer. (See tau.ac.il/~tromer/twirl) –  Ricky Demer Apr 25 '13 at 18:03
    
@RickyDemer: TWIRL is only for the sieving step. The page claims that the sieving step is the most expensive half of factorization, which, as far as I know, is true for 512-bit integers, but quite false for 1024-bit integers. There is a paper which estimates the cost of designing then building the machine for the linear algebra step, which claims to be "under 2 millions of dollars" which I frankly don't really believe. –  Thomas Pornin Apr 25 '13 at 18:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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