On Recommended Hardware

[Alperin-Sheriff, Jacob (Fed)]

Hi all,

 

In response to community recommendations on narrowing our requested hardware platforms, we are considering requesting that teams focus specifically on Cortex M-4 and Artix-7 for hardware implementations for Round 2. Are there any strenuous objections to these two platforms?

 

 

 

(Note that either way, we will still be considering implementations on other constrained devices (microprocessors,FPGAs, ASICs, etc.) both by teams and by third parties in our evaluations).

 

 

—Jacob Alperin-Sheriff

 

[D. J. Bernstein]

Markku correctly notes that "Cortex-M4" is ambiguous. I'd suggest saying
more specifically a Cortex-M4 with all options included. This is what's
available in, e.g., the low-cost STM32F4 Discovery boards. (ARM used to
have a separate name "Cortex-M4F" for this but later merged it into M4.)

---Dan

[Oscar Garcia-Morchon]

Hi, 

CortexM4 is a good platform that is widely used. However, there is also a very large body of low-cost IoT solutions on more limited platforms that currently use public-key cryptography. Thus, comparisons on these more limited platforms (and the mere ability to run on them) should also be taken into consideration when selecting the final portfolio. The risk of not doing this is selecting a set of solutions not capable to run on small devices. 

   

Industry experience (and simple market research) shows that more resource-constrained platforms such as Cortex M0, AVR, etc are not going away soon. For example, Google IoT devices include those using AVR (although with a cryptographic coprocessor): https://blog.hackster.io/google-teams-with-microchip-for-avr-iot-cloud-connected-8-bit-microcontroller-6e2fbe5078bf 

 

Popular AVR cryptography libraries are available that implement RSA and ECC. The Round5 team is keen to demonstrate that Round5 IoT variants offer superior or at least comparable performance to these, and therefore offers a viable transition path.

Regards, Oscar.

[Kevin Chadwick]

On 2/6/19 2:37 PM, 'Oscar Garcia-Morchon' via pqc-forum wrote:
> CortexM4 is a good platform that is widely used. However, there is also a very
> large body of low-cost IoT solutions on more limited platforms that currently
> use public-key cryptography. Thus, comparisons on these more limited platforms
> (and the mere ability to run on them) should also be taken into consideration
> when selecting the final portfolio. The risk of not doing this is selecting a
> set of solutions not capable to run on small devices. 
>
>    
>
> Industry experience (and simple market research) shows that more
> resource-constrained platforms such as Cortex M0, AVR, etc are not going away
> soon. For example, Google IoT devices include those using AVR (although with a
> cryptographic coprocessor):
> https://blog.hackster.io/google-teams-with-microchip-for-avr-iot-cloud-connected-8-bit-microcontroller-6e2fbe5078bf 
>

Cortex-M4 IS suited to low-cost IOT where 8 bit would mostly make no sense.
Often IOT is seen as just bolting a pi or insecure arduino with off the shelf
stuff these days, so that is refreshing, however. I expect/assume that the 8bit
controller you mention isn't doing any of the cryptography. I assume it just
shuffles data at the lowest cost possible. An actual IOT device that utilises
their chip would be very unlikely to choose an 8 bit micro, IMO.

[Derek Atkins]

On Wed, 2019-02-06 at 15:15 +0000, Kevin Chadwick wrote:

Cortex-M4 IS suited to low-cost IOT where 8 bit would mostly make no sense.

Often IOT is seen as just bolting a pi or insecure arduino with off the shelf

stuff these days, so that is refreshing, however. I expect/assume that the 8bit

controller you mention isn't doing any of the cryptography. I assume it just

shuffles data at the lowest cost possible. An actual IOT device that utilises

their chip would be very unlikely to choose an 8 bit micro, IMO.

Yes, the M4 is suited for that, however that doesn't stop people from using the M0 or AVR solutions. You know what they say about people who assume, right? I can assure you that we see many customers *today* using the M0, MSP430, 8051, and AVR platforms and looking to perform public-key cryptography on the controller itself! I do not expect this to change in the next 3-5 years.

-derek

-- 

Derek Atkins
Chief Technology Officer
SecureRF Corporation

Office: 203.227.3151  x1343
Direct: 617.623.3745
Mobile: 617.290.5355
Email: DAt...@SecureRF.com

This email message may contain confidential, proprietary and / or legally privileged information and intended only for the use of the intended recipient(s) and others specifically authorized. Any disclosure, dissemination, copying, distribution or use of the information contained in this email message, including any attachments, to or by anyone other than the intended recipient is strictly prohibited.  If you received this in error, please immediately advise the sender by reply email or at the telephone number above, and then delete, shred, or otherwise dispose of this message.

[Markku-Juhani O. Saarinen]

Hi Kevin,

Talking about this with industry colleagues we arrived at a different conclusion -- most either have live development projects or are supporting products based on 8-bit microcontrollers. This is because in industry and manufacturing we are often motivated to choose the cheapest viable option, and also due to long lifespans of some product lines. If you have a working control solution for some appliance you don't want to port it to a 32-bit architecture unless you absolutely have to. 

