5 ms·

This just isn't true. Nearly every SoC you can buy today has hardware accelerators in it, from STM32s up to Xeons. You have to be looking at really tiny, gener

This just isn't true. Nearly every SoC you can buy today has hardware accelerators in it, from STM32s up to Xeons. You have to be looking at really tiny, generally pretty old micros before you literally don't have any. On top of that, hitting hardware speeds by putting in faster cores just isn't a thing for most parts. It's pretty easy to get 8-9x throughput wins on many primitives with a hardware accelerator, but getting a similar improvement just by getting bigger chips is often impossible and always expensive.

anon4242 7y ago
> Nearly every SoC you can buy today has hardware accelerators in it True, but few are full-featured HW acceleration SoCs. Most support a few operations like for instance AES-ECB and maybe AES-CBC but if you want AES-CCM or AES-GCM you still need to implement parts of it in software. The HW may be super fast at ECB:ing many blocks of memory but the setup cost is steep so when you need to ECB just a single block (for your counter in CCM) it buys you very little performance gains over just ECB in SW. (Of course what you do then is setting up several counters in a larger block of memory, after each other, this is ok because the counters are just increments, and you ECB a bunch of blocks. Next you need to solve how to do the same to get CBCMAC with just CBC HW...)
- debatem1 7y ago
  This is just moving the goalposts. First it was "crypto accelerators are rare because ITAR", now it's "crypto accelerators are rare because they don't buy you much". Neither is true. Crypto accelerators are extremely common, including those that implement full cryptosystems or even complete protocols. Nearly every wireless part will have them (especially for CCMP), as well as basically every modern+common consumer device SoC (eg, all Qualcomm, Samsung, Apple, AMD, and Intel parts). Several of these actually have overlapping accelerators for eg memory encryption or wireless (full protocol) and acceleration instructions like those for ARMv8. And they are there because they work. Setup cost is a thing, but A) is largely paid when you rekey and therefore rarely for most protocols, B) is acceptable in many protocols because you can interleave other operations to prevent port contention without sacrificing throughout, and C) is often buried by the cost of a very small number of blocks, or even just one.
  - snagglegaggle 7y ago
    He didn't move the goalposts and usefully expanded on my point. Those devices you're talking about notably adhere to other external standards and are not typically user reprogrammable (where user is the integrator). Also important is that I would not consider them secure in general due to the standards they implement. You also certainly realize that their power consumption, when present, massively dwarfs the type of processor we were first discussing? By the time you get to the ARMv8 accelerators, yes, you're going to exactly the same place I was arguing we should go with my original comment. There's actually a number of primitives that could be reused for various systems.
    - debatem1 7y ago
      The original claim was that these parts were rare because of ITAR. They aren't rare, and ITAR doesn't have much to do with where they're present or absent. Shifting the argument to a different point about a specific accelerator or specific class of parts is exactly as I said: moving the goalposts. The question of whether they're user programmable or not is nearer to the mark because EAR cares about it, but it still doesn't present a formidable barrier-- at least, I've been shipping parts with crypto accelerators at various levels of user configurability for a long time, and so has everybody else.
  - anon4242 7y ago
    > Setup cost is a thing, but A) is largely paid when you rekey Well, it depends on the crypto HW. Some HWs are designed for "throughput", which is completely useless for ECB but looks good on specs ("Our HW AES 10MB/s!"). So you set it up with src, dest and key pretty much as you setup your typical DMA transfer, only you almost never want to encrypt more than 16 bytes at a time with ECB so it's mostly wasted. > consumer device SoC (eg, all Qualcomm, Samsung, Apple, AMD, and Intel parts) We are not all so fortunate that we get to work with such powerful SoC. In my job it's mostly small embedded MPUs. > B) is acceptable in many protocols I think we are talking past each other here. I haven't even gotten to the protocol part yet. In order to support a wireless and/or network protocol you will need better building blocks than AES-ECB. You need AES-GCM (or at least AES-CCM). Not to mention ECDSA or RSA(>=3072)...
raxxorrax 7y ago
That is an exaggeration in my opinion. Many µC don't have a real use case for encryption as well as many sensors. Maybe you meant that with really tiny, then forget about it. But I would think that there are a lot more units of these tiny chips sold compared to a fully featured 32bit ARM processor. Maybe that will change with price.
vardump 7y ago
> Nearly every SoC you can buy today has hardware accelerators in it, from STM32s up to Xeons. You have to be looking at really tiny, generally pretty old micros before you literally don't have any. Well... the SoC in Raspberry Pi 4 doesn't have one. Although it does have enough CPU (and in theory GPU) oomph to still do crypto at reasonable rates, AES-128 at 85 MB/s per CPU core.
- debatem1 7y ago
  The RPi 4 SoC does have crypto accelerators, specifically for HDCP. It does not have the ARMv8 crypto extensions.
  - vardump 7y ago
    Does it have any HW crypto accelerator that could be utilized from ARM side software? I couldn't find anything.
    - debatem1 7y ago
      Not that I know of, but they're so cagey on details for those parts I wouldn't be surprised if it did and they just hadn't documented it. Certainly lots of quasi-similar boards like the espressobin have them (which I like better for the topaz switch anyway).
