1
$\begingroup$

I just went through https://tools.ietf.org/html/rfc7539#section-2.6 (sections 2.5 and 2.6). There it is described how to generate one-time Poly1305 keys using the ChaCha20 block function (for this a 96-bit nonce is required).

I am asking myself how this is "better" or "more secure" in comparison to just use the key that is used for the ChaCha20 block function.

$\endgroup$
  • $\begingroup$ Better as in not reusing the same key for different purpose(s)? $\endgroup$ – DannyNiu Feb 6 at 12:27
  • $\begingroup$ @DannyNiu But if the key is always generated freshly during key establishment (e.g. using an HKDF with a random nonce/salt), then we dont need to extra use the KeyGen function ChaCha20, right? $\endgroup$ – user35869 Feb 6 at 14:01
  • $\begingroup$ That same ChaCha20 key would be used to encrypt the message, right? So it would be used for Poly1305 based authentication and encryption, hence dual purpose? $\endgroup$ – Maarten Bodewes Feb 6 at 20:51
  • 1
    $\begingroup$ @MaartenBodewes no, I am only interested in the MAC generation using Poly1305 with a key that is always been freshly generated for each execution of the MAC function. The key is derived using an HKDF with a shared DH key and a random value for each execution (e.g. a nonce). I am asking myself whether it is possible (advisable) to use the output of the HKDF directly or to use it as an input for the ChaCha20 keygen to get a onetime poly1305 key First and use this as the Poly1305 MAC key. $\endgroup$ – user35869 Feb 6 at 20:56
  • 1
    $\begingroup$ Probably best to integrate above comment into the question; it is vital information required (be able to) to answer the question. $\endgroup$ – Maarten Bodewes Feb 6 at 21:19
0
$\begingroup$

You wrote in the comments:

no, I am only interested in the MAC generation using Poly1305 with a key that is always been freshly generated for each execution of the MAC function. The key is derived using an HKDF with a shared DH key and a random value for each execution (e.g. a nonce).

In the same RFC that you mention it is written (quoting Bernstein's paper):

The original article ([Poly1305]) is titled "The Poly1305-AES message-authentication code", and the MAC function there requires a 128-bit AES key, a 128-bit "additional key", and a 128-bit (non- secret) nonce. AES is used there for encrypting the nonce, so as to get a unique (and secret) 128-bit string, but as the paper states, "There is nothing special about AES here. One can replace AES with an arbitrary keyed function from an arbitrary set of nonces to 16-byte strings."

Now you've got HKDF, which is a keyed function, a nonce and an output which can be made 16 bytes. I say: go for it, but don't use the key for anything else, including ChaCha20 encryption or worse, calculating another authentication tag.

Just for reassurance: do please use SHA-256 or better for HKDF. Then it should be just as secure.


Do remember that you're now in unchartered territory. That means using libraries to implement this kind of functionality will be harder, compared - for instance - to just using the AAD of a ChaCha20/Poly1305 cipher to calculate a MAC.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Thanks for your answer! From your answer I understand that it is fine to use the output of the HKDF directly for the generation of the MAC (wolfssl.com/doxygen/…). Is there any security improvement when using the output of the HKDF as in Input for the ChaCha20 KeyGen (wolfssl.com/doxygen/group__ChaCha.html ) and to use the output of the KeyGen as MAC Key? I am asking myself whether it does "worth" to have this intermediate step (which still should cost low ressources). $\endgroup$ – user35869 Feb 7 at 7:25
  • 1
    $\begingroup$ No, HKDF is designed to provide a perfectly valid key, I don't see how ChaCha would be able to improve the key material at all. Then again, with the same key and block size it should not decrease either. $\endgroup$ – Maarten Bodewes Feb 7 at 9:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy