Seal | Create/Verify performance review a.k.a "Bring keys back home and marry your Identity"

features
1

@georg.greve as promised, getting back with the performance tests of the seal creation/verification routines.

For those who are not aware

On one of the previous demos Georg asked what might be the cause of possible slowdown of the seal creation process.

I mentioned that one of the things not under client’s control are backend calls related to signing/decryption/obtaining of the keys. (Key management calls for further reference)

Performance test

Test only covers seal creation and email verifications functions.

Status submission/verification and seal tail submission are not a subject of this test, because they are out of the scope of Key management logic.

Test has been performed 100 times and average values in seconds are provided.

TL;DR

Create seal function

  • CreateSeal.Total: 1.75s // Avg time to create seal
  • CreateSeal.BackendCalls.Total: 0.87s // Backend calls included in total time

Conclusion: Key management backend calls taking 50% of seal creation time.

Verify seal function

  • VerifyEmail.Total: 3.51s
  • VerifyEmail.Backblaze: 3.07s // Average time it takes to obtain seal tail from CDN with the average size of 3.4kb
  • VerifyEmail.Backend: 0.16s // Average time it takes to perform /qrcode-hsm/decrypt
  • VerifyEmail.VerifySignatures: 0.12s // Average time it takes to verify all MIME signatures using WebCrypto on the client

Conclusion: obtaining of the seal tail from the CDN is the most time consuming operation, although it’s very volatile. I’ve been noticing a spreading betwen 300ms-6s to download tail with the size of 3.4 kb

The whole report

Create seal function

  • CreateSeal.Total: 1.75s // Avg time to create seal
  • CreateSeal.BackendCalls.Total: 0.87s // Backend calls included in total time
  • CreateSeal.MimeSignaturesCalculation.Total: 0.58s // Avg time to calculate MIME signatures
  • CreateSeal.MimeSignaturesCalculation.Backend: 0.4s // Relevant /hsm/sign calls to backend
  • CreateSeal.EncryptSealData.Total: 0.38s // Avg seal encryption time
  • CreateSeal.EncryptSealData.Backend: 0.31s // Avg time for /qrcode-hsm/encrypt call
  • CreateSeal.CreateSealImage.Total: 0.36s // Avg time to create and prepare seal image
  • CreateSeal.CreateSealImage.CreateQrCode: 0.26s // creates QR code and places it on png template
  • CreateSeal.CreateSealImage.AddMetaData: 0.01s // adds PNG metadata
  • CreateSeal.CreateSealImage.PrepareHtmlTemplate: 0.07s // Prepares HTML template

Verify email function

  • VerifyEmail.Total: 3.51s
  • VerifyEmail.Backblaze: 3.07s // Average time it takes to obtain seal tail from CDN with the average size of 3.4kb
  • VerifyEmail.Backend: 0.16s // Average time it takes to perform /qrcode-hsm/decrypt
  • VerifyEmail.VerifySignatures: 0.12s // Average time it takes to verify all MIME signatures using WebCrypto on the client

Conclusion

It worth to consider local key management strategies for the seal project.

Benefits:

  • Better security
  • Improved performance
  • Decentralisation

Challenges:

  • Multi client/device key management
  • Key recovery and transferability to another devices

At the beginning of the seal project, we wanted to store keys in some persistent storage of the Outlook Add-in/Chrome Ext/Gmail Add-on. However there was no way to do it at that point in time.

Now we have iframes, and we can manage keys similarly to the Vereign Identity approach, which also might be a one step closer to marrying with Vereign Identity

@perkon please review

Ticket in GitLab

(https://code.vereign.com/seal/building-blocks/iframe/-/issues/9)

2 Likes