HLRichardson-Git
commented
1 month ago As this change could effect performance of the implementation I took a benchmark of the current implementation. Here is that benchmark:
#include <benchmark/benchmark.h>
#include <string>
#include <gestalt/aes.h>
static void BM_AESEncryptECB(benchmark::State& state) {
const std::string key = "10a58869d74be5a374cf867cfb473859";
std::string pt;
pt.resize(state.range(0), 'A');
std::string ct;
for (auto _ : state) {
ct = encryptAESECB(pt, key);
benchmark::DoNotOptimize(ct);
}
}
BENCHMARK(BM_AESEncryptECB)->DenseRange(1024, 65536, 2048);
BENCHMARK_MAIN();Running this benchmark I received these results:
-----------------------------------------------------------------
Benchmark Time CPU Iterations
-----------------------------------------------------------------
BM_AESEncryptECB/1024 70809 ns 71498 ns 8960
BM_AESEncryptECB/3072 205943 ns 205078 ns 3200
BM_AESEncryptECB/5120 358817 ns 353021 ns 2036
BM_AESEncryptECB/7168 459763 ns 460482 ns 1493
BM_AESEncryptECB/9216 598512 ns 599888 ns 1120
BM_AESEncryptECB/11264 731372 ns 732422 ns 896
BM_AESEncryptECB/13312 869547 ns 878514 ns 747
BM_AESEncryptECB/15360 997502 ns 1004016 ns 747
BM_AESEncryptECB/17408 1120059 ns 1116071 ns 560
BM_AESEncryptECB/19456 1242621 ns 1223645 ns 498
BM_AESEncryptECB/21504 1388437 ns 1395089 ns 448
BM_AESEncryptECB/23552 1524054 ns 1534598 ns 448
BM_AESEncryptECB/25600 1637397 ns 1650799 ns 407
BM_AESEncryptECB/27648 1773527 ns 1759383 ns 373
BM_AESEncryptECB/29696 1940738 ns 1968834 ns 373
BM_AESEncryptECB/31744 2047902 ns 2038043 ns 345
BM_AESEncryptECB/33792 2192906 ns 2197266 ns 320
BM_AESEncryptECB/35840 2306850 ns 2299331 ns 299
BM_AESEncryptECB/37888 2432239 ns 2426610 ns 264
BM_AESEncryptECB/39936 2578160 ns 2544981 ns 264
BM_AESEncryptECB/41984 2707504 ns 2698293 ns 249
BM_AESEncryptECB/44032 2834147 ns 2846928 ns 236
BM_AESEncryptECB/46080 3039373 ns 2999442 ns 224
BM_AESEncryptECB/48128 3215499 ns 3208705 ns 224
BM_AESEncryptECB/50176 3531040 ns 3525641 ns 195
BM_AESEncryptECB/52224 3716222 ns 3753492 ns 179
BM_AESEncryptECB/54272 3618258 ns 3592914 ns 187
BM_AESEncryptECB/56320 3650675 ns 3578911 ns 179
BM_AESEncryptECB/58368 3970371 ns 4010695 ns 187
BM_AESEncryptECB/60416 4124791 ns 4178779 ns 172
BM_AESEncryptECB/62464 4050373 ns 4087936 ns 172
BM_AESEncryptECB/64512 4213611 ns 4199219 ns 160And here is that data graphed, where the x axis is the input sizes and the y axis is the time in ns:
Optimistically, the current implementation is very closely linear as the input size increases. The goal is to not effect the performance with this refactor.
Summary
In the latest version of Gestalt as of July, 30th 2024 version 0.6 we introduced the second block cipher DES (TDES as well if you count that as a separate cipher). In this, we ran into the not-at-all-unexpected problem of trying to use the current template functions for the modes of operations (ECB, CBC, etc) that were previously only use for AES.
Given that the AES implementation and DES implementation are fundamentally different in how blocks are "divided" i.e:
This means it isn't easy to make the template work for both block ciphers. I propose we refactor the AES implementation to better match the implementation of DES.
Motivation
The solution we settled on for version 0.6 was to create an independent implementation of ECB and CBC for DES and TDES. This is not ideal as we add more block ciphers it will become more and more of a headache to try and maintain them all.
Additional context
The way I plan on refactoring AES is to actually largely leave the implementation as it is. This is because I just want to change the implementation to always expect a
unsigned char block[16]instead of a pointer to a unsigned char array (who knows maybe this will help performance). Then we rework the modes of operation template so we can create a vector of theseunsigned char block[16]arrays, similar to how we make a vector ofuint64_tfor DES' mode of operations.Additionally, I would like to change how we do the current encryption/ decryption in place to return the computed value.