Author Topic: 32F417 hardware crypto  (Read 828 times)

0 Members and 1 Guest are viewing this topic.

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3671
  • Country: gb
  • Doing electronics since the 1960s...
32F417 hardware crypto
« on: August 19, 2022, 09:49:24 am »
I've been doing some timings, on a 168MHz CPU.

This "tiny AES256" https://github.com/kokke/tiny-AES-c does 100kbytes/sec. It is 900 bytes in size.

The AES256 which comes with MbedTLS does 800kbytes/sec.  It is 4026 bytes in size.

In the context of embedded HTTPS, is there any point in using the 417's hardware AES? I don't know the speed of it but probably much faster still.

The 417 has no acceleration for RSA or EC, so the session setup takes 2-3 seconds. That is probably a much bigger issue, for some users.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Online DiTBho

  • Super Contributor
  • ***
  • Posts: 3801
  • Country: gb
Re: 32F417 hardware crypto
« Reply #1 on: August 19, 2022, 10:10:25 am »
fsksht, HTTPs for embedded on an MPU? that's why when I think of modern computing I feel nothing but the hope that someone will hire me to throw buckets of food at hyper-carnivorous bears that are mostly found within the Arctic Circle.
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: 32F417 hardware crypto
« Reply #2 on: August 19, 2022, 10:32:43 am »
Maybe this is of use: https://www.wolfssl.com/docs/stm32/

AFAIK the F217 is similar to the F417, but it has a Cortex-m3 instead of m4f core.
I'm not too familiar how the TLS handshake works if there are any faster options in the SSL libraries, but I guess it kind of makes sense that the handshake time is quite slow.

But realistically performance also depends on the TCP/IP stack. If the TCP protocol can't push more than 1MB/s (although I think more should be possible on that MCU), then upgrading to 10MB/s hardware acceleration is kind of moot. On the other hand, every cycle saved is a nice bonus..

Got to wonder though, is it an application requirement to run HTTPS? Is it a server or client? It implies the device is connected to ethernet, and frankly I still prefer to connect embedded devices behind some kind of tunnel instead of straight to the internet.

@DiTBho, what are you on about? The world moves forward and so does internet standards. The new HTTP3 standard doesn't even use TCP anymore and the whole protocol is built around TLS as a integral part. The transport is based on QUIC, which still uses UDP as it's still compatible with many home routers, but if they had the option they would also have skipped that. QUIC also offers nice features like being able to prioritize certain file transfers (e.g. audio over video) or connection handovers when the IP (and thereby NAT) is switched over. The killer feature thouhg is that QUIC+HTTP3 can do connection handshake, TLS handshake and the first HTTP request in 1 round-trip.
They don't expect 100% adaption of HTTP3 , but there is going to be a time when things will need to move over, and that this enormous beast (as it implements TCP, TLS, and part of HTTP with header compression in 1) of a protocol stack will have to run on embedded. So it's always better start learning today (read: keep learning everyday)
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3671
  • Country: gb
  • Doing electronics since the 1960s...
Re: 32F417 hardware crypto
« Reply #3 on: August 19, 2022, 11:09:48 am »
Interesting stuff there Hans. I am not surprised to see a 10x speedup.

Incidentally I did a dig around, to see why MbedTLS was chosen on my project ~3 years ago. It was probably a good choice.
https://stackoverflow.com/questions/67204980/wolfssl-vs-mbedtls-vs-openssl-what-is-the-difference

WolfSSL needs a runtime payment, so not much good for many projects.

Also I found that that MbedTLS cannot be updated beyond 2.16 due to:
https://github.com/OpenVPN/openvpn/commit/110eee0288cff0720952a2cf16c4fb191d0bd616

HTTP3 looks like a complete nightmare. For embedded, we will end up with another "MbedTLS" which will be buggy as hell for the next 5 years.

The 32F417 hardware support is usable really only for AES. DES/3DES is apparently not used by anybody anymore (discredited, rightly or wrongly) and the rest of the hardware features are similarly obsolete.

Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Online DiTBho

  • Super Contributor
  • ***
  • Posts: 3801
  • Country: gb
Re: 32F417 hardware crypto
« Reply #4 on: August 19, 2022, 12:08:43 pm »
A private connection to yourembededserver can't be established because your computer's date and time  are incorrect.

To establish a secure connection, your clock needs to be set correctly. This is because the certificates that websites use to identify themselves are only valid for specific periods of time. Since your device's clock is incorrect


Yeah, let's put this inbuilt with HTTP3 support just to make things worse
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf