Page MenuHomePhabricator

[keyserver] APIs for starting client side of PAKE login
ClosedPublic

Authored by varun on Nov 28 2022, 7:47 AM.
Tags
None
Referenced Files
F3386891: D5738.diff
Fri, Nov 29, 6:43 AM
Unknown Object (File)
Mon, Nov 25, 3:54 AM
Unknown Object (File)
Mon, Nov 25, 3:54 AM
Unknown Object (File)
Fri, Nov 22, 8:01 AM
Unknown Object (File)
Fri, Nov 22, 8:01 AM
Unknown Object (File)
Fri, Nov 22, 8:01 AM
Unknown Object (File)
Fri, Nov 22, 8:01 AM
Unknown Object (File)
Fri, Nov 22, 7:59 AM
Subscribers

Details

Summary

using Neon to surface the Rust opaque-ke "client login start" API to Node.js, along with some getters

Test Plan

called the new APIs from a Node module and confirmed the results

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

varun requested review of this revision.Nov 28 2022, 8:01 AM
atul added a subscriber: bartek.

(Think it probably makes sense to add @bartek to your Rust diffs even if he doesn't have full context on identity stuff? CC @ashoat @tomek who probably have a better idea)

Don't have context + enough rust knowledge here

change js functions to camelCase

varun edited reviewers, added: jon; removed: atul. varun added 2 blocking reviewer(s): tomek, bartek.Nov 29 2022, 11:35 PM
tomek added inline comments.
keyserver/addons/opaque-ke-node/src/lib.rs
154–177

These two seem to be almost identical. Can we somehow share the logic between them?

bartek added inline comments.
keyserver/addons/opaque-ke-node/src/lib.rs
154–177

I'm wondering if it would be worth implementing this API in a more object-oriented way.

// in JS, instead of
const startResult = clientLoginStart(...);
const loginStateArray = getLoginStartStateArray(startResult);
const loginMessageArray = getLoginStartMessageArray(startResult);

// do this
const startResult = clientLoginStart(...);
const loginStateArray = startResult.getStateArray();
const loginMessageArray = startResult.getMessageArray();

But not sure how could this affect the complexity/readibility of this code and if it is even convenient to mix JsBox and JsObject

I think the object oriented way is a bit cleaner, especially if everything needs to go through a context object anyway.

Personally I'm not a fan of get in method names, generally it's implied.

This revision is now accepted and ready to land.Nov 30 2022, 11:47 AM
keyserver/addons/opaque-ke-node/src/lib.rs
154–177

I wanted to do this in a more object-oriented way, but I couldn't figure out how to get data from a JsBox on the javascript side

154–177

These two seem to be almost identical. Can we somehow share the logic between them?

Can't think of a good way besides introducing an enum as a function param, but that adds a different kind of complexity...

https://linear.app/comm/issue/ENG-2384/improve-the-opaque-ke-node-library

In D5738#172368, @jon wrote:

I think the object oriented way is a bit cleaner, especially if everything needs to go through a context object anyway.

Personally I'm not a fan of get in method names, generally it's implied.

https://linear.app/comm/issue/ENG-2384/improve-the-opaque-ke-node-library