[zeromq-dev] [ANN] curvetls: a simple, robust transport encryption package

Manuel Amador (Rudd-O) rudd-o at rudd-o.com
Mon Sep 26 12:57:12 CEST 2016

Hello, folks!

I am announcing the first iteration of curvetls: a Go library that
provides a robust framing and encryption layer for your Go programs,
striving to be secure, strict, and simple.

With curvetls, it's dead easy to go from raw sockets to secure channels,
based on CurveCP (NaCL) encryption primitives, and you get framing for
free. This makes it dead easy for you to write secure, robust clients
and servers that do not need to implement low-level control flow at
all.  While curvetls is based on the CurveZMQ specification, it does not
depend on any ZeroMQ or CurveZMQ libraries itself.

This library gives you a layered, stackable wrapper (client / server)
for network I/O, which allows you to upgrade regular network sockets to
the curvetls protocol.  All the wrapper needs is a key pair, a random
nonce, and a socket whose underlying transport is of any reliable kind
(e.g. a TCP- or file-backed `net.Conn`).

So why did I write this?

  * For the longest time, there have been CurveCP implementations that
    have languished without being completed.  CurveCP would have been
    ideal, but there is no implementation for Go.  Even if there was
    one, or a binding, the CurveCP is a much deeper stack and its
    reference implementation uses an unsafe language.
  * ZeroMQ's CurveZMQ is not suited for writing secure software that
    must withstand hostile Internet conditions, because it allows an
    arbitrary number of connections, it provides no easy mechanisms to
    control access or to throttle connection attempts by clients, and it
    allows clients (which possess the server's public key) to consume
    arbitrary amounts of memory.  Additionally, it's almost impossible
    to use multiple goroutines for simultaneous send / receive on Go ZMQ
    sockets, requiring ugly hacks like using PAIR sockets to shuttle the
    data back and forth between threads.  I wrote the hack myself, and
    I'm not proud.

These problems have left Gophers like me with having to choose between no
encryption or the heavyweight TLS (with the associated key management
woes).    curvetls aims to fulfill that role.

There are a few things remaining to do, such as memory limitations to
protect the server (after the successful handshake) from authorized yet
misbehaving clients which send too much data on a single frame, as well
as a variety of tests I want to write, and integration tests to see how
the interoperability with CurveZMQ is doing.  At this time, clients
cannot consume arbitrary amounts of memory during the handshake, which
is good, but there's still room for optimization.

I hope you enjoy using curvetls as much as I enjoyed writing (and
continuing to further) it!

Without further ado: https://github.com/Rudd-O/curvetls

Don't forget to send bug reports and pull requests!


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160926/f462aef4/attachment.sig>

More information about the zeromq-dev mailing list