4 ms·

I wonder if FPGAs would make good crypto devices, e.g. for disk encryption? If you implement AES on an FPGA, is it fast enough to keep up with at least a SATA 3

I wonder if FPGAs would make good crypto devices, e.g. for disk encryption? If you implement AES on an FPGA, is it fast enough to keep up with at least a SATA 3 SSD?

aswanson 8y ago
Yes, they are used extensively in crypto applications for precisely that reason.
anfilt 8y ago
Yea some FPGAs could do that.
pmalynin 8y ago
I thought that CPU’s with AES-NI can already keep up. EDIT: in fact I just looked up some benchmarks for Ryzen and it can do 3GB/s per core. So that should be enough
- floatboth 8y ago
  It's not about performance. (Perf is necessary, not the goal.) Doing crypto on a separate chip lets you keep they key away from system RAM and CPU cache, removing any possibility of leaks into other programs.
- Timmah 8y ago
  Just because it can doesn't mean it's tolerable to have one core of their CPU eaten up just working on AES all day. Plus if it wasn't task set to a CPU you'd see massive latency hits on disk access even the CPU could keep up. The kernel still has to schedule the task and load balance.
aseipp 8y ago
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.
- snaky 8y ago
  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.
  - aswanson 8y ago
    Hilariously, the update mechanism likely opens an attack vector.
  - aseipp 8y ago
    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.
- floatboth 8y ago
  The FPGA advantage I was thinking of is that FPGAs are not covered by any crypto export regulations in any country. As well as the possibility of the crypto "code" (HDL) being open source.

I wonder if FPGAs would make good crypto devices, e.g. for disk encryption? If you implement AES on an FPGA, is it fast enough to keep up with at least a SATA 3 SSD?

aswanson 8y ago

Yes, they are used extensively in crypto applications for precisely that reason.

anfilt 8y ago

Yea some FPGAs could do that.

pmalynin 8y ago

I thought that CPU’s with AES-NI can already keep up. EDIT: in fact I just looked up some benchmarks for Ryzen and it can do 3GB/s per core. So that should be enough

floatboth 8y ago
It's not about performance. (Perf is necessary, not the goal.) Doing crypto on a separate chip lets you keep they key away from system RAM and CPU cache, removing any possibility of leaks into other programs.
Timmah 8y ago
Just because it can doesn't mean it's tolerable to have one core of their CPU eaten up just working on AES all day. Plus if it wasn't task set to a CPU you'd see massive latency hits on disk access even the CPU could keep up. The kernel still has to schedule the task and load balance.

aseipp 8y ago

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.

snaky 8y ago
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.
- aswanson 8y ago
  Hilariously, the update mechanism likely opens an attack vector.
- aseipp 8y ago
  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.
floatboth 8y ago
The FPGA advantage I was thinking of is that FPGAs are not covered by any crypto export regulations in any country. As well as the possibility of the crypto "code" (HDL) being open source.