-
Notifications
You must be signed in to change notification settings - Fork 19
Description
Describe the bug
AtClientImpl uses an empty Initialisation Vector when it encrypts and decrypts "shared keys" (and self keys). So a get works from Java if the put was performed by Java it will not work if the put was performed by the Dart SDK which will use a random IV (which it adds to the key meta data). Correspondingly a get from Dart SDK will work because it supports empty IV on decrypt but a put once the Java SDK has created the shared_key fails.
Steps to reproduce
Use the attached feature file, to enroll 2 APKAMS for the srie and device2 atsigns in the virtual env
This creates 2 shared keys and then repeatedly asserts that it can get the shared keys and the value match what was put
Use the demo dart code in at_demos/demos/at_getting_started APKAMs to get the values for these shared keys...
dart run at_key_get.dart -d vip.ve.atsign.zone -a @srie -n ns -k @srie-app1-device1.atKeys -o @device2
dart run at_key_get.dart -d vip.ve.atsign.zone -a @device2 -n ns -k @device2-app1-device1.atKeys -o @srie
and to attempt to put new values (which should cause the feature file to fail in the expected way
dart run at_key_put.dart -d vip.ve.atsign.zone -a @device2 -n ns -k @device2-app1-device1.atKeys -o @srie -m xxxxx
Expected behavior
Putting and Getting using the Java and Dart SDK in both "directions" should work
Screenshots
No response
Smartphones
- Device: [e.g. iPhone6]
- OS: [e.g. iOS8.1]
- Browser [e.g. stock browser, safari]
- Version [e.g. 22]
Were you using an atApplication when the bug was found?
No response
Additional context
No response