Most of the time when someone posts a "look what I just implemented in C" to HN it's, well, not great. As I mentioned I only looked for five minutes, but I looked for really basic general programming errors, low-hanging fruit kind of stuff. That's enough to effectively cull a lot of the noise that gets posted here.
His code is good - I just wonder why someone'd go to the effort (which is much higher than most other programming projects, due to the consequences of a bug) when we already have well-worn codebases for stuff /almost/ exactly like this, considering the tightrope-of-vigilance that is correctly implementing crypto protocols.
I understand now that he wants a PSK vs. stunnel/TLS's certs-on-both-ends method, but effectively it only really differs in connection setup, as TLS (the way I understand it to be generally used) does symmetric crypto for the payload data anyway (after key setup).
PS: His project is the first time I've encountered the use of gotos resulting in _cleaner_ code than without them. :)
It wasn't that much effort. Almost everything under /lib/ I had already written as part of tarsnap or kivaloo; I spent maybe 10 hours making minor tweaks and cleanups to that code (which will be useful when I next use the library code anyway) and somewhere around 40 hours figuring out the protocol and writing the spiped specific code.
Having a simple secure pipe tool will save me far more time than that, once you count things like wanting to programmatically set up encrypted pipes (for which spiped's command line and arbitrary key is much better than stunnel's configuration file and SSL certificates).
effectively it only really differs in connection setup
And connection setup is a big deal. That's where almost all the vulnerabilities happen. In SSL, you go through a complicated handshake before you can decide that the client you're talking to doesn't have the right keys; in spiped, you exchange 256-bit nonces, and then if the very next buffer you read doesn't have right right HMAC, the connection is dropped. Evil data never meets asymmetric crypto. If an attacker doesn't have the key, they can't force you to burn any significant amount of CPU time.
I didn't reach any conclusion from my quick look, but was definitely put off by the "it's big so it must be insecure" view taken by the author.