6 ms·

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 updat

by 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.

by snaky 8y ago

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.