reliable message transportation with randomized retransmissions
kaetzchen query support
cryptographic persistent storage
So far we've got a very rough draft client with no state persistence to disk, and currently it only supports kaetzchen queries; it not only needs more code... it needs a code cleanup ;) This library really SHOULD use the golang standard context package for implementing timeouts and cancellations.
https://github.com/katzenpost/client
The scope of this library should be quite small. It will not perform any end to end encryption except the sphinx encryption of the packets. It will definitely NOT utilize any keyserver. These are very clearly not our problem. This library is essentially a message orientated transport library. Application developers are certainly able to couple it with encryption schemes.
This library will require some information about the mixnet and the "user account" on the provider:
PKI information
Provider pinned key
username on local Provider
private link key for user on local Provider
username on remote Provider
private link key for user on remote Provider
The fact that I have used "link key" should not be confused with their usage. The client does NOT use the remote link key for link layer authentication because the client only connects to it's local Provider. The remote Provider is used for receiving messages... as a deaddrop which gives us our location hiding properties.
It is now time to point out that clever uses of the bytes comprising the username is also OUT OF SCOPE. This library gives zero thoughts about such things as it's only concern in life is the transportation of Sphinx packets. It's fine if application developers want to stuff a self signed certificate into the username but we aren't going to do that kind of thing here. This will NOT be a kitchen sink monolithic beast of a library. Instead it is meant to be used in composition with other components.
This transport protocol library should support unreliable and reliable transmissions. If using the reliability then the library would also dedup spurious retransmissions. On the other hand I'm not sure if we should include a fragmentation scheme or not. Fragmentation could instead be handled by the calling party.
Furthermore, we need to decide if the library will handle it's own channel maintenance and rotation of dead drops. I think it should not do so. It also does not handle exchanging dead drop addresses between clients. These are all prerequisites for using such a transport library. I can for example pair this library nicely with the PANDA protocol such that e2e keys + dead drop locations are exchanged.
Let's write a decent mixnet client library with:
So far we've got a very rough draft client with no state persistence to disk, and currently it only supports kaetzchen queries; it not only needs more code... it needs a code cleanup ;) This library really SHOULD use the golang standard context package for implementing timeouts and cancellations. https://github.com/katzenpost/client
The scope of this library should be quite small. It will not perform any end to end encryption except the sphinx encryption of the packets. It will definitely NOT utilize any keyserver. These are very clearly not our problem. This library is essentially a message orientated transport library. Application developers are certainly able to couple it with encryption schemes.
This library will require some information about the mixnet and the "user account" on the provider:
The fact that I have used "link key" should not be confused with their usage. The client does NOT use the remote link key for link layer authentication because the client only connects to it's local Provider. The remote Provider is used for receiving messages... as a deaddrop which gives us our location hiding properties.
It is now time to point out that clever uses of the bytes comprising the username is also OUT OF SCOPE. This library gives zero thoughts about such things as it's only concern in life is the transportation of Sphinx packets. It's fine if application developers want to stuff a self signed certificate into the username but we aren't going to do that kind of thing here. This will NOT be a kitchen sink monolithic beast of a library. Instead it is meant to be used in composition with other components.
This transport protocol library should support unreliable and reliable transmissions. If using the reliability then the library would also dedup spurious retransmissions. On the other hand I'm not sure if we should include a fragmentation scheme or not. Fragmentation could instead be handled by the calling party.
Furthermore, we need to decide if the library will handle it's own channel maintenance and rotation of dead drops. I think it should not do so. It also does not handle exchanging dead drop addresses between clients. These are all prerequisites for using such a transport library. I can for example pair this library nicely with the PANDA protocol such that e2e keys + dead drop locations are exchanged.