Page MenuHomePhabricator

[native] Expose verifySignature function via JSI
ClosedPublic

Authored by bartek on May 6 2024, 7:18 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Nov 10, 3:02 PM
Unknown Object (File)
Sun, Nov 10, 9:23 AM
Unknown Object (File)
Sun, Nov 10, 9:17 AM
Unknown Object (File)
Sun, Nov 10, 3:25 AM
Unknown Object (File)
Mon, Oct 28, 12:29 PM
Unknown Object (File)
Fri, Oct 25, 7:06 PM
Unknown Object (File)
Oct 11 2024, 1:44 AM
Unknown Object (File)
Oct 11 2024, 1:44 AM
Subscribers

Details

Summary

This function is needed to verify device list signatures. It was already there in CryptoModule but not yet exposed via JSI.

Test Plan
await commCoreModule.initializeCryptoAccount();
const pubKey = await getContentSigningKey();
const signature = await commCoreModule.signMessage('hello');

try {
  await commCoreModule.verifySignature(pubKey, 'hello', signature);
  console.log('OK');
} catch (err) {
  console.warn(err);
}

Changing the message or signature returns BAD_MESSAGE_MAC

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

bartek held this revision as a draft.
bartek published this revision for review.May 6 2024, 8:15 AM
This revision is now accepted and ready to land.May 6 2024, 9:34 AM
native/schema/CommCoreModuleSchema.js
140 ↗(On Diff #39849)

Sorry for suggesting this after accepting the diff but it occurred to me only after I saw the child diff - it is a bad design for a signature verification to throw if the signature is bad. I think it would be better to implement it to return boolean.

native/schema/CommCoreModuleSchema.js
140 ↗(On Diff #39849)

Yeah I'd love to have it return boolean too. The reason I decided to throw is to keep consistent with JS counterpart on web and our function in CryptoModule:

Olm C API docs say that this is the way of distinguishing different failure causes.

native/schema/CommCoreModuleSchema.js
140 ↗(On Diff #39849)

If there are multiple reasons for verification failure and the JS version throws anyway then it justifies this approach. On the other hand we are actually not doing anything with this error details. How about returning to JS some thing like:

{
    +error?: string,
    +success?: 'true'
}

?

native/schema/CommCoreModuleSchema.js
140 ↗(On Diff #39849)

Played with this a bit and I think your proposal makes more sense on the JS side (in olmAPI - child diff). This way, we can also do it for web