Where does crypto happen?
-
- Posts: 33
- Joined: Tue Nov 17, 2015 5:20 am
Where does crypto happen?
When I connect to a server using TLS, the connection can block for close to a full second depending on the cipher suite used. Currently, as far as I can tell, the app calls pretty directly into mbedtls, which means that the crypto all happens on the app core. Is there an easy way to move the crypto to the pro core? I've been thinking about doing the connection establishment in a different task pinned to that core. Or is that a bad idea for other reasons? Overall, I'm trying to reduce the impact on the rest of the app when a reconnection occurs. Any suggestions?
Re: Where does crypto happen?
Hi tvonicken,
The cryptography "heavy lifting" for TLS will happen on the CPU where the task which is establishing the connection is placed. If it's pinned to either core, it happens on that core. If un-pinned it can happen on either core. There isn't a dedicated "mbedtls task" like there is to handle internals of LWIP or WiFi (these two have tasks that can be pinned to a single core).
If you have the option, if it's an option then you could trim the supported ciphers to a list which can handshake faster, and check that all of the hardware accelerators are turned on. In particular, RSA-based ciphersuite verification (with hardware MPI acceleration) is much faster in recent versions of ESP-IDF, and significantly faster than DHE / ECDHE - but all are supported by default. Just note that if you don't control the server, you should make sure you have enough fallback options if the supported ciphersuites change in the future.
Angus
The cryptography "heavy lifting" for TLS will happen on the CPU where the task which is establishing the connection is placed. If it's pinned to either core, it happens on that core. If un-pinned it can happen on either core. There isn't a dedicated "mbedtls task" like there is to handle internals of LWIP or WiFi (these two have tasks that can be pinned to a single core).
If you have the option, if it's an option then you could trim the supported ciphers to a list which can handshake faster, and check that all of the hardware accelerators are turned on. In particular, RSA-based ciphersuite verification (with hardware MPI acceleration) is much faster in recent versions of ESP-IDF, and significantly faster than DHE / ECDHE - but all are supported by default. Just note that if you don't control the server, you should make sure you have enough fallback options if the supported ciphersuites change in the future.
Angus
-
- Posts: 33
- Joined: Tue Nov 17, 2015 5:20 am
Re: Where does crypto happen?
Thanks for the response! I a bit confused by this:
Did you perhaps mean RSA vs. DSS / ECDSA? I'm looking at cipher suites with perfect forward secrecy and the DHE/ECDHE part is very slow (as expected), but that's independent of RSA vs alternatives as far as I understand. Am I confused?In particular, RSA-based ciphersuite verification (with hardware MPI acceleration) is much faster in recent versions of ESP-IDF, and significantly faster than DHE / ECDHE
Re: Where does crypto happen?
Sorry for my unclear explanation. I mean that a cipher suite that uses RSA for the key exchange (ie ciphersuite name starts with TLS_RSA) will be faster than the supported alternatives. If you require forward secrecy then this is not an option. Using DHE for the key exchange is likely still faster than ECDHE, however I don't have a comparison at hand for this.tvoneicken wrote: ↑Thu May 28, 2020 7:41 amDid you perhaps mean RSA vs. DSS / ECDSA? I'm looking at cipher suites with perfect forward secrecy and the DHE/ECDHE part is very slow (as expected), but that's independent of RSA vs alternatives as far as I understand. Am I confused?
Who is online
Users browsing this forum: No registered users and 149 guests