Nonce reuse with the same key is catastrophic to security. The same premise holds for initialization vectors. If the key is rekeyed, then nonce or IV reuse is not catastrophic. It's the nonce/IV+key pair that you need to pay attention to.

In the preceding post, a user supports my belief that a group shared symmetric key that doesn't rotate may be used to support a large number of encrypted group-shared messages, which is to say in the following formulae that a single, static instance of $SymmetricKey$ may be securely used, so long as each and every instance of $nonce$ (unless denoted $nonce_n$, to denote a bitwise equivalence across the subscript equivalent appearances) is a unique, randomly generated 128 bit value (and specifically using the counter in $chacha$ for 64 bits of it, and the $64$ bit nonce parameter for the other 64 bits of it). Also, generating a 128 bit MAC with the $HMAC()$ function, as can be done securely with $HMAC-MD5$ according to:

Is HMAC-MD5 considered secure for authenticating encrypted data?

Yes, there are currently no known attacks on HMAC-MD5.

So, a message,

$M_n$ = $ChaCha(SymmetricKey, Nonce)$

supports an $n$ value of securely encrypted messages equivalent to the nonce space (minus one, if starting at zero). With ChaCha's $counter$ + $nonce$ space being, together, 2^128, that means $340,282,366,920,938,463,463,374,607,431,768,211,456$ messages can be encrypted with the single, static symmetric key. However, it must be noted that collisions will actually almost certainly start breaking the security of the system prior to the theoretical maximum number of securely encrypted messages, it's just that practical security will be maintained for an enormous volume of messages prior to collisions being likely ($170,141,183,460,469,231,731,687,303,715,884,105,728$ messages generated before a 50% probability of a 128 bit nonce collision being randomly generated, I think). Each $M_n$ will also have its own -- presumably enormous -- maximum byte count.

Is it secure to use the same shared symmetric key, from the example as previously described, for unlinkable contact signaling, by inputting it into an HMAC function (as the symmetric key, with the other argument, then, a public nonce)? By contact signaling I mean using (with |, as often it does, denoting concatenation, rather than bitwise or).

$H_n$ = $HMAC(SymmetricKey, Nonce_n)$
$ContactSignal$ = $H_n$ | $Nonce_n$

Such that messages encrypted by, say,

$chacha(SymmetricKey, Nonce)$

can be tested for intent to be processed by a group member who has the symmetric key, by the group member calculating:

$HMAC(SymmetricKey, Nonce)$

after receiving the public $Nonce_n$, and as a membership test for the secret SymmetricKey on the unlinkable contact signal, taking

$H_n$ = $HMAC(SymmetricKey, Nonce_n)$

and computing,

${constComp}(H_n, HMAC(SymmetricKey, Nonce_n))$

in order to determine from a smaller index downloaded by everyone whether the associated (potentially much larger) message was intended for members of one's group (as can be reported by the constant time string comparison function $constComp()$ returning 1 to denote "true" in response to the membership question regarding the group shared secret symmetric key).

The potential issue I can see is from using a single shared symmetric key in both HMAC and a symmetric mode of operation with a nonce with a symmetric algorithm like chacha. The thing to keep in mind is that it is an atypical use of HMAC where messages -- potentially being many kilobytes or more -- are labeled as being for members of a group, with various unlinkability and other security guarantees being met. So, with the HMAC as used for unlinkable contact signaling, the primary goal is to allow members of the group to signal to each other when a larger message, by its smaller cryptographically secure index, is identifiable to group members as intended for them, without letting an attacker outside of the group link such messages together as belonging to a single group.


1 Answer 1


Is it secure to use the same shared symmetric key, used for encryption with the arbitrary generation of a new nonce per message, for unlinkable contact signaling?

Yes, as long as adversaries do not manage to get hold on the key. That condition implies

  1. None of the multiple holders of the key in the proposed system are adversaries.
  2. Each is competent at keeping the key confidential, which is hard.
  3. Each is competent at avoiding unauthorized use of the key, which is harder.

Point 1 is a good reason to use public-key cryptography. Point 2 is a good reason to use Smart Cards or HSMs, and to rotate keys. Point 3 is a good reason to worry about the sad state of software security.

That shall not be construed as condoning:

  • Use of HMAC-MD5 in a new design. That's a no-no, even though there's no known attack, and there remains some level of security argument (because a security proof of HMAC relies on a weaker property than collision-resistance of the hash).
  • The $2^{128}$ number of messages if HMAC is made with a 128-bit hash, much less a broken one like MD5 is. For a $h$-bit hash, I would think twice before approaching the design limit of the hash, which is $2^{h/2}$ messages. If we use HMAC-SHA-256 truncated to 16 bytes, I'd state we are OK to $2^{120}$ messages save for attacks on implementations, and everyone would be more than happy with that.
  • The reuse of the same key in Chacha20 and HMAC in a new design. Not that I know a concrete weakness, but using the same key for two algorithms implies that any side-channel attack against the implementation of either construct breaks the other. Perhaps worse, knowing that an audit has concluded that each implementation is safe, it can not be rationally concluded that the combination of the two with the same key is: perhaps the information extracted from the two attacks can be combined. That's why we have Key Derivation Functions: starting from a single key, we can derive two others, one for each algorithm.
  • An analysis of the full security of the protocol.
  • $\begingroup$ I substantially clarified my question, if you don't mind looking it over once more. $\endgroup$
    – cyborg
    Commented Jun 4, 2020 at 6:28
  • $\begingroup$ I totally agree -- I just had trouble getting all of the parameters to match up, yet wanted to make sure it's at least secure. In an actual system I would use keccak and not even use the $HMAC()$ function -- just $H(SymmetricKey | Nonce)$. I'd also probably use counter mode on $AES()$ -- do you know if $aes-ctr$ is secure with key reuse, provided $nonce$ is random and not re-used, like $ChaCha-ctr$ is? $\endgroup$
    – cyborg
    Commented Jun 4, 2020 at 7:11

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.