Market research was mentioned; the market share is about 35%, but since 8-bit units are generally cheaper than 32-bit units, actually a majority of MCUs currently sold are 8-bit. [1,2]. Although the units-sold market lead is not that that great, the devices are not disappearing anywhere soon.

I suspect that you are referring to purely hobbyist projects since you mention Raspberry Pi -- surely you do realize that the extremely popular Arduino system you mention is based on an 8-bit AVR MCU. 

Some links to 8-bit cryptography implementations: https://www.cryptolux.org/index.php/Links_to_Embedded_Crypto_Implementations

Market research pointers:
[1] https://www.electronicdesign.com/microcontrollers/8-bit-or-32-bit-choosing-your-next-design-s-mcu

[2] https://www.alliedmarketresearch.com/microcontrollers-market

Cheers,
- markku

Dr. Markku-Juhani O. Saarinen <mj...@pqshield.com> PQShield, Oxford UK.

[Kevin Chadwick]

On 2/6/19 3:53 PM, Markku-Juhani O. Saarinen wrote:
> Talking about this with industry colleagues we arrived at a different conclusion
> -- most either have live development projects or are supporting products based
> on 8-bit microcontrollers. This is because in industry and manufacturing we are
> often motivated to choose the cheapest viable option, and also due to long
> lifespans of some product lines. If you have a working control solution for some
> appliance you don't want to port it to a 32-bit architecture unless you
> absolutely have to.

Did this survey only include those that include cryptography and may utilise
PQC. If it didn't, then your data is misleading.

>
> Market research was mentioned; the market share is about 35%, but since 8-bit
> units are generally cheaper than 32-bit units, actually a majority of MCUs
> currently sold are 8-bit. [1,2]. Although the units-sold market lead is not that
> that great, the devices are not disappearing anywhere soon.
>

I am in the "industry", and make technical choices today. Legacy support is no
reason for future decisions and we are talking about new code. New product
designs will not choose 8bit, it makes no technical sense. It is more likely
that the "industry" you mention would deploy insecure md5 or worse still today.

> I suspect that you are referring to purely hobbyist projects since you mention
> Raspberry Pi -- surely you do realize that the extremely popular Arduino system
> you mention is based on an 8-bit AVR MCU.

Actually I was criticising some woefully insecure arduino wifi chips and that
IOT is abused like the word Crypto, quite often ;)

[Kevin Chadwick]

On 2/6/19 3:39 PM, Derek Atkins wrote:
> Yes, the M4 is suited for that, however that doesn't stop people from using the
> M0 or AVR solutions. You know what they say about people who assume, right?

I do, however M0 is not 8-bit, a bigger assumption was that Googles design
supported your point around 8-bit, it didn't.

If you assure me that many use 8-bit/AVR then that is a different statement
entirely. It wouldn't convince me??

[Derek Atkins]

On Wed, 2019-02-06 at 16:49 +0000, Kevin Chadwick wrote:

On 2/6/19 3:39 PM, Derek Atkins wrote:

Yes, the M4 is suited for that, however that doesn't stop people from using the

M0 or AVR solutions. You know what they say about people who assume, right? 

I do, however M0 is not 8-bit, a bigger assumption was that Googles design

supported your point around 8-bit, it didn't.

Huh? I never said it was. But the AVR is.

If you assure me that many use 8-bit/AVR then that is a different statement

entirely. It wouldn't convince me??

You seemed to have conveniently skipped over my second paragraph, where I DID say that many customers are asking for public-key cryptography on 32, 16, and yes, 8-bit MCUs.

[Kevin Chadwick]

On 2/6/19 4:52 PM, Derek Atkins wrote:
>
> You seemed to have conveniently skipped over my second paragraph, where I DID
> say that many customers are asking for public-key cryptography on 32, 16, and
> yes, 8-bit MCUs

Ok but I hope that you see my point that stating that many use oxygen via
Mouths, Snorkles and Skuba gear doesn't mean that Skuba gear is a widely used
tech of the future for super large air tanks.

I am not saying, you are wrong. I would love to visit Aquamans Atlantis ;). Just
that the evidence given didn't support your statement and that first hand
evidence in terms of my own design decision knowledge doesn't either. You could
certainly convince me on price but I'm not sure that will sustain in the future
or to wafers/volume?

[Apon, Daniel C. (Fed)]

Some brief clarification:

In order to best enable an ‘apples-to-apples’ comparison between hardware performance data, we will recommend that teams generally focus their hardware implementation efforts on Cortex-M4 -- ‘with all options included’ -- and Artix-7. These devices have been chosen primarily for their ubiquity of use. In particular, we've been contacted by a handful of hardware teams that are each now working to implement most or all of the 2nd Round candidates on these selected devices in their local test environments (though we still strongly encourage additional, independent hardware performance analysis of the candidates).

However, we also believe there is value in understanding the viability of post-quantum public-key crypto on even lighter-weight devices such as e.g. the Cortex-M0 or AVR microcontrollers. We will certainly consider any experimental data gathered on these or other, alternative devices as a part of any candidate-scheme’s portfolio.

--Daniel Apon