https://www.reddit.com/r/crypto/comments/fnku50/nonce_reuse_vs_iv_reuse/
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.