Using ByteBuffers allows us to to apply Android encryption directly to bytes allocated in Rust and remove the unnecessary copies. This diff also changes the JS encryption so that AES operates directly on the bytes of the Uint8Array.
Details
Details
Run code in this gist (the java testing code is taken from D8425)
- JS test
- Run the code in gist, check the logs for successful encryption/decryption:
key: 13,89,71,158,129,211,109,73,220,78,29,25,140,250,85,192,139,203,201,226,87,138,223,61,64,226,231,135,112,228,170,38 plaintext: 1,2,3,4,5,6,7,8,9,10 sealedData: 29,187,158,149,99,224,76,111,254,109,113,73,174,168,94,110,64,192,79,22,254,105,247,218,113,171,181,99,252,230,19,141,141,106,57,105,245,204 plaintext2: 1,2,3,4,5,6,7,8,9,10
- Java test
- Send a notification (which triggers the testing code
- check that there is Decrypted text: test_data! in the logs
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Minor thing but it's important to keep names correct. It's very easy to get confused here.
Link to glossary we created one time
| native/expo-modules/comm-expo-package/android/src/main/java/app/comm/android/aescrypto/AESCryptoModule.kt | ||
|---|---|---|
| 141 ↗ | (On Diff #33454) | |
| 158–162 ↗ | (On Diff #33454) | |
| 168 ↗ | (On Diff #33454) | Maybe add a comment here analogous to encryptAES that this returns destination buffer if provided |
| 171 ↗ | (On Diff #33454) | When initially implementing this, we agreed to keep strict naming rules for these variables. Sealed data = iv || ciphertext || tag |