Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Group encrypt benchmark #31

Draft
wants to merge 2 commits into
base: dev
Choose a base branch
from

Conversation

jagerman
Copy link
Member

Add some test suite benchmarking for group encryption/decryption performance.

Quick takeaway: on my desktop system:

  • It takes an admin about 34ms to construct all the 1000 encryptions.
  • It takes a user about 430µs (i.e. 0.43ms) for one member to attempt decryption of all 1000 encrypted values (exactly one of these succeeds, but for the benchmark I try them all anyway).

Tests from running qemu arm64 emulation, still on my desktop:

  • The 1000 member encryption takes about 151ms
  • The 1000-attempt decryption takes about 1.9ms

And on a native arm64 Raspberry Pi:

  • encryption takes about 210ms
  • decryption takes about 1.6ms

(I'm more than a bit surprised that emulated arm64 performs that well--faster on the encryption and not that much slower on the decryption).

I don't think that's slow enough to worry about optimizing, at least for now (remember, these are 1000-member groups; a 100-member group is going to be 10x as fast), but if we did need more performance we could precompute the aM (group-priv-key times member-pubkey) value for all of the group members to get times of (amd64/arm64-qemu/arm64):

  • 1000-member encryption: 1.0ms/4.8ms/3.9ms (instead of 34ms/151ms/210ms so ~30x faster)
  • 1000-member decryption: 400µs/1.7ms/1.4ms (so ~10% faster).

i.e. most of the encryption time is spent doing crypto operations to compute each member's encryption key, not the encryption itself. (This is also why decryption is so much faster in the first place: there's only one crypto multiplication calculation for each member, of mA, rather than 1000 calculations of aM for each of 1000 different Ms).

The only problem with this caching is that you still have to do all the aM computations somewhere, so you still have to eat that extra time at some point, and then store them. So I'll put it down as a stretch goal for libsession-util to do such caching, but not something we need to launch new groups.

This provides some indication of how long it takes to encrypt/decrypt
keys for a simulated 1000-member group.
@jagerman jagerman marked this pull request as draft April 21, 2023 21:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant