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!

$\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
    Sep 15, 2023 at 8:21
  • $\begingroup$ There is also Lightweight Cryptography by NIST that you might be interested where Ascon selected. $\endgroup$
    – kelalaka
    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
    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
    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
    Sep 15, 2023 at 12:11

2 Answers 2

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.

$\endgroup$
1
-2
$\begingroup$

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.

  1. 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.

$\endgroup$
3
  • 2
    $\begingroup$ Can you please explain what do you mean by "The ciphertext size does remain the same as the plaintext" regarding AES-GCM-SIV? I am not an expert on this topic but I looked into the RFC datatracker.ietf.org/doc/html/rfc8452#autoid-8 and in section 8 they state "The final ciphertext is the result of XORing the plaintext with the keystream and appending the tag" therefore the ciphertext is also larger than the plaintext. Thats whats done in ChaCha-Poly as well unless I am mistaken. $\endgroup$
    – honzaik
    Sep 15, 2023 at 11:38
  • 1
    $\begingroup$ @honzaik is correct. AES-GCM-SIV also requires storing a tag, as does any AE or AEAD scheme. Unauthenticated encryption (where there's no tag) should rarely be used in protocols. A 128-bit tag is nothing and is also used for lightweight AEAD schemes, so I don't see why this is considered a problem. If you use a counter nonce, you have the minimal possible ciphertext expansion unless you truncate the tag, which is either not allowed for AEADs like ChaCha20-Poly1305 or not recommended for AEADs like AES-GCM. Just don't truncate tags. $\endgroup$ Sep 15, 2023 at 12:12
  • $\begingroup$ "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." So you don't consider yourself an expert on this matter, or maybe this is just a copt-out left by the AI (in this case ChatGPT) that you've consulted. $\endgroup$
    – Maarten Bodewes
    Sep 25, 2023 at 9:49

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.