4 ms·

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

by dlsym 15y ago

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

keithwinstein 15y ago
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).
- deleted 15y ago
  [deleted]
dchest 15y ago
OpenSSL also had 8 vulnerabilities in 2012 -- http://www.openssl.org/news/vulnerabilities.html http://www.openssl.org/news/vulnerabilities.html.
- kragen 15y ago
  Maybe this is the place to plug http://nacl.cr.yp.to/ 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.
  - dchest 15y ago
    Plus, in NaCl there's a work-in-progress implementation of CurveCP protocol http://curvecp.org/ http://curvecp.org/, which works over UDP and seem to be a good fit for something like mosh.

by dlsym 15y ago

keithwinstein 15y ago

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).

deleted 15y ago
[deleted]

dchest 15y ago

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

kragen 15y ago
Maybe this is the place to plug http://nacl.cr.yp.to/ 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.
- dchest 15y ago
  Plus, in NaCl there's a work-in-progress implementation of CurveCP protocol http://curvecp.org/ http://curvecp.org/, which works over UDP and seem to be a good fit for something like mosh.