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

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