Why is MAC using nonce+message+hash(nonce+message+identifier) not the standard? Given that we know that nonce + message + hash(nonce + message + mac-key) all inside the encryption makes it possible to detect if any bits of the message have been changed by the attacker (in essence converting a malleable cipher into a non-malleable one), why do they still say encrypt then MAC?

Furthermore, doesn't adding the mac-key that is split into pairs like the symmetric cipher authenticate the attacker by proving the rest of the material not subject to attack on the cipher is known (assuming adequate length)?

Of course if we had full asymmetric we'd sign then encrypt but that's not the question being asked.

EDIT: The encryption algorithms I prefer all have the property of not having invalid inputs, in that any ciphertext + any key -> some "plaintext", usually garbage. There cannot exist an attack on the algorithm that would crash the implementation.

EDIT: OK I get the part about HMAC not being hash(a + b) due to most hash functions being unsuitable. I prefer to replace a hash function as unsuitable for any use once it reaches the state of unsuitable for that use but no matter. I don't get the part about why we care if the ciphertext has been altered. The way my stuff is set up it is not faster to MAC before attempting decryption due to rewinding streams.
It has the disadvantages of any MAC-then-encrypt scheme, which I'm quoting from the linked answer below. In addition:


It has the property that you need both a nonce and a hash, so for equivalent security it requires more message space.
The nonce has to be random, so it requires strong random numbers for each message, unlike e.g. AES CTR + HMAC.
Doesn't work if you need deterministic encryption, for some reason.




From the link:


  Does not provide any integrity on the ciphertext, since we have no way of knowing until we decrypt the message whether it was indeed authentic or spoofed.


This means that it may allow some chosen-ciphertext attacks that encrypt-then-MAC would protect from. It also means more time is wasted on incorrect messages, which could e.g. help with denial-of-service attacks.


  If the cipher scheme is malleable it may be possible to alter the message to appear valid and have a valid MAC code. This is a theoretical point, of course, since practically speaking the MAC secret should provide protection.


In your scheme the nonce and ID take the place of the MAC secret, which could be weaker if the encryption is weak and the hash function isn't a strong MAC in that mode, but can't be any stronger. Still theoretical, as long as you choose a strong, unknown nonce.