Storing keyshards for ecdsa signing

[bonecruizer]

I have been playing with the ElGamal and ecdsa signing examples. In the current demos, a new key is generated each time.
If I understand correctly, the private key x used in the dsa example is never exposed since it exists as a SecureObject.
I would like to reuse a securely generated key by somehow storing (serializing) the shards each party holds locally, so next time they can be loaded (deserialized) and used in the signing process. This is part of a theoretical use case where certificates are signed using MPC (and also the key is generated with MPC and only stored as shards). So far I haven't found a way to do this within MPyC (I am no Python expert). Any ideas how to handle such a use case?

Thanks in advance,
Hilco

[lschoe]

A quick solution is to use Python's pickle module to (de)serialize the keys used by the MPC parties.

For example, if x is a SecureObject holding (a share of) the private key you can convert to/from a Python bytestring using

import pickle
s = pickle.dumps(x)
print(s)
x = pickle.loads(s)

With pickle.dump() and pickle.load() you can directly use a file to store the keys.

[bonecruizer]

Thanks for your reply. I actually tried that, but the binary files the nodes write out, are exactly the same, and when I load them and check the value of x.share, they are the same in all nodes (returns the value of the complete key). So that is when I started doubting this method. So maybe I am missing out on something.

I have the keygen from the ElGamal demo generate a key; then store it to a file unique for the current pid.

await mpc.start()
x, y = await keygen(curve.generator)   

shard_filename = 'shard_' + str(mpc.pid)
with open(shard_filename, "wb") as outfile:
    pickle.dump(x.share,outfile)

[lschoe]

If I run such code say with python dsa.py -M3 --output-file to create log files, including a print(s) to output a pickled share in the code, the log files are clearly different. How do you run your code?

[bonecruizer]

That was a rather helpful suggestion. Firstly, I noticed that I did not pickle the share but the object itself; secondly I ran the tests with two (remote) parties and apparently then the output is the same. Now running with three and I get different shares like expected. Brilliant :-) Thanks for the assistance.

Hilco

[lschoe]

You can also pickle the SecureObject if you like, instead of just the share.

And when you run the tests with only two parties, then the secret sharing will indeed be trivial, meaning that both parties see the secret. That's because for $m=2$ parties, the threshold is $t=\lfloor(m-1)/2\rfloor=0$. To get nontrivial secret sharing you need $m\geq3$ parties, to allow for an honest majority.