Hacker News Reader

Comment by robert_foss | Hacker News Reader

There are data-dependencies in most AES modes (except ecb) which prevent parallelization. If you however run 2k separate AES encryption streams you could expect a nice performance increase. But for a single stream there is little performance to be had.

View on HN

We run tens of thousands of streams in parallel.. So that's not a problem. :)

I'm just realizing that GPUs could be a viable alternative to specialized (eg, expensive) encryption offload engines or very high end (eg, expensive) v4 Xeons with many, many cores. However, it is rather hard to find data on the bandwidth at which GPUs can process a given cipher. I'm just now starting to look into this, so I could very well be mis-understanding something,

Throughput 100% depends on how hard they need to hit memory. GPUs love stuff that they can do entirely within registers. Having to hit (the limited quantity of) shared memory slows things down much more. Inefficient/non-coaslesced use of shared memory or global memory too often can trash performance. Hitting host/CPU memory in any non-trivial amount usually dooms a program.

With each step you not just cut down your bandwidth but also you increase your latency and that has a huge impact.

Guys have a look at SSLShader[1]

[1]: http://shader.kaist.edu/sslshader/

Thanks!

What about a stream cipher like ChaCha20?

Also would data-dependencies be different on a GPU than with parallelization on a CPU? Because modes like GCM (i.e. CTR) both the encryption and decryption are parallelizable (with CBC it's just decryption).

I wonder if AMD GPU's would be better suited to the task than Nvidia's (at least their existing GPU's) provided you could actually saturate the GPU with enough work to make it worth it.

Reply on news.ycombinator.com