ladnir
commented
1 year ago yes, in some ways the threading support for IKNP is actually better than silent. If you want multiple threads for IKNP, you call splitBase() and this will give you a new instance if IKNP. You then create multiple threads and give each one copy of IKNP.
For silent, you can do the same but maybe sometimes you dont want to. If you call splitBase() and run multiple instances at a time, the communication complexity scales linearly with the number of threads. The internal communication complexity of silent is log, so if you want N ots, then you will send log N data if you use one thread and t * log(N/t) data if you split the ots across t threads.
In order to keep the same communication complexity and use t threads, silentOT offers this additional parameter. Unfortunately, the current PCG codes don't support multi-threading so only a portion of the silentOT protocol will actually be multi-threaded. In particular, only the generation of the sparse noise vector is multi-threaded. This is less than half the time for a single-threaded execution.
If you are ok with t * log(N/t) communication complexity, I think the splitBase() approach is still preferable. If you do this approach, make sure that you call the genBaseOts() protocol before calling splitBase, that way you dont need to do expensive base OT generation every time.
Xenooooooooo
Hello, professor. I've been doing a implementation test of libOTe for a while now, and I've found the thread numbers for different protocols in ./frontend_libOTe are not the same.
Silent OT is tested under 4 threads, while IKNP doesn't have a parameter to describe how many threads are going to use in the function.
Are the protocols like IKNP can only work under only one thread, or there are some ways that can increase the thread number?