# Disadvantage of the using a counter within plain text for encrypting with AES256 and authentication?

What if we use a counter within the plain text and then encrypt the plain text with aes 256 to encrypt & authenticate?

For example:

encryptAES(32bit_counter+plain_text_of_96bit); or encryptAES(16bit_counter+plain_text_of_112bit);

This way we do not need to depend on other authentication algorithms and can send about 2^32*96 ~= 48 GB of data using single key.

User can also adjust their counter length & massage length and they can start using a new key by securely exchanging a new key before reaching maximum data transfer limit.

So is there any disadvantages of using this method except reduced data transfer rate?

Is this authentication method better than available cryptographic hash functions? (How much future proof this method is, considering weakness of cryptographic hash functions to collision attacks & length extension attacks? Ref: Comparison of SHA functions).

So is there any disadvantages of using this method except reduced data transfer rate?

Actually, that's a fairly major one; however another one is the possibility of someone injecting random changes undetected.

Suppose an attacker took a ciphertext block, and replaced it with random data. Then, when you decrypt, what you come up with is effectively random data. If the sequence number looks correct (probability $$2^{-32}$$ or $$2^{-16}$$, depending on the tag size), then it'll be accepted. This is a higher probability than many applications will accept. The attacker has no control over what the decryption is, for some attacks, this might be sufficient.

Is this authentication method better than available cryptographic hash functions?

You might turn that question around; how is this method even as good as standard methods (for example, GCM)? It uses more bandwidth, and it has weaker modification detection probability.

• And, it might be also interesting to see that the time of extra encryptions due to the plaintext increase might be slower than an authentication. – kelalaka Dec 10 '18 at 21:18
• @poncho thanks for pointing out the probability of modification detection. I think in some context data transfer rate is not much of a concern, even in some cases we can increase the counter size to 64 bit or even 120 bit. Even though the 2^32 is already fairly enough. The main concern I have is about security? – Nayan Karan Dec 11 '18 at 4:05
• @NayanKaran: "The main concern I have is about security"; well, if we're talking about authentication, then the probability of modification detection is security... – poncho Dec 11 '18 at 4:30
• @poncho Agree. I am thinking about the scenario when gcm or any other hash authorization function is broken in future. Which is more future proof? This authentication method or AES-GCM? – Nayan Karan Dec 11 '18 at 4:36