[go-nuts] Go AES performance

[Taru Karttunen]

Go AES performance

Go uses an AES implementation written purely in Go that is optimized
for correctness. Needing some crypto performance I compared the
different encryption modes to each other.

This is meant as informative if other people end up needing
some crypto performance. Note that the numbers will vary
wildly depending on the machine (the test was run on amd64,
warm cache, 5 runs of 16mb the last 4 of which were measured,
no spikes observed and averaged into the numbers).

| AES-128-ECB encrypt | 34.73MB/s |
| AES-128-ECB decrypt | 39.93MB/s |
| AES-128-CBC encrypt | 27.17MB/s |
| AES-128-CBC decrypt | 28.55MB/s |
| AES-128-CTR encrypt | 31.66MB/s |
| AES-128-CTR decrypt | 32.68MB/s |
| AES-128-OFB encrypt | 31.64MB/s |
| AES-128-OFB decrypt | 32.89MB/s |
| AES-128-CFB encrypt | 2.06MB/s |
| AES-128-CFB decrypt | 2.12MB/s |
| AES-128-EAX encrypt | 16.57MB/s |
| AES-128-EAX decrypt | 16.85MB/s |

| AES-256-ECB encrypt | 27.32MB/s |
| AES-256-ECB decrypt | 30.69MB/s |
| AES-256-CBC encrypt | 22.46MB/s |
| AES-256-CBC decrypt | 23.49MB/s |
| AES-256-CTR encrypt | 25.41MB/s |
| AES-256-CTR decrypt | 26.18MB/s |
| AES-256-OFB encrypt | 25.63MB/s |
| AES-256-OFB decrypt | 26.29MB/s |
| AES-256-CFB encrypt | 1.65MB/s |
| AES-256-CFB decrypt | 1.68MB/s |
| AES-256-EAX encrypt | 13.23MB/s |
| AES-256-EAX decrypt | 13.41MB/s |

CTR and OFB modes seem to lead in performance followed closely by
CBC. CFB is very slow. EAX does two encryptions per block encrypted so
the performance is expected. Maybe using CTR+a hash instead will speed
things up?

| RIPEMD160 | 43.00MB/s |
| SHA1 | 59.54MB/s |
| SHA256 | 37.14MB/s |

Seems like it.

- Taru Karttunen

[Paolo 'Blaisorblade' Giarrusso]

On 11 Mag, 11:06, Taru Karttunen <tar...@taruti.net> wrote:
> Go AES performance
>
> Go uses an AES implementation written purely in Go that is optimized
> for correctness. Needing some crypto performance I compared the
> different encryption modes to each other.
>
> This is meant as informative if other people end up needing
> some crypto performance. Note that the numbers will vary
> wildly depending on the machine (the test was run on amd64,
> warm cache, 5 runs of 16mb the last 4 of which were measured,
> no spikes observed and averaged into the numbers).

For the sake of safety, I'd remind that ECB is of no practical use, so
benchmarking it serves just as a comparison for other modes.

[⚖ Alexander "Surma" Surma]

> For the sake of safety, I'd remind that ECB is of no practical use

Really? I always assumed that hard disk encryption software (like
lvm-crypt) uses ECB.
Am I mistaken?

Surma

[Taru Karttunen]

- Taru KarttunenOn Wed, 12 May 2010 14:23:01 +0200, "=?UTF-8?B?4pqWIEFsZXhhbmRlciAiU3VybWEiIFN1cm1h?=" <alexand...@googlemail.com> wrote:
> Really? I always assumed that hard disk encryption software (like
> lvm-crypt) uses ECB.
> Am I mistaken?

Yes, you are mistaken. ECB should not be used by itself, it is a
building block for other modes. It was contained in the comparison
to get the speed of the raw implementation as compared to the
various usable modes.

- Taru Karttunen