search

mchlnix / PyMix

A mix chain implementation in Python using UDP
0 stars 0 forks source link

Introduce link encryption #2

Closed mchlnix closed 6 years ago

mchlnix commented 6 years ago

The channel IDs in front of the mix-fragments are clearly visible. This is an unnecessary risk and should be avoided by link encrypting at least the first 'blocksize' bytes of the message.

mchlnix commented 6 years ago

This could be even more necessary, if the IV or the CTR start value is transferred in the open as well. What kind of cipher would that be, though? Simplicity would mandate not to mix block ciphers and asymmetric encryption is costly, even if used in a hybrid fashion.

mchlnix commented 6 years ago

The way the symmetric encryption works now, sending the CTR prefix value in the open is not a problem, since the key and the actual CTR start are still secret. A new problem is the possibility of correlating channel in with channel out IDs, simply by observing enough input and output sets of messages.

By cross referencing the output batches every time a channel of interest is observed to enter, it is possible to find a common output channel id given enough time. This can feasibly only be avoided by rotating the channel IDs often enough or by encrypting them as well.

Since the CTR prefix values are correlated as well the same solution should apply to them.

mchlnix commented 6 years ago

In regards to what mode of operation to choose for the link encryption: It can't be a stream cipher, since UDP is the underlying protocol. There is the CBC with explicit IV variant, that DTLS uses, which would add another block size of unnecessary data between the Mixes. Since the Channel ID, which is constant, and the Counter Prefix, which changes each time deterministically, is the plain text, maybe a simple ECB mode would be defendable. It would have to be shown, that the chance of a repeat block within the lifetime of a channel is close to zero (since the CTR prefix values should never repeat, that is a given) and that the chance of the same channel ID and CTR prefix combination occurring together over time is also very small.

4 Byte Channel ID + 8 Byte Counter Value, 2**96 possibilities. Maybe with 4 extra byte just being random?

mchlnix commented 6 years ago

Link encryption should also help with #10

mchlnix commented 6 years ago

Would it be too costly to just use DTLS between the Mixes and the Client etc? If not, then that would seem like a good solution.

mchlnix commented 6 years ago

The link encryption we now use is based on AES_GCM. The channel ID and the message ctr used for encrypting the message are filled up with reserved bytes to get to the block size of 16 Byte. Then it is encrypted with a previously shared symmetric link key and a random nonce, that is then prepended and send in the clear.

Since we don't use replay detection on the link level, sending it in the clear and choosing the nonce randomly is not a problem.