-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Registration function #84
base: master
Are you sure you want to change the base?
Conversation
let msgPtr = ctypes.unsigned_char.array()(m); | ||
let indexPtr = ctypes.unsigned_char.array()(index); | ||
let proofPtr = ctypes.unsigned_char.array()(proof); | ||
if (libCONIKS.cgoVerifyVrf(pkPtr, pk.length, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to compare this to the test-vectors here: https://github.com/yahoo/end-to-end/blob/master/src/javascript/crypto/e2e/coname/vrf/vrf_test.html ? Maybe (later), we should also consider this comment YahooArchive/end-to-end#58 (comment) / issue YahooArchive/end-to-end#59 (on the golang-side, too)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, could you please elaborate on this? Why do we want to perform that comparison?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought it might provide an extra check that on the JS side everything works as expected. It might be an overkill as the cgo part is already (well) tested. The second sentence refers to the FromBytesBaseGroup
in the coname's vrf code (which lacks some checks as explained in YahooArchive/end-to-end#59 and which is not directly related to this PR).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought it might provide an extra check that on the JS side everything works as expected. It might be an overkill as the cgo part is already (well) tested.
I think it's not really necessary since the vrf is implemented in go and is already tested.
The second sentence refers to the FromBytesBaseGroup in the coname's vrf code (which lacks some checks as explained in YahooArchive/end-to-end#59 and which is not directly related to this PR).
Yes. Should we open new ticket for this?
* Send registration request to CONIKS bots * Intercept CONIKS's response DM * Verify response * Store STR & TB to disk
This pull does:
TODO:
Handle registration when account is disconnected right after sending registration message or when users delete & restore their account. These cases need to be thoroughly analyzed (I would like to resolve it in a separate pull).
Changes compare to our discussion in #82 (comment):
coniks.str
), for example:{"epoch":0,"signature":[44,211,71,118,247,94,211,15,53,72,108,143,26,68,61,250,51,167,120,188,255,34,106,123,12,132,125,86,247,213,139,254,238,23,57,250,51,49,3,233,67,59,137,224,176,24,203,110,85,65,30,159,222,196,126,98,138,247,18,153,187,133,54,13]}
. The reason is I think the storage space should not be a concern, and I would like to use only one format for all files (i.e., JSON).AccountContext
, and after verifying the TB is inserted as promised, it will be set tonull
.