The solution of insert MAC in a ciphertext without Authenticated Encryption supported

Question

From Should we MAC-then-encrypt or encrypt-then-MAC?, I understand I should do Encrypt-than-MAC, which the MAC included all the information such as IV and cipher text.

After reading Why choose an authenticated encryption mode instead of a separate MAC?, I know reusing key in Encryption and MAC may trigger unwanted weaknesses. So I got a question, if the language I used don't have authenticated encryption supported, how should I insert a MAC? The author of the answer suggest to use KDF to solve the problem, but KDF need a salt otherwise it won't work. If I place the salt like salt||hmac||IV||ciphertext, since the salt is not protected form the MAC, will it be meaningless to use EtM and/or trigger another weakness?

Articles I have read also:

• Using the same secret key for encryption and authentication in a Encrypt-then-MAC scheme

Answer 1

The salt, if used at all for a Key Based Key Derivation Function (KBKDF), may be send in plaintext. There is generally no reason for salts to be kept secret.

As already noted in the comments by SEJPM, there is no direct need for a salt for a KBKDF. You may however well use it to strengthen the security of the KBKDF. The HKDF RFC (section 3.1) nicely explains the reasons why you might want to supply a salt.

---

Notes:

• You could also derive an IV from the KBKDF if you'd use a salt (using another Info parameter, e.g. "IV") - in that case you don't need to send it with the ciphertext;

• Generally the authentication tag (HMAC value) is placed at the end of the ciphertext, but that doesn't matter with regards to security.