Benchmark passphrase API of Secure Cell #582
Conversation
ilammy
added
core
| themis_secure_cell_encrypt_seal_with_passphrase, THEMIS_BUFFER_TOO_SMALL, THEMIS_SUCCESS, | ||
| }; | ||
|
|
||
| const PASSPHRASE: &str = "correct horse battery staple"; |
Indeed it is. Benchmarks on my Linux and macOS laptops show that with master-key API ancillary expenses (function calls, checks, memory zeroing, etc.) dominate actual encryption until you're encrypting around 1 KB of data, then throughput raises and tapers off at around 2 GB/s when encrypting more than 0.5 MB at once. Decryption shows similar numbers. To put it short, 3.5 microseconds to encrypt 32 bytes of a master key with another master key. Passphrase API has enormous (relatively speaking) fixed costs of KDF – approx. 120 milliseconds for our current 200k of PBKDF2 iterations – so it takes around 100+ MB of data for the passphrase API to show somewhat comparable throughput. Well, it‘s not like these APIs have comparable use cases in the first place... (And Secure Cell is not designed for streaming encryption, though Context Imprint mode should be capable of supporting it.) CircleCI shows more or less similar numbers. That is, KDF adds around 15 bits of “effective entropy” to user passphrases, which is... probably not bad, considering that passphrase users are unlikely to follow NIST advice (80 bits) and this API is probably going to be used with 4-digit PINs (13 bits) and 10-character or 4-word passwords (~30 bits). Master key API is always better when you don't have to keep the secret in your head (256 bits). |
Right now we don't have support for this API in RustThemis so we call C code directly in decryption benchmark to prepare the input data. Note that due to the nature of the passphrase API -- KDF makes repeated invocations purposefully slow -- the benchmarks are abysmally slow too and we have to cut down the sample sizes to execute them in a resonable time frame. And we don't need to have much variety in the message size since execution time is completely dominated by KDF costs until we get to gigabyte-sized messages. There is quite a few "inheritance" in the code from master key benchmarks but I'll leave it around for now until we are sure what utilities can be shared. Plus, Criterion has issues with reusing code so we might need to introduce additional helper crates for that which I would like to avoid doing.
ilammy
force-pushed
the
kdf/benchmarks
branch
from
4e56268
to
af0af3c
Compare
|
Dependencies have been merged. Rebased and retargeted onto master with no changes. |
Some benchmarks for passphrase API added in #577.
Right now we don't have support for this API in RustThemis so we call C code directly in decryption benchmark to prepare the input data.
Note that due to the nature of the passphrase API – KDF makes repeated invocations purposefully slow – the benchmarks are abysmally slow too and we have to cut down the sample sizes to execute them in a reasonable time frame. And we don't need to have much variety in the message size since execution time is completely dominated by KDF costs until we get to gigabyte-sized messages.
There is quite a few “inheritance” in the code from master key benchmarks but I'll leave it around for now until we are sure what utilities can be shared. Plus, Criterion has issues with reusing code so we might need to introduce additional helper crates for that which I would like to avoid doing.
🚧 This branch depends on #577 and #580 so it has to wait before they are merged. To get better diffs the PR is targeted to a temporary branch which has to be removed before this PR is merged.
Once dependencies are merged, do the following:
Follow the order. If the base branch is deleted early then this PR might get autoclosed.
Checklist