[POC] Secure channel abstraction

[yanndupis]

Hey @mortendahl @jvmncs ,

Here is an initial draft with the new abstraction for the secure channel. Let me know if it's moving to the right direction.

Thank you!

[jvmncs]

let's discuss in person, I have some further comments on finding the right abstraction for channels. I'd like to also go over how this might eventually be exposed to the user (taking some pointers from Morten's earlier recommendations)

also note I have not verified the encrypt/decrypt work just yet -- I made sure that the key generation was happening in such a way not to leak secret keys, but otherwise am assuming there haven't been too many significant changes to that. should be worth another look during next round of feedback.

[jvmncs]

I was thinking that the signature could be _move(self, arg, source_placement, target_placement) or similar. channel should be referencable from self (the Strategy)

[yanndupis]

good point, that would make more sense.

[yanndupis]

Hey @mortendahl @jvmncs ,

Quick status on this. I have made good progress but it's not completely done. I still want to add more tests, review the code again, potentially add ChannelGrid as discussed with Jason. Feel free to take a look to validate it's moving to the right direction or if you want provide suggestions. Once I finalize this and it's reviewed, we will move the code to the new repo.

Thank you!

[mortendahl]

hi @yanndupis, I've added a few comments; perhaps it makes sense to do a quick design sync

[mortendahl]

what is value here? how does it relate to the return value of receive?

[yanndupis]

value is list of EagerValues and it was returning a FederatingExecutorValue. I changed it to return a list of EagerValues.

I have the same pb with _encrypt_values_on_sender. However not sure yet, how to keep this Federatedtype check (if needed) if I return a list of EagerValues after encryption.

[yanndupis]

Hey @mortendahl , thanks for you! sounds good let's do a quick design sync.

[yanndupis]

Hey guys,

First of all, thank you for the review! I have addressed most of the comment (still have 2-4 for tomorrow).

However, I still have a Channel object per pair of placements. I need to investigate more tomorrow. But it seems we could have a channel per pair of executors. If that's possible, that could simplify the code. For each channel, each executor would have their key pair. Potentially I wouldn't need to use _place_key just need _place. And also wouldn't need this, sender and receiver in send and receive.

I just don't know yet how to structure ChannelGrid and if i am missing potential complications.

Thank you!

[yanndupis]

Hey guys,

I clean up a bit more, added specific tests to test Channel functionalities etc.

I have started to move the code to the tff-aggregations repo: tf-encrypted/federated-aggregations#1.

I will continue to work on this on Monday.

Regarding having Channel per pair of placements vs per pair of executors, after chatting with Jason, we decided to keep per pair of placements in this branch. Still open to discussion if we want to take the other approach but we can do this in the tff-aggregations branch.

thank you!