Initial implementation

[maurges]

Based on threshold BLS paper for MPC.

Docs may be improved I feel, but they already outnumber the code

[survived]

Didn't we want to do a threshold DH after all? I thought we'll end up with a protocol in which parties share secret key $x$, and given point $P$, parties can jointly compute $xP$. This should allow us to construct a KEM, but also, if we ever need the deterministic threshold one-way function, we can replace $X$ with hash_to_curve(...) in downstream library

[maurges]

Didn't we want to do a threshold DH after all?

We never discussed it in detail, so I just finished what I had. Your idea sounds useful, I'll switch to it

[maurges]

I'll rename the repo before merge. Not sure if we want to reserve a crates.io name before actually using this anywhere

[survived]

Not sure if we want to reserve a crates.io name before actually using this anywhere

I usually do that, I've been in situation when a troll took crate name before we found time to publish it. Our repo is yet private, so the risk is smaller

[survived]

The crate overall feels a bit too low-level. On one hand we have start_ecdh function, which uses round-based and key-share crates, and which is pretty intuitive, but on other hand, we have {partial_ecdh, aggregate} functions, which are quite difficult to use: one needs to manually extract necessary information from the key share, and figure out what piece of information to put to each argument (in my intuition, it may be very confusing for someone unfamiliar with MPC).

I'm not sure what the best way to improve. Possible approaches:

1. Move low-level functions into separate module, for advanced users to find
2. Annotate each function that it's low level, and that it's more difficult to use, and if you're unsure, please use start_ecdh.
3. Change the functions so they do accept the key share or key info

[maurges]

The low-levelness and the missing examples come from one reason: we don't currently have a usage for this crate. I wrote both styles, intending to see how we're going to use it in signers (the first draft used high-level run and I think we would have gone with it). It's hard to design a good API without a use-case.

Moving lower-level functions into a separate module and documenting them as such seems like a good idea.

[survived]

we don't currently have a usage for this crate

We do! Asymmetric encryption! Large one on our roadmap

[survived]

Ah you mean that it's not currently used anywhere in the code yet. Yeah, that's true, when you write a code that uses the library, it's easier to polish the API.

[survived]

On other hand, current API is usable, so you can easily use partial_ecdh/aggregate functions in the prod code (no brainer for you, as you wrote it), and then it will stay the same for eternity 😅 I'd rather make them accept key-share, so we don't need to decompose key shares in prod code, and do complex input arguments manipulation

[survived]

Anyway, separating low-level function into separate module is a good first step. I will look after prod code so they don't get to be used there 😃