4
$\begingroup$

The AEAD construction for chacha20-poly1305 described in the IETF proposal encodes message lengths into the text that is to be hashed. The newer proposal goes further and pads associated data and plaintext to multiples of 16 bytes.

Can anyone explain what the purpose of that is? The chacha20-poly1305 implementation found in OpenSSH doesn't do anything like that, and as far as I can see, neither does NaCl. Those are still considered secure so I wonder what's going on.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
5
$\begingroup$

The reason for the padding (and re-positioning of the AAD length) in the later draft is to make implementations easier and faster - i.e. not for a security reason.

The rationale for this change was actually documented on the CFRG mailing list by Alyssa Rowan:

Instead of the lengths directly following their ciphertexts:

draft-agl-tls-chacha20poly1305-04:

  AAD | len_AAD | ciphertext | len_ciphertext

this final version of the AEAD pads the Additional Authenticated Data (if any) and ciphertext to a 16-byte block boundary (using between 0-15 zero bytes) and moves the lengths to the end:

draft-nir-cfrg-chacha20-poly1305 (the final AEAD specified here):

  AAD | padding1 | ciphertext | padding2 | len_AAD | len_ciphertext

which is more efficient to implement (block-aligned, and the recipient knows the lengths are at the end, instead of having to jump backwards to find len_AAD). Thanks to Niels Moeller for that idea.

Improve this answer
$\endgroup$
2
  • $\begingroup$ I'm confused by this part: "the recipient knows the lengths are at the end, instead of having to jump backwards to find len_AAD". If I understand correctly, this is describing the input to the MAC, which is something the recipient needs to recreate rather than something they'd ever want to parse. Am I missing something? $\endgroup$
    – Jack O'Connor
    Jun 6 at 23:07
  • $\begingroup$ Yeah, I don't think that makes obvious sense either - the lengths are computed on both encrypt and decrypt in the abstract specification. I'd speculate there's a desire to have a packet format identical to the AEAD structure here, in which case the comment would make more sense. $\endgroup$
    – archie
    Jul 10 at 0:00

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.