Hacker News Reader

Comment by forgotusername | Hacker News Reader

There are 101 million ways to screw these kinds of protocols up, that's why I'm sceptical. There are too many avenues to list, but here are a few:

* Security product written in C++, leveraging 2 huge libraries (Google protocolbuffers, Boost)

* One man band by the looks of it

* Includes its own private crypto code (has rijndael-alg-fst.cc been vetted for timing issues?)

* Implements its own private crypto protocol (has it been vetted for replay attacks? padding attacks? [insert 20 years of perplexing bugs confounding the greatest minds in computer science]?)

etc.

And besides all that, this page is begging you to download it. It ticks every box: sexy Bootstrap design, prepackaged installers for every OS, and not one mention of a single downside! That raises the question: what is the author's agenda? (At a guess, school cred, but still, this isn't reason enough for me to swap out something as critical as SSH)

View on HN

We certainly welcome your eyes on the code. Any novel secure datagram protocol is going to have to prove itself; this one is no exception. Of course we think the radical simplicity of the design is an advantage, but of course others have thought that and have been wrong. So it's going to take time for everybody to get comfortable with it.

Regarding the Web site, I think Hacker News is able to take a little ribbing. You guys are always throwing up these twee Web sites; surely the free software community can have a little fun with the genre. :-)

From my limited perspective the code actually looks quite clean (although often this is the very quality that hides the worst of bugs!). One issue with UDP is dealing with NATs and firewalls (for example, in public WiFi hotspots where SSH is often permitted, but random other ports are not). The dependency on protocolbufs seems a little redundant given the size of your protocol (that is one huge library to import for the sake of 24 fields).

Will definitely give this a whirl at some stage, as the feature set is quite compelling, and assuming it gets healthy reviews from the talented crypto folk on HN. :) Good luck!

It’s good to be careful and perhaps a little skeptical when there’s a new approach that’s not the tried and true ssh.

The quote from the homepage tells me they get it:

Why you should trust Mosh with your remote terminal needs: we worry about details so obscure, even USENIX reviewers don't want to hear about them.

Agreed on the protocol buffers; that's a huge overkill for what it is used for.

    > Includes its own private crypto code (has 
      rijndael-alg-fst.cc been vetted for timing issues?)

This is as far as I can tell the original rijndael-alg-fst.c reference implementation, which has cache timing issues in the S-Box table lookup.

The crypto/aes/aes_x86core.c implementation from OpenSSL uses pre-fetching as a countermeasure.

[Edit: Better formulated as a question? :-)] Since OpenSSL is a long tested and optimized library, why did you decide to ship an own aes implementation?

We'll have to study this. The practical reason for using the rijndael reference code is that ocb.cc is only written against three interfaces: OpenSSL (which we can't ship currently for licensing reasons -- we depend on GPLed code), the rijndael reference implementation, and compiler AES intrinsics (which we don't have on most architectures).

Down the road we may end up making a shim to use GnuTLS or figuring out how to ship as GPL+OpenSSL exception.

The practical exposure to information leakage via timing attacks is pretty controlled, since we just ignore any datagram that fails the authenticity check and we generally only send outgoing packets per a timer (whose smallest value is 1/50 second).

OpenSSL also had 8 vulnerabilities in 2012 -- http://www.openssl.org/news/vulnerabilities.html.

Maybe this is the place to plug http://nacl.cr.yp.to/, by at least one author who has an excellent track record of shipping software with very few vulnerabilities. And who discovered the S-Box cache timing vulnerability mentioned upthread.

If you have the freedom to invent your own encrypted network protocol, instead of having to be backwards-compatible with SSL or SSH, you should seriously consider NaCl as an alternative.

Plus, in NaCl there's a work-in-progress implementation of CurveCP protocol http://curvecp.org/, which works over UDP and seem to be a good fit for something like mosh.

>Security product written in C++, leveraging 2 huge libraries (Google protocolbuffers, Boost)

Protocol buffers is heavily scrutinized and as for Boost, the way it's designed means that it only pulls in what you use. The project seem to only use very little of Boost anyway, so I wouldn't bother too much about it.

More surprising, I can see it does not use Boost.Asio for networking (strange ?). It seems to use Boost for things like Boost.Lambda (deprecated with C++11) and typeof.

I think the project could benefit from leveraging the Boost libraries more or just not use them at all.

Examples: use Boost.Spirit for Base64 and replace the custom made parser. Don't use malloc to allocate raw pointers but use strings, vectors or smart pointers. Replace the networking code with Boost.Asio (which is portable). etc.

Reply on news.ycombinator.com