Skip to content

Instantly share code, notes, and snippets.

@corollari
Last active April 23, 2020 15:35
Show Gist options
  • Save corollari/c7f5e698de2d69f36de955d7e8faef11 to your computer and use it in GitHub Desktop.
Save corollari/c7f5e698de2d69f36de955d7e8faef11 to your computer and use it in GitHub Desktop.
Rought draft of the report on mixnets & distributed stuff

Implementation strategies

  • nonblocking sockets on the client

Experiments

I’ve simulated packet loss by commenting out the code responsible of sending packets on the server and the results obtained are pretty much what anyone might expect, the removal of replies leads to clients requests being repeated and, when the server is using at least once invocation semantics,

Note from the author:

Security

  • udp being used to augment spam attacks
  • no cap on things such as response length which can lead to memory blowup + crash,
  • complete acess to filesystem
  • response history has unbounded growth but should have an eviction policy...)

Extra (mixnet + multithreaded + languages)

The system has been implemented using a mixture of languages, the client code has been written in python and the server in go.

Fixed-time algorithms for the serialization format have only been implemented in go for the decoding part, the rest of the algorithms are variable-time. The reason why these algorithms werent implemented on the client side in python is because their utility there is heavily diminished, as an attacker isnt able to get a time measurement of the time when decoding ended and when encoding started due to the fact that these events are not associated with packages being sent but with actions such as inputting a command or displayig something on-screen, actions that an attacker san’t monitor. The one case where these events are associated with network events are the ACK responses to usbscription updates, but in these cases all the information available is leaked by the behaviour of the client so having fixed-time algorithms wouldn’t help.

Encoding in go is variable-time instead of fixed because writing correct fixed-time algorithms turned out to be quite hard, and, given that the implementation was meant to only be a proof-of-concept, I thought it was more interesting to spend that time in other areas.

All encoding and decoding algorithms for all languages are unit tested.

While this was not required, the server I’ve implemented uses goroutines in order to handle parallel requests, therefore relaxing the assumption made in the lab manual that stated that client requests would be handled sequentially. The several goroutines in use are synchronized through mutexes and go channels.

Apendix

Graphs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment