Cryptographically secure random number generation

[Yoda]

Nowhere did I say that the derived cipher would be used for the MAC - it would be far more efficient to return to the underlying hash function and use e.g. HMAC.

That requires to run hash over the whole message twice. One for encryption process for generating pseudo-random chain and one for the HMAC.

In any case, CBC-MAC likewise requires the whole message be processed by itself

Yes, but only for encryption. The MAC is applied to last block only.

Protection against tampering is a property offered by a message authentication code. A MAC can be constructed from a block cipher, but a cipher itself is not a method of preventing tampering.

Of course, the cipher itself is not a method of preventing tampering. But since it is impossible to change the encrypted text so that plain text will get predicted changes, you may control the integrity with methods that are cryptographically insecure, but very fast and become reliable in conjunction with cipher. So, even a plain parity check (XOR of all DWORDs!) combined with encryption does that work.

[Owen]

[

In any case, CBC-MAC likewise requires the whole message be processed by itself

Yes, but only for encryption. The MAC is applied to last block only.

For block cipher operational modes:

• ECB is a joke and insecure (and MACing the last block only would only protect the last block)
• For CBC, modifying one block will only affect that block and the following block (so the MAC would only protect that one block
• For PCBC, two adjacent blocks can be swapped and only those two blocks will be affected
• For CFB, OFB, and CTR modes (which turn the block cipher into a stream cipher), the exact bit flipping the ciphertext results in the same bit being flipped in the plaintext applies

Note that for none of these will your proposed system, nor will a parity check work. The only valid method is a MAC over the whole message.

I do hope you have not been involved in the design of cryptographic systems

[Yoda]

But since it is impossible to change the encrypted text so that plain text will get predicted changes

Of course, it's possible.

Really??? Please tell me how do you plan to forge given block of plaintext without knowing the key.
There are only very few attacks you may target agains CBC encrypted message. Only two attacks possible in case of internal parity check.
1. If you find two identical encrypted blocks you may change them to two any other identical blocks. The result will be four completely garbled blocks of plaintext with the same parity of the whole decrypted message. But the more the size of block, the less probability of encountering identical blocks (for CBC mode!). If you use 128-bit or higher block size, such probability is disappering even if we consider birthday attack.
2. You may insert two identical blocks of ciphertext. In this case two blocks of plaintext will be garbled and two additional blocks of junk will appear. But this attack doesn't work for messages of fixed length.
If you think that these two threats are very dangerous, you may apply CRC to the message before encryption.

For block cipher operational modes

No need to list them. I know them all. And no need to show ECB penguins, I never told that it is reliable. The only thing I said is that it may be suitable for the very specific purposes.

For CBC, modifying one block will only affect that block and the following block (so the MAC would only protect that one block

Modifying one encrypted block will only affect that block and the following block of plaintext on decryption. But modifying one block of plaintext will affect all following encrypted blocks. That's why CBC-MAC works. The security of CBC-MAC for messages of fixed length is proven. After all, MACs are primarily targeted to protect unencrypted or insufficiently strong encrypted messages, such as just XORing with pseudo-random sequences.

I do hope you have not been involved in the design of cryptographic systems

I hope, you too.
I never told that I'm involved in cryptographic projects. Be sure, when I start to develop CryptoAPI, I'll consult with a true pro cryptographers community, not with you.
Let's stop personal jeering at once, OK?