3 ms·

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

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.

drewg123 10y ago
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,
- paulmd 10y ago
  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.
  - serialx 10y ago
    Guys have a look at SSLShader[1] [1]: http://shader.kaist.edu/sslshader/ http://shader.kaist.edu/sslshader/
    - nwrk 10y ago
      Thanks!
ryuuchin 10y ago
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.

drewg123 10y ago

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,

paulmd 10y ago
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.
- serialx 10y ago
  Guys have a look at SSLShader[1] [1]: http://shader.kaist.edu/sslshader/ http://shader.kaist.edu/sslshader/
  - nwrk 10y ago
    Thanks!

ryuuchin 10y ago

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.