cipherText = aes-ctr(key, iv+1, (plainText)); & authTag= aes-ctr(key, iv, aes-ecb(key, sha-1(cipherText+authData+key+iv))); is it secure?

Question

Proposed Cipher suite (using aes-ecb):

cipherText = aes-ctr(key, ++iv, (plainText)); & authTag= aes-ctr(key, iv, aes-ecb(key, sha-1(cipherText+authData+key+iv)));

---

Security targets:

1. Encryption of the plainText.
2. Integrity of the cipherText & authData.
3. Authenticity of the cipherText & authData.

---

Used components and reason behind using them:

1. sha-1: For checking integrity of the cipherText & authData.
2. aes-ctr: Used for encryption of the plaintext & aes-ecb(sha1).
3. aes-ctr(aes-ecb(sha-1(***cipherText+authData+key+iv)))*:
   • sha-1 is encrypted with aes-ecb to create hurdle in finding out the key stream used by aes-ctr to encrypt `aes-ecb(sha1). Because even if the attacker get to know sha-1, sha-1's encrypted value could not be guessed.
   • sha-1 is used to encrypt the cipherText & authData along with key + iv: So that we can check integrity of cipherText & authData. key + iv is added to create hurdle for attackers to guess value of sha-1.

---

The challenge/question is to find out security level of this cipher suite.

This question is for passionate & elite cryptanalysts, which would help them or other (from their answers), to understand how use of a broken hash function determines overall security?

I hope that some people would find this as a interesting challenge.

---

*Please note that value of sha-1 is truncated to block size.(i.e, 128 bits)

This method is improved version derived from the method proposed in this question.

Answer 1

I was just trying to build a secure enough cipher suite using aes and a sha-1 function

Your safest bet for this is to use AES-CTR and apply HMAC-SHA1 on the ciphertext. This should still be secure (because HMAC doesn't rely on collision resistance and mitigates length extensions). I.e. $$(c,\tau)=((\text{IV},\operatorname{AES-CTR}_{k,\text{IV}}(m)),\operatorname{HMAC-SHA1}_k(c))$$

Proposed Cipher suite (using aes-ecb):

I'm reasonably confident that this hits at least around a 64-bit security level, but the construction is too complex and too non-standard for me to trust my ad-hoc evaluation. Of course 64-bit is much less than you can get from more standard modes like GCM, CCM and EAX which should be preferred.

---

Additional nodes on sub-constructions:

• The encryption of the hash yields in itself a blocksize/2-bit secure MAC. The CTR application could mitigate structural attacks on SHA1 here.
• $H(m\| k)$ (and variants) suffers from collision attacks. This may be (partially) mitigated by the subsequent encryption operations.
• $H(k\| m)$ (and variants) suffers from length-extension attacks. This may be (partially) mitigated by the subsequent encryption operations.

Final conclusion:
Do not use this for applications where security actually matters!
When it doesn't matter and attackers will only invest a low amount of effort this has a chance of providing adequate security.