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

feat (atchops): Faster aes ctr algorithms #705

Open
XavierChanth opened this issue Nov 7, 2024 · 4 comments · May be fixed by #744
Open

feat (atchops): Faster aes ctr algorithms #705

XavierChanth opened this issue Nov 7, 2024 · 4 comments · May be fixed by #744
Assignees

Comments

@XavierChanth
Copy link
Member

XavierChanth commented Nov 7, 2024

Based on previous discussions and benchmarking, we plan to roll this out in two phases:

A note from me:

I believe the best path forward is:

Soon:
Decide on the algorithm (I think it's pretty clear that better is better for our needs)
Make non-breaking changes to uptake the new algorithm in pure-dart

When we have free time or more demand:
Make the breaking changes to atChops to return FutureOr<T> for all operations which 
could be asynchronous as a result of hardware acceleration
Propagate those changes to our packages
Add a new "initialize" function to at_client_mobile which is expected to be called 
at Flutter startup and loads the hardware acceleration libraries

Benchmarks were done against better_cryptography, webcrypto (boring ssl), cryptography, our C implementation of atchops using ffi (mbedtls) and the current library (encrypt)
The benchmarks were done without PKCS padding, since some algorithms don't include it out of the box.

Better cryptography was consistently the fastest of the stable algorithms, it doesn't support padding, so we will have to take that into consideration when implementing.

@XavierChanth
Copy link
Member Author

@murali-shris - 2 things to be done:

  1. Replace our current implementation of aes with the better_cryptography package.
  2. Re-implement PKCS padding for the output, better doesn't pad anything out of the box.

FYI: I did the performance & compatibility tests without any padding for all the algorithms, so the padding didn't impact our results.

@murali-shris
Copy link
Member

murali-shris commented Dec 2, 2024

@XavierChanth @gkc
Data encrypted using existing AES algo in at_chops cannot be decrypted using better_cryptography AES ctr algo since it has mac (message authentication code) as a param to encrypt/decrypt.
I have this approach in mind to preserve backward compatibility.

  1. Introduce new impl in at_chops - AESCtrEncryptionAlgo which will use better_cryptography. Set encAlgo in at_key.metadata to AESCTR256 or AESCTR512 .
  2. Deprecated existing AES impl - AESEncryptionAlgo
  3. In at_client SharedKeyEncryption, replace AESEncryptionAlgo with AESCtrEncryptionAlgo
  4. In at_client SharedKeyDecryption, based on encAlgo call existing AES decryption or new AES Ctr decryption
    Please let me know your thoughts on this approach

@XavierChanth
Copy link
Member Author

XavierChanth commented Dec 2, 2024

@murali-shris better's api is usable without mac, see the benchmark code in at_mono. Better is fully compatible with our current algo. It is not a drop in replacement, we will need to rework code, but all of the code changes should be in private implementation details.

The only additional work we will need here is to implement PKCS padding, as the current aes package does padding whereas better does not.

@murali-shris
Copy link
Member

at_chops and at_auth changes
#705
at_client PR:
atsign-foundation/at_client_sdk#1446
at_server PR:
atsign-foundation/at_server#2173

@murali-shris murali-shris linked a pull request Dec 19, 2024 that will close this issue
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 a pull request may close this issue.

2 participants