this diff exposes the server apis from the opaque-ke library for account registration and login. wanted to get this out before it blocks the backup service.
Details
Details
unit tested, checked that the C++ headers were generated as expected
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- opaque-ke-server (branched from master)
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
Created a linear task to restructure the cargo project and consolidate some of the unit testing code: https://linear.app/comm/issue/ENG-727/restructure-and-clean-up-the-opaque-ke-cxx-package
| native/cpp/CommonCpp/CryptoTools/opaque-ke-cxx/src/lib.rs | ||
|---|---|---|
| 85 ↗ | (On Diff #9554) | I don't really like how you're reusing MessageState in all of these requests. Prefer to create new structs for each call, mirroring the underlying API. Why not reuse the struct if the all end up just being a pair of byte vecs? To perserve the typedness of the API. If you have one type of like a ServerRegistrationStartResult there's really only one thing you can do with it -- the next step in the protocol. This is good API design because its hard to misuse. |
| 233 ↗ | (On Diff #9554) | nit: I wouldn't have introduced password_file_bytes. Just file: s.serialize(). |
| 252 ↗ | (On Diff #9554) | Also consider inlining the message: s.message.serialize()? here |
| 277 ↗ | (On Diff #9554) | Why does this function exist? |
| 284 ↗ | (On Diff #9554) | I'd inline this also |