example of local machine not running about protocols.distributed_keygen HOT 9 CLOSED

Could you check where the server is actually binding on (in the system)?

I would suggest trying to change this line

    pool.add_http_server(server_port, "localhost")

to this

    pool.add_http_server(server_port)

Default value of second argument is "0.0.0.0", that might solve your issues!

I was not able to reproduce your setting yet, but will try next week.

from protocols.distributed_keygen.

Hi Tony,

Based on the logging it seems like the messages are arriving. Servers suggest in the logging that they are binding to localhost (IPv4). However, the clients logging suggests that they are sending to ::1 (IPv6).

My first guess would be that there is difficulty in handling IPv6, or the IPv4 and IPv6 are mixed up.

from protocols.distributed_keygen.

Hi Thomas,

This seems reasonable. Are the libraries used in the project (say in Pool) supposed to use IPv6 or IPv4? Maybe it changed involuntarily due to update of required libraries?
Changing naively "localhost" to "[::1]" (in an attempt to use ipv6 when creating a server) didn't solve the problem because it says on line 84 of pool.py it tried to self.handlers_lookup[f"{socket.gethostbyname(addr)}:{port}"] = client (because it's an adress).
But I think it happens as a result of adding clients, not servers. So maybe there's a mix-up in pool.add_http_client and pool.add_http_server?
Is there a way to just force ipv4 all across the enviorenment?
How should the example in the appendix should be updated?

from protocols.distributed_keygen.

I tried your suggestion and it seems to work. I think it's a good idea to update the example in the readme.
However, I'm still experiencing some issues.
when trying to use distributed_scheme.decrypt() it seems to wait forever. Indeed, after further diving into the libraries, it seems in _decrypt_raw in DistributedPaillier class, it tries to broadcast to all the other parties its calculated share, but it is unclear from what part of the code they are going to respond. So when you reach recv_all() and execute result_tuple asynchronously, they never receive a response from the other parties. What am I missing?

from protocols.distributed_keygen.

Thanks for your feedback, will update the README accordingly.

In the distributed setting, decryption is an operation in which all (or at least a threshold number of) parties should perform collaboratively.

The current implementation requires all involved parties to call the decrypt function on the encryption. This means the encryption should be present on their machine, before being able to decrypt.

If the encryption that you wish to decrypt is not present at all involved parties, you should first share this encryption with them. This happens when your protocol is asymmetric.

An example where the latter is implemented can be found here: https://github.com/TNO-MPC/protocols.risk_propagation/blob/097b1d9c056ec1e8ab17a8ae6c08987b641c40ac/tno/mpc/protocols/risk_propagation/player.py#L110

from protocols.distributed_keygen.

This is what I eventually ended up doing to "bypass" it (which is not actually bypassing anything, but how it was intended to be used). In my head the idea was that "maybe the other parties agree to help to decrypt, but aren't interested in the result", but it seems a little bit irrelevant.

Thank you!

from protocols.distributed_keygen.

Additionally, the parties can configure who "learns" the result by specifying receivers

from protocols.distributed_keygen.

I have actually been facing the same problem recently, running the local code on a Ubuntu machine. It seems that the servers and parties are initialized correctly, but I'm still getting the following errors:
2022-04-20 00:41:24,748 - tno.mpc.communication.httphandlers - INFO - Serving on 127.0.0.1:3001
2022-04-20 00:41:24,750 - tno.mpc.communication.httphandlers - INFO - Serving on 127.0.0.1:3002
2022-04-20 00:41:24,750 - tno.mpc.communication.httphandlers - INFO - Serving on 127.0.0.1:3003
Starting distributed key generation protocol.
2022-04-20 00:41:24,858 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1
2022-04-20 00:41:24,859 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1
2022-04-20 00:41:24,859 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1
2022-04-20 00:41:24,859 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1
2022-04-20 00:41:24,859 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1
2022-04-20 00:41:24,861 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1
2022-04-20 00:41:24,862 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1
2022-04-20 00:41:24,869 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1
2022-04-20 00:41:24,871 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1
2022-04-20 00:41:24,871 - tno.mpc.communication.httphandlers - ERROR - Message not received.
Traceback (most recent call last):
File "/home/nojan/.local/lib/python3.8/site-packages/tno/mpc/communication/httphandlers.py", line 158, in _send
assert resp.status == 200, "Did not receive status OK (200)"
AssertionError: Did not receive status OK (200)

Do you have any idea why this could be happening? I've tried the solutions that were suggested above

from protocols.distributed_keygen.

I have actually been facing the same problem recently, running the local code on a Ubuntu machine. It seems that the servers and parties are initialized correctly, but I'm still getting the following errors: 2022-04-20 00:41:24,748 - tno.mpc.communication.httphandlers - INFO - Serving on 127.0.0.1:3001 2022-04-20 00:41:24,750 - tno.mpc.communication.httphandlers - INFO - Serving on 127.0.0.1:3002 2022-04-20 00:41:24,750 - tno.mpc.communication.httphandlers - INFO - Serving on 127.0.0.1:3003 Starting distributed key generation protocol. 2022-04-20 00:41:24,858 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1 2022-04-20 00:41:24,859 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1 2022-04-20 00:41:24,859 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1 2022-04-20 00:41:24,859 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1 2022-04-20 00:41:24,859 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1 2022-04-20 00:41:24,861 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1 2022-04-20 00:41:24,862 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1 2022-04-20 00:41:24,869 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1 2022-04-20 00:41:24,871 - tno.mpc.communication.httphandlers - INFO - Received message from 127.0.0.1 2022-04-20 00:41:24,871 - tno.mpc.communication.httphandlers - ERROR - Message not received. Traceback (most recent call last): File "/home/nojan/.local/lib/python3.8/site-packages/tno/mpc/communication/httphandlers.py", line 158, in _send assert resp.status == 200, "Did not receive status OK (200)" AssertionError: Did not receive status OK (200)

Do you have any idea why this could be happening? I've tried the solutions that were suggested above

I missed your remark in the closed issue. Did you manage to get it running?

Yesterday I published an optimized and improved version of this library (including updates on its requirements and updates in logging). Do you still experience trouble with this version?

from protocols.distributed_keygen.