Integer nonce incrementing and encoding for AEAD_Mode for Chacha20Poly1305 Vs AES-GCM

[nata11]

Hello,
New to Botan and its API/src.I have a requirement to have integer nonce which will increment as a counter for each encryption. All of your examples show the nonce to be random generated bytes filling std::vector<uint8_t> and docs say that if another nonce is needed, another random IV/nonce can be created as the larger the bit size of the nonce the chances are zero to nil for a collision. I would like to use both ChaCha20Poly1305 and AES-GCM as any one of the options for my AEAD. I have two question related to this situation.

• Looking through your src and examples, it seems that the integer nonce will need to be converted/encoded to a std::vector<uint8_t> vector. There are no options for using an integer nonce directly so that I can increment the nonce for the next message easily. I see I can possibly use a pointer to an array for a nonce as well. Am I correct in this assumption?

• If I do have to encode it into a vector of uint8_t, the encoding format for Chacha20Poly1305 and AES-GCM are different. Chacha specs say the nonce needs to be Big Endian encoded and AES GCM specs say nonce needs to be Little Endian encoded. Question here is does Botan take care of that internally in its implementation of the two algorithms or since your examples only show random nonces, it does not really matter internally how the algorithms use those vectors in Botan? If I am specifically using a counter based nonce, I assume I have to encode it into the right endian format before passing it down the respective AEAD Cipher Mode algorithm.

Thanks
Nadeem

[reneme]

I have a requirement to have integer nonce which will increment as a counter for each encryption.

Just to clarify: Is your requirement to increment your nonce on a per-block basis (i.e. 16 bytes/128 bits), or on a per-message basis (arbitrary data size)? The latter sounds like a really bad idea, because it almost certainly leads to nonce-reuse and loss of confidentiality if you encrypt multiple messages under the same key.

The nonce increment on a per-block basis is just what AES-GCM does internally and you wouldn't need to worry about it when encrypting messages that are larger than 16 bytes.

it seems that the integer nonce will need to be converted/encoded to a std::vector<uint8_t>

That is correct. Botan takes the nonces as opaque buffers of bytes. However, internally they are incremented as mandated by the spec. If, in your application, you have to maintain the nonces as integers, you'll have to convert them into byte buffers as you assumed. Here's some code that may be helpful for that.

In any case, please be warned: Are you are planning to use the AEAD with the same key for multiple messages? Technically, this is fine, but it requires careful handling of the nonces. If, in any situation, the internal block cipher encrypts different plaintext blocks using the same key/nonce pair, you may be loosing all confidentiality guarantees!!

[nata11]

Yes, the requirement is for pre-message basis with careful monitoring/tracking of nonces and key changes at appropriate times in order to not have a reuse of the nonce with same key. I understand that AES-GCM / ChaCha20Poly1305 use the nonce and increment it per-block basis and had no plans to mess with Botan's implementation of these algorithms. Thanks for the sample code for the encoding and the confirmation on nonce stored as buffers of bytes.