-4
$\begingroup$

What if we encrypt sha-1 hash of the plain text, along with the plain text using AES-256 in CTR mode?

How much future proof the above method would be in comparison to AES-GCM or any other method where auth tag is made public?

Ultimately the question comes down to which has higher chance of getting cracked in future? AES-256 vs HASH Algorithms.

If AES_256_ENCRYPT_CTR(key, sha-1(plainText)+plainText) is more secure, why in TLS 1.3 AES-GCM is used?

The improved version of this protocol presented in this question.

Improve this question
$\endgroup$
12
  • $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$
    – SEJPM
    Dec 12, 2018 at 18:46
  • $\begingroup$ @MaartenBodewes the posted challenge is bunk, I did not got the meaning of bunk. Would you please explain? $\endgroup$
    – Nayan Karan
    Dec 12, 2018 at 19:59
  • $\begingroup$ @MaartenBodewes Got it. She is right. $\endgroup$
    – Nayan Karan
    Dec 12, 2018 at 20:27
  • $\begingroup$ @MaartenBodewes Then we can also attack AES-GCM like this. GCM:WIKIPEDIA $\endgroup$
    – Nayan Karan
    Dec 12, 2018 at 21:08
  • 3
    $\begingroup$ No, you're forgetting the H component. As indicated, there is a security proof for GCM. Stop attacking GCM until you understand it. And stop stating things as you do; ask "but then why is GCM secure" in a different question, as already indicated. For goodness sake, learn to ask and listen. $\endgroup$
    – Maarten Bodewes ♦
    Dec 12, 2018 at 21:36

2 Answers 2

Reset to default
9
$\begingroup$

What if we encrypt sha-1 hash of the plain text, along with the plain text using AES-256 in CTR mode?

This is trivially breakable.

The "MAC" $\operatorname{sha1}(\text{plaintext})$ requires no secret material to evaluate, and so the adversary can forge tags for arbitrary messages.

We will assume that an adversary will at least have the ability to perform known plaintext attacks, which is a weak attack model that will always apply unless you're encrypting uniformly random strings of data as your plaintext.

The ciphertext consists of $$(\operatorname{sha1}(\text{m}_0) \oplus k_0) || (\text{m}_0 \oplus k_1)$$

The adversary knows $\text{m}_0$ and can recover the key stream bits $k_0, k_1$.

From there, the adversary can evaluate $\operatorname{sha1}(\text{m}')$ and forge a valid ciphertext: $$(\operatorname{sha1}(\text{m}') \oplus k_0) || (\text{m}' \oplus k_1)$$

This attack has negligible cost - in fact, it has less cost than the legitimate encryption operation, as the attacker does not even have to evaluate $\operatorname{AES}$ to acquire the key stream.

How much future proof the above method would be in comparison to AES-GCM or any other method where auth tag is made public?

None, the authentication mechanism is completely broken.

Ultimately the question comes down to which has higher chance of getting cracked in future? AES-256 vs HASH Algorithms.

This is not the case; Just because it uses a hash algorithm does not mean you must break the hash algorithm to break the construction.

Also, SHA1 is already broken anyways. So even if you had to break the hash function to break the authentication mechanism of this scheme, it could still be feasible to do so.

GCM mode uses GHASH, which is not a hash function in the sense of a collision resistant compression function (it is a universal hash family). but it is not AES-256 either. Regarding the authentication portion of GCM and the security of AES, AES is only used to generate a key for GHASH.

If AES_256_ENCRYPT_CTR(sha-1_(plainText), plainText) is more secure, why in TLS 1.3 AES-GCM is used?

It is not secure, let alone more secure.

Even if it were secure: It is not published or standardized, and GCM mode is. "Why doesn't TLS 1.3 use algorithm X that is not published and is not standardized" has a very simple answer.

Improve this answer
$\endgroup$
10
  • $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$
    – SEJPM
    Dec 12, 2018 at 18:50
  • $\begingroup$ @EllaRose If the transfer protocol implements checking of reuse of IV, then newly generated ciphers would be dismissed although it is still vulnerable to modification of generated cipher text at most one time. The attack can be mitigated by making each massage unique. So the constructed cipher text would be: (sha1(m0||k0))⊕k1)||((m0||k0)⊕k2). Because here the attacker would not have knowledge about the keystream k0. $\endgroup$
    – Nayan Karan
    Dec 13, 2018 at 7:51
  • $\begingroup$ @EllaRose If the transfer protocol implements checking of reuse of IV in the proposed ciphertext construction (in question), the chance of getting success of this attack depends upon how many massages of same length does the sender sends. More the number of massages less would be the chance of successful attacks. $\endgroup$
    – Nayan Karan
    Dec 13, 2018 at 8:10
  • $\begingroup$ @NayanKaran That is not a guarantee provided by CTR mode. Suppose you use AES-CTR to encrypt a file on your hard drive, and say it uses the nonce $0$. Then you encrypt a second different file, and that uses the nonce $1$. Refusing to decrypt any cryptogram with a nonce $< 2$ means you cannot decrypt your files on disk. CTR mode does not provide this property by itself, the protocol cannot be guaranteed to do so, and expecting the protocol to be responsible for ensuring integrity is not the right way to design an authenticated mode of operation. $\endgroup$
    – Ella Rose
    Dec 13, 2018 at 15:46
  • $\begingroup$ @EllaRose agree. But the context for which I given my previous comment is for communication protocol like tls. $\endgroup$
    – Nayan Karan
    Dec 13, 2018 at 17:33
