ChaCha20-Poly1305 and AES-GCM-SIV output size

Question

Background information:

I need to encrypt 168bit messages, the ciphertext should, preferably, match the plaintext size. Message Authentication and Integrity is not a must, but a really important should. My first idea was using AES-GCM-SIV, but performance is a thing. the software will run on a mini PC (Older RaspberryPi) and will need to encrypt a message every second and decrypt around 10 messages a second. The code will be written in C++ and the encryption and decryption will both run in their own threads. A new key will be used every day.

With the importance of performance in my mind, I began to look at ChaCha20, specifically ChaCha20-Poly1305.

I came to the following conclusion:

ChaCha20-Poly1305: Ciphertext Size: ChaCha20-Poly1305 produces ciphertext that includes the encrypted message and a 128-bit (16-byte) Poly1305 authentication tag appended to it. So, the ciphertext size is larger than the plaintext size due to this added authentication tag.

AES-GCM-SIV: Ciphertext Size: AES-SIV modes combine encryption and authentication, and they do not produce a separate authentication tag. The ciphertext size is the same as the plaintext size.

Comparison for a 168-bit message:

ChaCha20-Poly1305:

Ciphertext Size: 168 bits (message) + 128 bits (Poly1305 authentication tag) = 296 bits. Faster than AES-GCM-SIV, but a reused nonce is a serious threat.

AES-GCM-SIV:

Ciphertext Size: 168 bits (message) = 168 bits. Slower than ChaCha20-Poly1305, a reused nonce is not a big issue.

My questions are:

Is this conclusion correct?

Will the speed of AES-GCM-SIV cipher be a bottleneck?

EDIT:

If you have a suggestion for a better cipher, please feel free to share it!

Answer 1

I managed to free up just a little bit more than double the available space per message, so I can safely add a 128-bit tag so that we can have authenticated encryption.

The choice I am going to make is ASCON, as mentioned in the comments by @kelalaka. While this means that the application cannot be written in C++ (I won't write the implementation myself and the authors don't have it listed on their GitHub), it is the best cipher to use performance-wise.

I will still update the key every day since the key will be used by multiple devices, all using multiple sources of entropy and a PSRNG for generating the nonce for messages. While nonce reuse is not catastrophic with ASCON, I still feel like it is not a thing you should have in a system.

As @poncho mentioned clearly in the comments that AES-GCM-SIV also expands the ciphertext. The problem I was searching a solution for simply didn't have one.

Answer 2

Your background information and initial research are well laid out, and I'll address your queries point by point.

1. Ciphertext Sizes: Your observations are correct.

   • ChaCha20-Poly1305: The addition of the Poly1305 tag does increase the overall size of the ciphertext.
   • AES-GCM-SIV: The ciphertext size does remain the same as the plaintext, and one of the selling points of the SIV mode is nonce misuse resistance.

2. Performance:

   • ChaCha20-Poly1305 is designed to be fast, and it is especially so on platforms that do not have hardware acceleration for AES. Given that the older Raspberry Pi models don't have AES hardware acceleration, ChaCha20-Poly1305 might indeed perform better.
   • AES-GCM-SIV: While it is generally slower than ChaCha20-Poly1305 on platforms without AES hardware acceleration, it's important to benchmark this in your specific environment to get a realistic understanding. AES-GCM-SIV does have the advantage in nonce misuse resistance, making it safer in scenarios where nonces might accidentally get reused.

3. Is this conclusion correct?

Your conclusion seems accurate for the most part. ChaCha20-Poly1305 will likely be faster on older Raspberry Pi models that lack AES hardware acceleration, but the ciphertext is larger due to the authentication tag. AES-GCM-SIV provides an equal-sized ciphertext, with added nonce misuse resistance, but may be slower on the said platform.

4. Will the speed of AES-GCM-SIV cipher be a bottleneck?

On an older Raspberry Pi without AES hardware acceleration, AES-GCM-SIV might indeed be noticeably slower than ChaCha20-Poly1305. Whether this will be a bottleneck or not depends on the exact computational capabilities of your Raspberry Pi model and the workload.

Recommendation: Before finalizing a decision, I recommend setting up a small benchmark on your Raspberry Pi, encrypting and decrypting sample messages using both ciphers. Measure the time taken for both operations. This will give you concrete data on which cipher meets your performance needs and will validate or refute any concerns about potential bottlenecks.

Lastly, while performance is essential, ensure that security considerations are not compromised. If ever in doubt, it's always a good idea to consult with or have a review by a cryptography expert.