Yes, they can do traditional cryptography pretty well (depending on the algorithm, of course.) AES-128 in an FPGA can encrypt a full 16-byte block every clock cycle when done right. With 100Mhz clock that's about 2.3Gbp/s, well within SATA 3 transfer speeds. You can achieve that with a last-last-gen FPGA that will cost you a couple bucks out of pocket, and it will use a fraction of the power/thermal footprint of any desktop/mobile processor that doesn't have AES support. Likewise, you can easily scale this up -- 10gig/s isn't even worth mentioning because it's trivial, so you can think closer to 40Gbp/s and beyond (which, today -- still not that impressive, I'm just giving you an idea.)
The thing is, if you're going to do ubiquitous encryption for something like your SATA link at scale, with a lot of units being sold -- you're better off just using a dedicated ASIC with a fixed algorithm, and your performance/power profile will skyrocket even further.
Or maybe, if you're going to do ubiquitous encryption for something like your SATA link at scale, with a lot of units being sold, it would be nice to only update the FPGA firmware when the exploit will be found in the implementation of your crypto.
But no hardware engineer would think of it that way in such a hypothetical product scenario, if they were designing it. Because:
- If many units are being sold, BOM choices matter. People optimize part choices down to fractions of a penny on individual units when scale is large; ASICs and FPGAs are differences in dollars, it's a completely different order of magnitude. Power usage is similarly important for the same reasons. Cost is king, and nobody will buy/integrate your 20x more expensive SATA adapter when another alternative exists that does the same job, cheaper, faster, with lower power. So what about all that alleged 'security' advantage when nobody uses your chip at all?
- There is no indication cryptographic agility is actually advantageous for any given design, it can only be assessed in the context of a threat. It may in fact be a detriment due to exposing further attack surface (e.g. you now need a secure update mechanism). This is important because the design phase is absolutely critical and takes substantial amount of the overall development/market time -- so you don't introduce extra complexity if you don't have reason to believe you need it. (And it's also why you just tend to buy many components from other vendors, because paying a bill to them is cheaper than paying your engineers to recreate everything while assuming they won't fuck up. I'd guess that very few actual FPGA/RTL engineers actually implement AES cores outside of university, as opposed to just reusing an existing one...)
Ultimately all of this comes down to your design requirements for the product, but flexibility can come with costs and in terms of money it definitely is not free.
The thing is, if you're going to do ubiquitous encryption for something like your SATA link at scale, with a lot of units being sold -- you're better off just using a dedicated ASIC with a fixed algorithm, and your performance/power profile will skyrocket even further.