There a several things I see that could make CurveZMQ a lot better. I would be happy to help, but these may require more knowledge of ZMQ internals than I know. Yet. Some of them may need a Curve mechanism version bump. In any case, I wanted to bring them up for discussion:
Message Size Limits It behooves a pubic server to not accept large messages until authentication happens. Without a message limit, unauthenticated clients can easily get the server use up all available memory. On the other hand. authenticated clients are trusted and should be able to send large messages. This asymmetry cannot be handled with a single ZMQ_MAXMSGSIZE. However, during the security handshake, we know exactly what size packages to accept. We just need to somehow communicate this to the lower levels. Memory Usage There is currently several large buffers that are only used during handshakes but kept for the whole session. 160 bytes per client on server. 288 bytes on client. By freeing these after handshake, we can increate the number of simultaneous client connections. Zero State Initial Connections The protocol enables the server to keep zero state until the client has authenticated. This would allow public servers to mitigate DOS attacks much more effectively. However, implementing this would require DEEP changes in ZMQ: socket, session, stream_engine, mechanism, and so forth. Invalid Message Handling After the handshake is completed, it seems to make sense to drop invalid messages rather than killing the entire connection. I tried to return a simple EAGAIN instead of EPROTO, but this just prevented the server from processing messages. Message Command Currently, after the handshake, CurveZMQ sends messages back and forth prefixed with a "\7MESSAGE". Do we really need to have this for EVERY message? Certificate Exchange It would be nice to have a protocol level mechanism for exchanging certificates before authentication. This is not about certificate format or validation mechanisms, just a way to exchange the cert blobs and call on the application to do validation. I am currently working on a proof-of-concept and will share more with the group later. Crypto Library tweetnacl - very small, adequate speed and cross-compatibility. This is already included with zmq, but only the CMAKE tools use it. I think this should included in the build by default for both CMAKE and autotools libsodium - better cross-compatibility. May be slightly faster than tweetnacl. May be an option to use if tweetnacl cannot compile correctly nacl - fast, hard to compile. Maybe an option for those who want the fastest speed. Does not include ed25519, but that is not used explicitly by libzmq.
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
