Hacker News Reader

Comment by dlsym | Hacker News Reader

    > 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?

View on HN

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.

Reply on news.ycombinator.com