keymanager/src/churp: Fetch key shares and recover key #5715
Conversation
✅ Deploy Preview for oasisprotocol-oasis-core canceled.
|
peternose
force-pushed
the
peternose/feature/churp-key-shares
branch
2 times, most recently
from
fc936de
to
46befe0
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #5715 +/- ##
==========================================
+ Coverage 65.03% 65.49% +0.45%
==========================================
Files 619 620 +1
Lines 63248 63308 +60
==========================================
+ Hits 41134 41464 +330
+ Misses 17292 16968 -324
- Partials 4822 4876 +54 ☔ View full report in Codecov by Sentry. |
peternose
requested review from
kostko,
peterjgilbert,
pro-wh and
ptrus
as code owners
peternose
force-pushed
the
peternose/feature/churp-key-shares
branch
4 times, most recently
from
40a9928
to
81dfcd7
Compare
peternose
force-pushed
the
peternose/feature/churp-key-shares
branch
2 times, most recently
from
d99ccf3
to
486a70a
Compare
| @@ -7,10 +7,6 @@ use p384::{ | |||
|
|
|||
| use super::{FieldDigest, GroupDigest}; | |||
|
|
|||
| /// Domain separation tag for encoding to NIST P-384 prime field or curve | |||
| /// using the SHA3-384 hash function. | |||
| const NIST_P384_SHA3_384_ENC_DST: &[u8] = b"P384_XMD:SHA3-384_SSWU_RO_"; | |||
There was a problem hiding this comment.
Will not using standard DSTs make it harder for third-party implementations?
There was a problem hiding this comment.
I guess if DSTs don't use something like length-prefix encoding for the components (e.g. like TupleHash), then it doesn't make it any easier as soon as there are custom DSTs. So in this case it is fine and this can be ignored.
There was a problem hiding this comment.
By harder for third party implementations you mean that it would be great to have standard dst in the package so that third party apps can easily construct full dst?
IEFT draft hashing to elliptic curves suggests name <app>-V<xx>-CS<yy>-<suiteID>-<enc> where <xx> and <yy> are two-digit numbers indicating the version and ciphersuite, respectively, and <suiteID> is the Suite ID of the encoding used in ciphersuite <yy>. I'm not sure what <yy> should be, but I guess in our case the dst should be oasis-core/keymanager/churp: V00-P384_XMD:SHA3-384_SSWU_RO_-<runtime_id>-<churp_id>-shareholder or CHURP-V00-P384_XMD:SHA3-384_SSWU_RO_-<runtime_id>-<churp_id>-shareholder. However, if we want to be consistent with our signature ctx, the tag should be oasis-core/keymanager/churp: sharehoder for runtime <id> for churp <id>. Not sure what is better.
There was a problem hiding this comment.
length-prefix encoding for the components
Tested locally, and I get the same result. I also checked the code, and length prefix or suffix (not sure what) is added only to the full dst (concatenated components).
Renames request not authorized error message and uses block_on function to simplify the code.
peternose
force-pushed
the
peternose/feature/churp-key-shares
branch
from
0a9f1d6
to
8812ba2
Compare
Updates the key manager client to fetch key shares from shareholders and reconstruct the secret key, from which the state key can be derived.