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.

$\endgroup$
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.

$\endgroup$

Your Answer

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

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