‘Hardware encryption chips’ could mean a couple different things: it could mean
- hardware that simply computes cryptographic operations with keys fed in by software, like Intel's AES-NI CPU instructions; or
- hardware that stores keys and computes cryptographic operations in them with defensive measures to prevent anyone from ever extracting the keys, like a YubiKey USB device or an HSM.
What I was addressing in the earlier post was only the first type.
If you can take advantage of your CPU's (say) AES and GHASH hardware, then it is probably faster and less vulnerable to timing side channel attacks than software AES.
But it's a lot of engineering work to audit the entire software stack in all instantiations that might arise to ensure that you really are taking advantage of the hardware—because,
- for compatibility, software stacks usually have software fallbacks; and
- for performance except in sensible software like BearSSL, software fallbacks are usually faster but leaky by default; and
- timing side channels are usually silent meaning you won't ever notice the problem until someone on the other side of the planet steals your money through a leak in your Bitcoin wallet software.
Of course, you can get almost the same performance and essentially the same side channel resistance just by using ChaCha and Poly1305 instead, and then you don't have to do all that engineering and auditing work because the widely available ChaCha and Poly1305 software tends to resist timing side channels already, and you get a better security margin because ChaCha is a better design, and your software will be usable securely on a wider variety of platforms.
So, if you're choosing a cipher for a new protocol, then this argument favors ChaCha or XSalsa20 and Poly1305 over AES-GCM in order to avoid needing hardware for fast security. But if you're choosing an implementation when your protocol has already chosen AES-GCM, then it's safer to use AES-NI or similar to compute it if you can.
As for hardware devices that store keys, well, it's great if you can do that because then malicious apps on your phone/laptop/exobrain/advertisementIVdrip can't steal the keys.
But it also means someone can't just use your awesome app with a one-click install from the app store; instead they may have to carry around a physical device, or you may have to deal with vagaries of platforms like TPM in laptops and SE in iPhones and so on.
So it's more engineering work and usability hurdles. Which may be worth the security benefit! It's up to you as an engineer to make informed decisions about these tradeoffs, using particular information about your intended audience, usage, etc.
