Hello, Gophers!
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 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!
--
Rudd-O
http://rudd-o.com/
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
