Are hardware encryption chips safer than their software counterparts for desktop apps? Wouldn't accessing the hardware encryption chip be safer than relying on an encryption library? 

My question is prompted as a response to @SqueamishOssifrage replying on the "Properly securing a private key for remote storage" post, item #6 (I don't have enough points to reply to their comment).

Quote:


  it takes a lot of effort to audit your software stack well enough to guarantee it is reliably using the hardware AES support on all 
  platforms that may be of interest to you.


If my desktop application is signed, wouldn't it be safer to use the chip?

Clarification based on answer received

yeah I'm basically looking for a secure solution to storing private keys. Your point #2, storing the key in the chip where the key never sees the light of day seems like the obvious solution. Thinking through what to do for potential problems (supporting different chips, a new vulnerability being found, etc.) makes that impractical for a small-time developer. At this point, implementing a software solution where keys perhaps are signed by multiple remote servers seems the way to go (you may compromise one remote server but can you compromise them all?). If there's a better design pattern than that, I would be interested in pursuing that. As it is, I don't trust a software implementation on a single computer to do it.
‘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.