4
$\begingroup$

I have recently been playing with Chacha20-Poly1305 with libsodium, and all of the examples state the additional data portion of the tag is stored in plaintext when encrypted. But from what I can tell the AD tag never actually gets put anywhere in the ciphertext. So if I were to simply transfer the ciphertext I would never actually be able to extract the AD portion (which is where I would like to store the nonce). And even if I were to just append the AD portion to the ciphertext afterward I am not certain the best way to retrieve it without doing something like OpenSSL with its Salted__ magic constant.

All of the examples say something like this:

#define MESSAGE (const unsigned char *) "test"
#define MESSAGE_LEN 4
#define ADDITIONAL_DATA (const unsigned char *) "123456"
#define ADDITIONAL_DATA_LEN 6

unsigned char nonce[crypto_aead_chacha20poly1305_NPUBBYTES];
unsigned char key[crypto_aead_chacha20poly1305_KEYBYTES];
unsigned char ciphertext[MESSAGE_LEN + crypto_aead_chacha20poly1305_ABYTES];
unsigned long long ciphertext_len;

randombytes_buf(key, sizeof key);
randombytes_buf(nonce, sizeof nonce);

crypto_aead_chacha20poly1305_encrypt(ciphertext, &ciphertext_len,
                                     MESSAGE, MESSAGE_LEN,
                                     ADDITIONAL_DATA, ADDITIONAL_DATA_LEN,
                                     NULL, nonce, key);

unsigned char decrypted[MESSAGE_LEN];
unsigned long long decrypted_len;
if (crypto_aead_chacha20poly1305_decrypt(decrypted, &decrypted_len,
                                         NULL,
                                         ciphertext, ciphertext_len,
                                         ADDITIONAL_DATA,
                                         ADDITIONAL_DATA_LEN,
                                         nonce, key) != 0) {
    /* message forged! */
}

But in real life you obviously only retrieve the ciphertext and would not have ADDITIONAL_DATA without extracting it. So what is the "standard" way of handling additional data in a AEAD scheme?

EDIT: Got the OpenSSL magic constant wrong.

$\endgroup$
  • $\begingroup$ Note that Additional Data is also known as Additional Authenticated Data (AAD) in other schemes, I think AAD is more common. $\endgroup$ – Maarten Bodewes Feb 8 '15 at 5:54
5
$\begingroup$

First of all the Additional Data (AD) is not a tag. It is data that is also authenticated by the authentication tag. This authentication tag is appended to the ciphertext by libsodium. The tag doesn't consist of separate portions for AD and the ciphertext (and IV), the AD is taken into account during calculation of the tag.

The AD can be any data, including data that can be generated or data that is known in advance. In that sense it does not have to be send. How it is handled or generated is out of scope for the definition of the authenticated cipher. You do need all the AD data on both sides or you won't be able to calculate the authentication tag. The AD cannot be extracted from the ciphertext nor from the tag.

To my knowledge all authenticated ciphers already include the IV in the tag calculation, so there is no need to treat the IV as AD. It's actually a requirement for the CEASAR competition, so no doubt this algorithm will comply with that. Don't confuse or mix nonce and AD, they are different inputs to the cipher.

If you want a standard way of handling nonce, AD etc. you should look for a suitable container format such as CMS.

| improve this answer | |
$\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.