bbs-signature
bbs-signature copied to clipboard
decentralized-identity
Update KeyGen procedure to use hash_to_scalar
Since we don't use HKDF anywhere else and aren't trying to be compatible with the BLS signatures spec (different salt).
It's a bit odd using camel case for the input parameters and snake case for the parameter, but I'm trying to be consistent with the rest of the spec.
Likewise, I'm not sure if we prefer len() or length(), and either way we might need to define that.
Although i agree with removing the dependency to hkdf I'm worried that we are changing the security assumptions.
It's true that the H2C spec claims expand_message to be intistinquishable from a RO, however 1. there is no formal published work proving that (the claim is based in comparisons with [CDMP05]), 2. we didn't required that up until now. We only required expand_message to have basic "hash" properties i.e., "un-revershability" and "coalition resistance". So using it for KeyGen does raise the amount of assumptions we have to make.
Note:
This is probably completely fine. We can always add this to the list of things we need to revisit and do a formal analysis on ;P. So I'm happy to move with this.
For reference, the VOPRF draft also uses hash-to-scalar for key generation: https://cfrg.github.io/draft-irtf-cfrg-voprf/draft-irtf-cfrg-voprf.html#name-key-generation-and-context-
Discussed on WG call today, @andrewwhitehead is going to update with latest changes from VOPRF once #230 is merged.
Discussed on WG of 14th of Feb. Will discuss after PR #243 is resolved.
Discussed on WG call on 6th of Mar. Will update the test vectors and try to incorporate the update for draft 02.
Discussed on WG call 13th of Mar, will update to include the ciphersuite id to the default dst. Will review after.
Discussed briefly on the 10th April call, @andrewwhitehead believes all pending updates to the schemes definition have been done and we will discuss again next week as a wider group about approval and merging.