Conversation
feat: update generatePrivate in Core
feat: Update Point in common-types to be curve independant
refactor: propagate KeyType through core and serviceprovider
feat: storagelayer with ed25519
Feat ed/seed and importkey
Feat ed/update lagrange
Feat ed/refactor
fix: enable common type tests
feat: enable core tests secp256k1
…ivate feat: replace eccryptro's generatePrivate
|
@ieow addressed comments and rebased. Also changed the constructor to not require There is one weird thing: For one account ( |
|
I couldn't figure out the issue with this one specific user. Maybe the user was initialized incorrectly and is bugged. To resolve this, I simply changed the user schema and now the tests work fine. (The MAC error seems to be unrelated and is because torus.js in some cases pads the ciphertext, and therefore the MAC integrity check fails.) I think this may be ready for merge? @ieow @himanshuchawla009 |
| "typescript": "^5.2.2" | ||
| }, | ||
| "optionalDependencies": { | ||
| "@nx/nx-linux-x64-gnu": "16.10.0" |
There was a problem hiding this comment.
why this is required?
There was a problem hiding this comment.
After rebuilding the package-lock, this issue came up. This is apparently the common way to solve this.
packages/tss/src/provider.ts
Outdated
|
|
||
| verifierId?: string; | ||
|
|
||
| sssNodeDetails: { |
There was a problem hiding this comment.
we should move inlined interface to the type file also we should mark these class properties as private if they intend to be.
There was a problem hiding this comment.
I just copied this over from tkey-mpc. Actually, sssNodeDetails is not being used anywhere, so I removed it.
The properties are public somewhat intentionally (e.g., like custom auth also exposes the torus instance).
| * Initializes this service provider instance. If `tssKeyType` is not | ||
| * provided, it defaults to the value of `keyType`. | ||
| */ | ||
| constructor(args: TorusServiceProviderArgs & { enableOneKey?: boolean; tssKeyType?: KeyType }) { |
There was a problem hiding this comment.
we should just name it keyType for consistency
There was a problem hiding this comment.
TorusServiceProviderArgs already includes a variable keyType. tssKeyType is optional and is only there for the case, where you want keyType and tssKeyType be different. See the constructor comment.
There was a problem hiding this comment.
which should never be the case, as we discussed... we can use any key type internally but for a user facing interface it should be one type.
| super(args); | ||
| const { customAuthArgs, enableOneKey, tssKeyType } = args; | ||
| this.tssKeyType = tssKeyType || this.keyType; | ||
| this.tssTorus = new TorusUtils({ |
There was a problem hiding this comment.
why we need tssTorus in this class, cant we use parent torus class from customAuth instance available in parent class ?
There was a problem hiding this comment.
This is for the case where tssKeyType is different than keyType. We still support this. It would be actually quite a bit of work to remove this separation now. Although the default is to not specify tssKeyType and in this case it will just default to keyType, as described above.
There was a problem hiding this comment.
if tssKeyType is optional and doesnt have much real usecase significance we should just remove it. We can add it later if any usecases arises. It looks like a overkill scenario as of now, might make code a very difficult to maintain. We should just follow one rule:- Shares and finalKeys should be on keyType, metadata ops and keys should be on secp256k1.
matthiasgeihs
force-pushed
the
v13
branch
2 times, most recently
from
a499a5d to
90d7666
Compare
himanshuchawla009
force-pushed
the
v13
branch
2 times, most recently
from
3ee55c8 to
7cf8a25
Compare
|
already merged |
4 participants
This PR adds TSS support to TKey, deprecating
tkey-mpc. (Much of the code is copied from there.)Metadatato optionally contain TSS related data fields.TKeyTSS, a wrapper around TKey that provides functionality relevant to TSS.TSSTorusServiceProvider, a wrapper aroundTorusServiceProviderthat additionally provides functionality relevant to TSS. (This is mainly for reading TSS related node details. Alternatively, this could be integrated with the original TorusServiceProvider?)A corresponding WIP PR that shows the integration of this Module within MPC Core Kit is available at the MPC Core Kit repository: Web3Auth/mpc-core-kit#105.