Hacker News new | past | comments | ask | show | jobs | submit login

Nah

Specifically, "nah with OpenSSL on AMD or Intel boxes from the last decade":

    AES-128 (ctr mode)  9.7 GB/s
    AES-256 (ctr mode)  8.6 GB/s (90 % as fast,
       not ~70 % as 10-vs-14 rounds would naively suggest)

    AES-128 (gcm mode)  12.4 GB/s
    AES-256 (gcm mode)  10.8 GB/s
(plain CTR is slower than GCM because the GCM implementation in OpenSSL has received more attention than the counter mode implementation, simply because standalone counter mode is used a lot less)

And this is just one core anyway. How many 100 GbE ports are you running per core?

I keep reiterating this because crypto=slow is still a very common idea from the days when AES-128 would peg a core running at 40 MB/s, rcp actually was 3x faster than scp, http:// instead of https:// would actually meaningfully reduce load, SMB/NFS encryption would actually slow things down and it was a bog to actually use a system running with LUKS-encrypted drives. But that's not the case any more. Encryption is really really fast and has been for about ten years, depending on what you're looking at exactly. Nowadays even many microcontrollers have AES acceleration because - internet of things mainly.




It was a trick on my part to ask a leading question I already knew the answer to for others to provide the details as I didn’t have it handy :)

Asymmetric encryption remains “slow” but symmetric is within an order of magnitude of a memcpy.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: