In the AEAD scheme described in https://www.rfc-editor.org/rfc/rfc7539#section-2.8.1, the aad and cyphertext are padded to be a multiple of 16 bytes in length. Why is this necessary? Does it provide any advantage over simply not padding the data?
$\begingroup$
$\endgroup$
2
-
3$\begingroup$ It is necessary because the block size is 16-byte. You have to pad to the block size in order to process. In canonical verification, you don't need to remove the pad, it is one way. $\endgroup$– kelalakaCommented Jan 13, 2019 at 10:47
-
$\begingroup$ @kelalaka I was under the impression that the ChaCha20 block size was 64 bytes when implemented as such, and that normally, it's a stream cipher, not a block cipher, so it shouldn't need padding? $\endgroup$– Lev KnoblockCommented Jan 13, 2019 at 14:45
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
It is the authentication - which uses Poly-1305 that needs the padding; the padding does not expand the ciphertext. The Poly-1305 operates on blocks of 128 bits. The padding is applied so that Poly-1305 can always process full blocks of input. Afterwards the the padding is discarded - it is not kept with the ciphertext.
During verification the padding is reapplied, otherwise the calculated authentication tag would not be identical with the one that was kept with / is part of the ciphertext.
In the case of Poly1305 it seems that the additional authenticated data (AAD or just AD) is padded separately, instead of concatenating the two and padding the combination of the two. This makes it possible to calculate the AAD component independently of the ciphertext component of the authentication tag, as DannyNiu's answer indicates.
Note that in practice a single block input buffer will be used within the implementation of the Poly-1305 function. Implementations will pad the buffer instead of the actual input. Discarding consists of clearing the buffer - if it is cleared at all, it can also ignore the data in it.
answered Feb 13, 2019 at 13:28
$\begingroup$
$\endgroup$
2
One advantage it provides, is that you can calculate the authenticator for associated data AFTER you've calculated authenticator for ciphertext, which may not be fully available at the time of calculation.
Although canonically, you should have all your data ready at the invocation of encryption API, ChaCha20-Poly1305 is designed as a "high throughput" AEAD mode just like GCM, which intend to make such computation possible.
-
$\begingroup$ From what I can tell, the example code provided in the paper does not use separate authenticators for the cyphertext and authenticated data. $\endgroup$ Commented Jan 13, 2019 at 15:51
-
$\begingroup$ You're right. It's a little used feature of universal hashing, and it doesn't worth being treated specially in the specification. $\endgroup$– DannyNiuCommented Jan 14, 2019 at 0:46