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

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?

• Password based KDFs (PBKDFs) need a salt. key based KDFs (KBKDFs) don't generally need a salt, but rather something to distinguish the derived keys (like a string "MAC-KEY" and "ENC-KEY"). – SEJPM Mar 23 '16 at 13:39
• KBKDFs is something I didn't hear before, but it still require something input to generate the derived key and it need to append to the message in plaintext right? – Hartman Mar 23 '16 at 14:25

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.

• Thank you for the answer, but I still don't understand how KBKDF works even I read the whole RFC 5869. Could you explain more about how it works? – Hartman Mar 23 '16 at 17:15
• A KDF basically uses a Pseudo Random Function (usually a MAC) to derive one or more session keys from a given secret. It does so by including information such as a label ("IV" for instance) and the secret in the PRF calculation. That way the resulting keys cannot be used to either calculate the input / master secret nor each other. The simplest form of KDF is simply H(secret | counter) (called KDF1 or KDF2) where the counter is e.g. a 4 byte value acting as the label. This is pretty secure even if the hash H is officially not a PRF. HKDF has a better security "proof". – Maarten Bodewes Mar 23 '16 at 17:21
• I know how a KDF generally works. But after I read the RFC 5869, I'm don't understand about the salt part. The paper said if the salt is not provided, it is set to a string of HashLen zeros. What does it means and how to preform? And RFC 5869 don't have secton 3.5. – Hartman Mar 23 '16 at 17:26
• Sorry, typo, should have read 3.1 of course. Unless you implement it yourself it simply means you don't need to supply a salt. If you do implement it it means you need to put bytes with value 00 hex at the location where you would otherwise supply the salt. – Maarten Bodewes Mar 23 '16 at 17:28
• Anyway, I got a running code at (github.com/Sc00bz/ECSRP/blob/master/hkdf.php). Although I don't know is it a correct HKDF follows RFC 5869, I will use it frist. – Hartman Mar 23 '16 at 18:15