-
Notifications
You must be signed in to change notification settings - Fork 26
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
Handle Subroutines ABORT #246
Comments
Discussed on WG on 6th of Mar. Will revisit for draft 03 after we simplify Sign |
Discussed on WG call on 13th of Mar. The current point serialization cannot be curve agnostic. Will update the test vectors to use un-compressed format and re visit this after. |
Discussed on WG call 20th of Mar. Will consider having PK as a point, to not restrict key representation. |
Discussed on WG call on 27th of Mar. Consensus is to define ciphersuite specific encodings with the addition to define PKs as points in the operation's input |
Discussed on the WG on the 22nd of May. Will address after PR #257 is merged |
2 sugestions for the Ciphersuite format:
A. Points serialization:
The point serialization we use is curve agnostic. No reason to be defined in the Ciphersuite. We could simplify things and define them as global parameters.
B.
expand_len
definition:After #243 is merged, we can define
expand_len
in the ciphersuite and impose requirements for its value in a way thatexpand_message
will never fail. We can then remove all theif uniform_bytes is INVALID, return INVALID
steps (and potentially even makehash_to_scalar
to never fail if we remove the check for 0s).The text was updated successfully, but these errors were encountered: