1
$\begingroup$

I have to develop a program using a "secret" locally stored encoded program for a school project. For this I have to decipher the code on the fly to use it. The project recommend the use of AES 256 in CBC mode, but for better performance any suggestion is welcome.

So I have two questions:

  1. I made my own implementation of AES (I know it's not recommended but it's mandatory in the project) and I'm looking to compare it to the fastest software implementation, any idea where to find it?

  2. I was looking for faster cipher but more or less "as secure" than AES to suggest and implement. So far I found quite a few: CLEFIA, Threefish, Salsa20 and LWC:PRESENT, LEA, ASCON(AEAD?). I understand that the security on LWC is far less than standard cryptography(even though the difference is not really clear between SC and LWC) but they don't seem to be broken. Should they be used for my purpose? If not any other suggestion?

Thank you

$\endgroup$
3
  • 1
    $\begingroup$ One thing to consider: is the distinction between a block cipher and the mode of operation of a block cipher. You can block ciphers with CBC, but it might also be slow. AES-CTR may be faster if you can parallelize it for instance. For pure software, CHACHA20 seems to have good performance. Finally, it may be worth considering integrity protection as well $\endgroup$ Jun 18 at 15:02
  • $\begingroup$ yes I understood the distinction. When I was listing the others block ciphers, I meant using them with CBC mode. I don't understand how CTR mode is faster, you still need to compute the ENC(counter). It's only faster that CBC because it's also parallelizable for the encryption? But in my case since I will only focus on descryption on the fly, it' won't have any impact. For the integrity protection, I was thinking about AEAD scheme since it's provide confidentiality and integrity (and authenticity), but I don't know if it's mean to be used that way. $\endgroup$ Jun 18 at 18:56
  • 1
    $\begingroup$ Yes, CTR encryption is parallelizable while CBC encryption is fundamentally not, hence the advantage. I'm not sure what is meant by on the fly. But if decrypting chunks of 64 bytes, the encryption/decryption can be 4x. faster. AEADs are probably useful. I am thinking streaming AEAD can be a good fit: developers.google.com/tink/streaming-aead $\endgroup$ Jun 18 at 20:22

2 Answers 2

2
$\begingroup$

If you are writing your own implementation of AES, and can use the AES-NI instruction set, then you will end up with a cipher that is mathematically secure and fast. Very fast... AES in hardware is generally going to be faster than the storage device.

You may also fall into the trap of equating a mathematically secure cipher with a large keysize to a secure implementation of that cipher. Without the use of CPU instructions or a special coding like masking that WILL make your implementation slow and complex, it is not easy to make a secure AES implementation. If part of the grading is how secure your DRM scheme is, and it is obviously crackable despite your use of a secure block cipher, that may not bode well for your grade.

A cipher that is both fast and secure, even without hardware acceleration instructions, will be ChaCha8. It is a counter mode stream cipher and can be substantially faster than unaccelerated AES while also being far more securely implemented. It may even be as fast as AES with hardware acceleration if you can use vector instructions.

If you are looking for integrity protection it is commonly paired with the Poly1305 MAC, though you can use HMAC as well which may be less complex to implement but generally slower, as long as you have the option of generating more key material.

Finally, consider that if you are using a block cipher with a key, how those keys are stored, managed, and created. Many DRM schemes have been foiled simply due to poor key creation or management. Using a 128-bit cipher will not provide security if there are only 1000 unique input keys.

$\endgroup$
0
$\begingroup$

Try OpenSSL. It has assembly language routines which take advantage of CPU specific instructions that are intended to speed up AES. The assembly routines do have to be enabled when building OpenSSL.

When Oracle added similar to support to Java they got performance increases of a couple of orders of magnitude. Now that's Java, not C, so it's not surprising that the increase was very large and you won't see that kind of increase with OpenSSL. See this for some details.

$\endgroup$
1
  • $\begingroup$ Yeah I read about OpenSSL but It doesnt't have all the cipher I want to try. Also I need security arguments not only performance. So I can't just take the fastest one based on a benchmark. I understood that because of AES NI instruction set, AES is the fastest block software but I read on the specification of CLEFIA that it was faster, same for the LWC schemes. $\endgroup$ Jun 18 at 18:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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