2
$\begingroup$

I know that for Poly1305-ChaCha20 reusing the key does reveal information about the plaintext. How it is for the Poly1305 MAC algorithm? Revealing information about the plaintext is not a problem at all, as it is available in plaintext anyways.

Question: Does a reuse of the Mac key reveal information about the key itself ?

Source: https://www.rfc-editor.org/rfc/rfc8103

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

Does a reuse of the Mac key reveal information about the key itself ?

One would certainly hope not - Message Authenticate Codes are supposed to be able to be safely used with the same key multiple times.

There is one caveat - the Poly1305 algorithm does need a nonce, which must be different whenever you MAC a message (specifically, you cannot reuse the same (key, nonce) pair to MAC two different messages) - if you do, you do leak enough information for someone to generate a forgery.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Thanks for your answer! According to the specification the MAC algorithm only needs data input and key input, how does this follow your answer ? You are specifically talking about Poly1305 using the ChaCha20 primitive to generate one time keys, right ? $\endgroup$
    – user35869
    Commented Feb 27, 2020 at 16:07
  • $\begingroup$ @Marm: no, I am not talking about ChaCha20 to generate one-time keys; instead, the Poly1305 algorithm does talk a nonce. See section 2 of the RFC for their discussion about how the nonce can be managed; in general, their solutions boil down to "use a fresh key for every message" (not because reusing a key is inherently bad, but because they have difficulty selecting a nonce that has never been used before). However, in other contexts (e.g. TLS), we do use the same keys for multiple messages (records) $\endgroup$
    – poncho
    Commented Feb 27, 2020 at 16:14
  • $\begingroup$ Hi! I just realized that I referred to the wrong rfc, it actually is tools.ietf.org/html/rfc7539 ,that was the reason for the misunderstand I guess. In section 2.5 it is mentioned that poly1305 only takes a payload and a key, that’s it $\endgroup$
    – user35869
    Commented Feb 27, 2020 at 19:56
  • $\begingroup$ @Marm Note that this RFC was obsoleted by RFC 8439, fixing the errata (typos) and adding some considerations about security. $\endgroup$
    – Lukas
    Commented Feb 27, 2020 at 23:48
  • $\begingroup$ @poncho Poly1305 takes a 256-bit key consisting of two 128-bit partitions (r,s). The public nonce n is not part of the core Poly1305 algorithm. However, Poly1305 has strict requirements for s: The pair (r,s) should be unique, and MUST be unpredictable for each invocation (that is why it was originally obtained by encrypting a nonce), while "r" MAY be constant. In Poly1305-AES, s is derived from from a public nonce n and a 128-bit secret key k as s = AES(k,n). This was simply chosen as a practical way to exchange a suitable (secret, unique and unpredictable) s. $\endgroup$
    – Lukas
    Commented Feb 27, 2020 at 23:49

Your Answer

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