implement chillidkg #192
implement chillidkg #192
Conversation
- It should be possible to convert to a Scalar<Public> from NonZeroU32
We weren't following any of the FROST papers in how to compute the binding coefficient. To follow [1] all we have to do is hash the parties involved. [1]: https://eprint.iacr.org/2023/899
|
This is ready for review now.
|
| let dh_key = g!(multi_nonce_keypair.secret_key() * encryption_key).normalize(); | ||
| let pad = Scalar::from_hash(H::default().add(dh_key).add(encryption_key).add(dest)); | ||
| let payload = s!(pad + share).public(); | ||
| (*dest, payload) |
There was a problem hiding this comment.
This doesn't quite match the encryption of encpedpop here.
We calulate dh_key the same way.
Their hash is different to ours:
Hash( "encpedpop ecdh", dh_key || my_pubkey || their_pubkey || context_data )- I think their
my_pubkey/pubnoncewe have asmulti_nonce_keypair.public_key(), notencryption_key? - Our hash is missing context data that sounds important? See this comment: This hashed ElGamal's "crucial feature is to feed the index of the enckey to the hash function"
There was a problem hiding this comment.
I instead implemented it like in the paper referenced:
- Yes there a few instances of this. I am just putting in what I think is actually important because I'm lazy and I don't know how this will actually turn out byte-for-byte yet. It's a very good idea to look closely at this though and ask questions (as you've just done!).
my_pubkeyisencryption_keyandpubnonceismulti_nonce_keypair.public_key(). I'm not sure what the right name. Maybe it shouldn't be called encryption_key because we later transform it into a signing key.- The index is dest.
There was a problem hiding this comment.
That makes sense.
Theyre passing their pubnonce into my_pubkey for their encryption hash, bit confusing. So they're actually including multi_nonce_keypair.public_key() in their hash
There was a problem hiding this comment.
Yes. pubnonce is definitely superfluous since it's a function of dh_key and my_pubkey. There is an approach to these kinds of "what to hash" question which is just hash every single thing without giving a particular justification for it. That's a fine approach but it requires extra care when specifying the thing otherwise you end up with concatenating stuff like "context_data" everywhere and it gets unwieldy.
Implements the ideas from the bip-frost spec. This is a WIP. I think I like the new spec way better so I want to make proper errors for the error cases as well do documentation and renaming. Then delete the old key generation.
This deviates from the spec in several ways that I won't bother to list but they are mostly superficial things that I'll either fix or make an issue about.