Context: I need to calculate MAC for a collection of files just for future integrity and authentication verification.

This is the conceptual order of steps:

  • Derive a 64 bytes key from user input password, using PBKDF2 (with sha512) with 10k iterations and fixed salt.
  • Then, use this derived key to calculate the MAC using HMAC+BLAKE2b(512) and store the output for possible future verification.

PBKDF2 is used instead of HKDF because I can't ensure that the input will have enough entropy.

The key derivation step happens once (on app initialization) and later used multiple times to calculate MAC of arbitrary number of files. Generating an random IV is not possible because I don't want (as far as possible) generate a derived key for every file. Having duplicated MAC digests for duplicated files it is not an issue.

Question: For that purpose, are there some security implications having that salt as a fixed byte string?

Answer: As @SEJPM pointed me, the general security model of MAC algorithms assumes that the keys will be reused for calculate arbitrary number of MAC's, so this scheme should be secure.

  • 1
    $\begingroup$ Did you know that Blake2 offers a built-in MAC and there's no need for HMAC then? $\endgroup$
    – SEJPM
    Apr 18, 2016 at 20:06
  • $\begingroup$ I'm not sure if this answers your question: But the general security model for MACs assumes to have access to an arbitray number of MAC'ed message and he shall not be able to forge one himself afterwards, so key-reuse with MAC should be fine. $\endgroup$
    – SEJPM
    Apr 18, 2016 at 20:07
  • $\begingroup$ @SEJPM Thanks, yes, this answers my question. And, yes, I'm aware that BLAKE2b comes with own MAC, but I don't know what is the difference? Any advantages over HMAC+BLAKE2b? $\endgroup$ Apr 19, 2016 at 5:53
  • $\begingroup$ @AndreyAntukh keyed mac is faster and does not require the HMAC wrapper class, so less potential code $\endgroup$ Apr 19, 2016 at 10:12
  • $\begingroup$ @RichieFrame Thanks! I will change the HMAC construction into keyed BLAKE2b. $\endgroup$ Apr 19, 2016 at 17:29

1 Answer 1


For that purpose, are there some security implications having that salt as a fixed byte string?

The key re-use is fine here, because the standard model for MACs allows the attacker to request an arbitrary (polynomially bounded) amount of authenticated messages while still not being able to forge new MACs.

As a bonus, you may want to consider using the built-in MAC mode for Blake2, because it reduces code complexity and improves speed while providing a comparable security level (thanks to Richie here)

  • $\begingroup$ I've written this answer so we can get this question rid off our list of unanswered questions. $\endgroup$
    – SEJPM
    Apr 19, 2016 at 19:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.