kevin_thibedeau 7y ago
That covers AES and hashing. Try generating a 2048-bit RSA key on a Cortex-M. It will take minutes. ECC is thankfully more performant on resource constrained devices.

anon4242 7y ago

> Nearly every SoC you can buy today has hardware accelerators in it True, but few are full-featured HW acceleration SoCs. Most support a few operations like for instance AES-ECB and maybe AES-CBC but if you want AES-CCM or AES-GCM you still need to implement parts of it in software. The HW may be super fast at ECB:ing many blocks of memory but the setup cost is steep so when you need to ECB just a single block (for your counter in CCM) it buys you very little performance gains over just ECB in SW. (Of course what you do then is setting up several counters in a larger block of memory, after each other, this is ok because the counters are just increments, and you ECB a bunch of blocks. Next you need to solve how to do the same to get CBCMAC with just CBC HW...)

debatem1 7y ago
This is just moving the goalposts. First it was "crypto accelerators are rare because ITAR", now it's "crypto accelerators are rare because they don't buy you much". Neither is true. Crypto accelerators are extremely common, including those that implement full cryptosystems or even complete protocols. Nearly every wireless part will have them (especially for CCMP), as well as basically every modern+common consumer device SoC (eg, all Qualcomm, Samsung, Apple, AMD, and Intel parts). Several of these actually have overlapping accelerators for eg memory encryption or wireless (full protocol) and acceleration instructions like those for ARMv8. And they are there because they work. Setup cost is a thing, but A) is largely paid when you rekey and therefore rarely for most protocols, B) is acceptable in many protocols because you can interleave other operations to prevent port contention without sacrificing throughout, and C) is often buried by the cost of a very small number of blocks, or even just one.
- snagglegaggle 7y ago
  He didn't move the goalposts and usefully expanded on my point. Those devices you're talking about notably adhere to other external standards and are not typically user reprogrammable (where user is the integrator). Also important is that I would not consider them secure in general due to the standards they implement. You also certainly realize that their power consumption, when present, massively dwarfs the type of processor we were first discussing? By the time you get to the ARMv8 accelerators, yes, you're going to exactly the same place I was arguing we should go with my original comment. There's actually a number of primitives that could be reused for various systems.
  - debatem1 7y ago
    The original claim was that these parts were rare because of ITAR. They aren't rare, and ITAR doesn't have much to do with where they're present or absent. Shifting the argument to a different point about a specific accelerator or specific class of parts is exactly as I said: moving the goalposts. The question of whether they're user programmable or not is nearer to the mark because EAR cares about it, but it still doesn't present a formidable barrier-- at least, I've been shipping parts with crypto accelerators at various levels of user configurability for a long time, and so has everybody else.
- anon4242 7y ago
  > Setup cost is a thing, but A) is largely paid when you rekey Well, it depends on the crypto HW. Some HWs are designed for "throughput", which is completely useless for ECB but looks good on specs ("Our HW AES 10MB/s!"). So you set it up with src, dest and key pretty much as you setup your typical DMA transfer, only you almost never want to encrypt more than 16 bytes at a time with ECB so it's mostly wasted. > consumer device SoC (eg, all Qualcomm, Samsung, Apple, AMD, and Intel parts) We are not all so fortunate that we get to work with such powerful SoC. In my job it's mostly small embedded MPUs. > B) is acceptable in many protocols I think we are talking past each other here. I haven't even gotten to the protocol part yet. In order to support a wireless and/or network protocol you will need better building blocks than AES-ECB. You need AES-GCM (or at least AES-CCM). Not to mention ECDSA or RSA(>=3072)...

raxxorrax 7y ago

That is an exaggeration in my opinion. Many µC don't have a real use case for encryption as well as many sensors. Maybe you meant that with really tiny, then forget about it. But I would think that there are a lot more units of these tiny chips sold compared to a fully featured 32bit ARM processor. Maybe that will change with price.

vardump 7y ago

> Nearly every SoC you can buy today has hardware accelerators in it, from STM32s up to Xeons. You have to be looking at really tiny, generally pretty old micros before you literally don't have any. Well... the SoC in Raspberry Pi 4 doesn't have one. Although it does have enough CPU (and in theory GPU) oomph to still do crypto at reasonable rates, AES-128 at 85 MB/s per CPU core.

debatem1 7y ago
The RPi 4 SoC does have crypto accelerators, specifically for HDCP. It does not have the ARMv8 crypto extensions.
- vardump 7y ago
  Does it have any HW crypto accelerator that could be utilized from ARM side software? I couldn't find anything.
  - debatem1 7y ago
    Not that I know of, but they're so cagey on details for those parts I wouldn't be surprised if it did and they just hadn't documented it. Certainly lots of quasi-similar boards like the espressobin have them (which I like better for the topaz switch anyway).

kevin_thibedeau 7y ago

That covers AES and hashing. Try generating a 2048-bit RSA key on a Cortex-M. It will take minutes. ECC is thankfully more performant on resource constrained devices.