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 &amp; 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 &amp; 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 &amp; 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.