kokke/tiny-AES-c

performance?

Closed this issue · 5 comments

sam0x17 commented

Is this fairly performant i.e. would this be something good to use on something other than an embedded system or is it going to be a lot slower than, say, openssl's implementation? Would be great if there was a note about relative performance in the README. The simplicity of the API makes it extremely easy to link against this in various languages using FFI, which is why I ask.

kokke commented

Hi @sam0x17 and thank you for your interest in this project :)

The short answer: This library is slow :D

The slightly longer answer is, I did not design the code to be slow as a feature, but every time a trade-off could be made, sacrificing speed for lower RAM usage, I have generally done that.

This library may be a single or a few orders of magnitude slower than OpenSSL and other implementations, especially the ones using machine instructions especially optimized for this (e.g. AES-NI on newer Intel CPUs).

If you are intending to use this code in desktop environments and speed is an issue, I would honestly recommend that you find an implementation using a table-based approach or convert this to do so. That is often a more sane choice once you can spare a few kilobytes of memory - which is often at a premium on embedded hosts.

DamonHD commented

You may possibly want to evaluate our efforts under https://github.com/opentrv/OTAESGCM
It is designed to squeeze into an 8-bit MCU, but does use tables and it portable to bigger CPUs (ie runs on laptop 64-bit CPUs for unit testing).
Rgds
Damon

  • 👍1
kokke commented

@DamonHD to the rescue once again 👍

Damon: Have you bench-marked the performance improvements against this implementation? I think a lot could be gained just from using tables. Especially decryption suffers immensely from the on-the-fly approach used by tiny-AES.

DamonHD commented

Hi,

I haven't, no. That would be a good thing to do. If someone else did it I'd happily capture the results in the project!

So many ideas, so little time!

BTW, I'm definitely NOT claiming that OTAESGCM is faster or better than yours in any way, but it may be worth trying.

Rgds

Damon

sam0x17 commented

thanks!