5
$\begingroup$

The system proposed with SHA-1 does not have the same level of security as AES-GCM.

@EllaRose's answer demonstrates how a malleable ciphertext may be manipulated. Malleable crypto systems are vulnerable to adaptive chosen cipher text attacks, and malleability is generally not a desirable characteristic. Authenticated encryption systems (such as AES-GCM) are used to prevent malleability: AES-GCM is not malleable; the AES-CTR+SHA-1 system is.

If SHA-1 were replaced with a better hash, whether SHA-256, SHA-512 or SHA-3, it would still be vulnerable to the attack in Ella's answer.

To materially improve it, the plain hash function needs to be replaced with a MAC such as HMAC.  This would give a system that would probably be okay, as long as AES-CTR mode continued to be used; if that was switched to AES-CBC mode, it would be vulnerable to padding oracle attacks.  (This is why the linked question and best practice recommend MAC-ing the cipher text, not the plaintext - i.e., MAC on the outside.)

(Note that HMAC-SHA-1 is still considered secure, despite the weaknesses in SHA-1.)

So to answer the question as stated, AES-GCM is objectively more secure.

If we broaden the question to: AES-CTR+HMAC vs AES-GCM, we might be able to create an answer.

In AES-CTR + HMAC, if AES gets broken but HMAC is not, we could detect a modified cipher text, but we would likely lose confidentiality. If HMAC was broken, but AES not, (hypothetically, since there are security proofs) we return to plain AES-CTR, which is malleable.

So, in other words: in a system that uses two primitives to build a crypto system, if either primitive fails the system fails.

In AES-GCM, if the AES part is broken, then both confidentiality and authentication (integrity) are lost; if the GHASH is broken, authentication fails. And if authentication fails, we are back to AES-CTR, which is malleable.

How much future proof the above method would be in comparison to AES-GCM or any other method where auth tag is made public?

If the GHASH in AES-GCM is broken, it will be big news. You will know about it. And hashes are normally broken gradually, so there should be time to prepare. The same is true of a hybrid AES-CTR+HMAC mode, except you would need to remember that you are using HMAC with the AES encryption.

And in building a hybrid crypto system, you have to ensure you put the correct primitives together in the correct order.

Ultimately the question comes down to which has higher chance of getting cracked in future? AES-256 vs HASH Algorithms.

Actually, in a constructed system like AES-CTR+HMAC, if either of the primitives fails the overall system fails. (Otherwise there would have been no use in having used the part that failed.)

If AES_256_ENCRYPT_CTR(key, sha-1(plainText)+plainText) is more secure, why in TLS 1.3 AES-GCM is used?

Well, it's not more secure. But for the hybrid constructions that are, using a single mode to provide authenticated encryption is safer, because there's less for the users of the cryptography (i.e. the TLS designers and implementers) to get wrong.

(And if weaknesses in AES-GCM are found, we will get a drop-in replacement; if problems are found in either AES-CTR or HMAC, we have to figure out how to circumvent those issues where the two are used together.)

Improve this answer
$\endgroup$
1
  • $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$
    – SEJPM
    Dec 12, 2018 at 18:52

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