0
$\begingroup$

I'm in need of an encryption algorithm that can be easily implemented in c, doesn't drastically increase the size of the encrypted data (the data to be encrypted will be approximately 200 bytes and the size can't increase by more than 15%) It is also important for the algorithm to be quite lightweight as it's going to be running on minimal hardware. I initially tried RSA with two 4-digit prime decimal numbers for the key generation and it worked but decoding took more than 40 seconds on my home computer so it would be completely unviable on a microcontroller. I then looked into SPECK and SIMON but the single example i was able to find didn't produce the correct results. Also the fact that SPECK and SIMON are block ciphers introduces more issues. Is there another cipher that fits my requirements? Thanks in advance

$\endgroup$
4
  • 2
    $\begingroup$ "RSA with two 4-digit prime", This is an alarming sign that you have no clue of what you're doing! And even a 2048-bit modulus won't take nearly 40 seconds to decrypt! The best case scenario with this is that tell us what kind of application you're developing, and we may be able to suggest an existing product that cover your need. $\endgroup$
    – DannyNiu
    Commented Apr 10 at 1:21
  • 2
    $\begingroup$ this question doesn't really make sense. are you looking for symmetric or asymmetric encryption? $\endgroup$ Commented Apr 10 at 1:46
  • $\begingroup$ @DannyNiu I know RSA with that kind of numbers is terribly insecure. My main priority is it being lightweight (encryption is just for show on this project to be honest) so before i found out about dedicated lightweight algorithms (cryptography isn't exactly my thing as you can probably tell) I tried that. If however there's a way to have some kind of security, I much prefer that. Now as for why RSA decryption takes so long, I'm probably doing something terribly wrong but as RSA is probably not the way to go, I didn't troubleshoot it further. $\endgroup$
    – Hristos
    Commented Apr 10 at 6:13
  • $\begingroup$ If it has to be implemented from bare C (no library), and only confidentiality (not integrity) is thought, I would suggest a block cipher (like TEA which is particularly simple to code, SIMON, SPECK) in CTR, CFB or OFB mode. $\endgroup$
    – fgrieu
    Commented Apr 10 at 7:04

1 Answer 1

2
$\begingroup$

Most symmetric modes of encryption - i.e. block ciphers in a mode of operation or stream ciphers - do not require overhead other than a nonce and an optional authentication tag. Using RSA or ECDSA or other asymmetric primitives will always add significant overhead for the significant benefit that they give regarding key management (in many scenarios).

The nonce is required because otherwise the ciphertext would be the same as the plaintext. It depends on the protocol if the nonce is required to be send with the ciphertext or not; if a nonce can be securely established between sender and receiver of the ciphertext (which can be the same entity in case the ciphertext is only stored, rather than transmitted). The authentication tag is required if message integrity & authenticity needs to be maintained. It isn't strictly required when the message needs to be confidential, although many factors such as plaintext oracles should then be taken into account.

If we do some calculations in your case then 200 bytes with a maximum overhead of 15% gives us 230 bytes. 30 bytes of overhead gives us ample space to store a nonce and optional authentication tag. Of course, if you'd bring down the message to 100 bytes then those 30 bytes would be a 30% increase. The overhead is generally a constant. This assumes that the ciphertext consists of randomized bytes - i.e. it is not base 64 encoded or similar. It may also be that the plaintext requires additional overhead such as length bytes; it's assumed here that this overhead is within the 200 bytes mentioned; it is not part of the ciphertext expansion.

You are saying that SPECK and SIMON would "cause more issues" but actually running a block cipher in counter mode is pretty easy. You setup a unique counter block using the message-unique nonce, encrypt that with the block cipher giving you 8 or 16 bytes of key stream. This key stream can be XOR'ed with the plaintext to give the ciphertext. This ciphertext can be decrypted using the exact same routine; you'd only need the block cipher encryption routine.

There are also lightweight stream ciphers which often perform a very similar operation - although they usually don't use a counter to calculate the key stream. The problem is that lightweight stream ciphers seems an ever ongoing point of research, with the ciphers balancing on the edge of security and performance. To get the best cipher you may need to look into the most recent literature and choose one that is modern, fast and / or small, relatively secure but also well studied. Personally I'd just take a look at Salsa / ChaCha variants and check if the performance is OK.

Beware that stream ciphers and ciphers in CTR mode themselves don't offer integrity/authenticity and that repeating the key stream (or, therefore, counter) will break security almost entirely.

$\endgroup$

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.