Open mikelsr opened 1 year ago
I need to keep going so for the time being I will be using standard protocols and doing the key-pair thing, but sooner or later this will need to be changed.
I went ahead and implemented it with RSA and the results were... disastrous :,)
In my i7-6700K forking a process takes almost 1 second, 90% of which is singing and encrypting a message from inside a WASM guest and another significant chunk is generating a new key pair for each new process. I am discarding this idea and finding a new approach. Any help is welcome!
I will however create a tag for this version of the code in my local fork so I can reproduce it to document the performance results.
An efficient executor implementation requires some sort of process tree. I have implemented the tree in this branch, but populating it is another issue.
@lthibault @aratz-lasa or anyone else, atm I can't figure out a way of implicitly discerning who is making the call and deducing the callers PID (if it has one) from there.
As an alternate path I though about adding a
ppid
parameter to theexec
call, whereppid
is thepid
of the process making the call. Each process would know its ownpid
. This means theppid
is easily forge-able, and processes can pass themselves as other processes, evenpid=0
which is thePID
reserved for the executor.The solution might be for both executor and processes to have a prv/pub key pair, so the process calling
exec
signs theppid
with its private key and encrypts it with the executor's public key.Would you mind giving it a thought to see if we can come up with a better approach? If not, do you know of any lightweight encrypting and signing protocols? Thank you in advance, look forward to hearing your opinions! Ping me in Matrix for quick conversations :)