0
$\begingroup$

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!

Improve this question
$\endgroup$
6
  • $\begingroup$ What about ChaCha20's nonce? The tag calculation in needs double pass in GCM. There is also SIV mode for ChaCha20-Poly1305, too. Though your messages are small, SIV mode need to process data before encryption. Did you post somewhere some performance measure on your device? $\endgroup$
    – kelalaka
    Commented Sep 15, 2023 at 8:21
  • $\begingroup$ There is also Lightweight Cryptography by NIST that you might be interested where Ascon selected. $\endgroup$
    – kelalaka
    Commented Sep 15, 2023 at 8:25
  • $\begingroup$ @kelalaka While I do know a bit about cryptography, I am still a novice (probably a level below novice) and do not know the working of ciphers. From my understanding ChaCha20-Poy1305S-SIV is also slower than ChaCha20-Poly1305? The need for a new key every day was implemented because of the risk of reusing a nonce if the nonce cannot be that big. (From my understanding a bigger nonce = more ciphertext expansion?). The device that will be used for this project is a RaspBerryPi 2B. Thank you for the recommendation of Lightweight Cryptography bij NIST, I will take a look at that. $\endgroup$
    – Florebol
    Commented Sep 15, 2023 at 8:58
  • 1
    $\begingroup$ AES-SIV does expand the ciphertext. Actually, any cipher that accepts arbitrary bitstrings for encryption and does authentication (that is, during decryption, the decryptor has a probability of rejecting ciphertexts that were not generated by the encryptor) will expand the ciphertext. Hence you need to pick between "no ciphertext expansion" and "message integrity checking" $\endgroup$
    – poncho
    Commented Sep 15, 2023 at 12:07
  • 1
    $\begingroup$ "With the importance of performance in my mind"; is performance that criticial? A raspberry-pi should be well capable for [en|de]crypting 11 short messages per second with any reasonable mode of operation, with plenty of room to spare... $\endgroup$
    – poncho
    Commented Sep 15, 2023 at 12:11

1 Answer 1

Reset to default
1
$\begingroup$

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.

Improve this answer
$\endgroup$
1

Your Answer

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

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