Concerns about use of MAC in my specification Here is the pseudocode for a routine I am designing:

encrypt(password, string):
  nonce1 := generate_random_nonce()
  nonce2 := generate_random_nonce()
  key := derive_key(nonce1, password)
  encrypted := cipher(nonce2, key, string)
  return (nonce1 || nonce2 || encrypted || mac(key, encrypted))


I realized that an attacker with the encrypted text might be able to brute force the key, since a mac is not slow to compute (like key derivation).

I thought about using a third nonce for the mac key instead of the ciphertext key, but the mac key should be secret so this isn't an option.


  How should I correctly use a MAC to authenticate the ciphertext (and thus plaintext) in this situation?
The pseudocode has a serious issue: changing the value of nonce2 in an otherwise valid cryptogram is not detected, and results in invalid deciphered plaintext. That would be fixed by

encrypt(password, string):
  nonce1 := generate_random_nonce()
  nonce2 := generate_random_nonce()
  key := derive_key(nonce1, password)
  encrypted := nonce2 || cipher(nonce2, key, string)
  return (nonce1 || encrypted || mac(key, encrypted))


but leaves two lesser issues:


The same key is used for cipher and mac; when not done properly, that can be a bad thing, and is a known recipe for disaster, e.g. if both cipher and mac used the key as an AES key for CBC encryption and CBC MAC, rather than using a carefully thought authenticated encryption mode like AES-GCM-SIV. With cipher chacha, and mac blake2b which is based on the chacha core, we should at least worry (even though I see no attack right now), and perhaps use something like proposed by Maarten Bodewes in that other answer.
We are told that derive_key is pkcs5_pbkdf2; this does key stretching, which is indispensable for any password; but PBKDF2 does not leverage the RAM and possibly multiple CPUs available at no cost to legitimate users, hence is orders of magnitude less safe against serious adversaries (using ASICs or FPGAs for password searching) than something state-of-the-art like scrypt.