Proposal for adding aes-ctr method in spec.

[itsuki-hayashi]

AES in CFB mode is not supported by WebCrypto in major browsers, so to implement a Chrome OS version of Shadowsocks, developers have to do encryption in JavaScript, which is slow even with asm.js(about 40MiB/s+ vs 300MiB/s+ with modern x86 processor, could be 1GiB+ with AES-NI intrinsics).
AES in CTR mode is supported by most WebCrypto implementations, and it is trivial to implement in most server side implementations of shadowsocks.
Some implementations(e.g shadowsocks-chromeapp) already have CTR mode support. I think it is best to add CTR mode to spec.

[Mygod]

LGTM. Related information.

[madeye]

LGTM. Added via shadowsocks/shadowsocks-libev@9e407a9

[nekolab]

Thanks for your proposal.

Actually the bottleneck of chrome app is not only at the crypto performance, the design of JavaScript socket API and the V8 GC are also terrible for the heavy data traffic. That's the reason why I put the emphasis on the native client version. You can see further discussion here: shadowsocks/shadowsocks-chromeapp#21, shadowsocks/shadowsocks-chromeapp#15 and
shadowsocks/shadowsocks-chromeapp#1.

But even there are many weak points in chrome app, I still think use WebCrypto API instead of JS library like forge is necessary, so, LGTM.

[itsuki-hayashi]

@meowlab FYI https://bugs.chromium.org/p/chromium/issues/detail?id=585566 dskaram is working on a PPAPI for AES-NI. This might be useful for your NaCl version.

[nekolab]

@edsgerlin Wow, that's great. Thanks for letting me know that.

[wongsyrone]

Added in shadowsocks/shadowsocks-windows@2fafc52

[librehat]

Added for Qt implementation shadowsocks/libQtShadowsocks@2959fff

[wongsyrone]

@madeye I think it is time to add this to the website.