yes PK crypto is computationally expensive for large messages. Symmetric key cryptography is typically much faster than asymmetric key cryptography because its algorithms are generally simpler and require fewer computational resources - this adds up quickly when needing to perform bulk encryption of large amounts of data and if you work on a small MCU like an ESP32, it makes sense thus to consider more efficient algorithms.
You also find cases where symmetric encryption is used in conjunction with asymmetric encryption ➜ look at TLS: it is widely used to secure internet communications like web browsing, email, instant messaging, or voice-over-IP (VoIP) for example and in TLS, asymmetric encryption (RSA / Elliptic Curve Cryptography) is used for the initial key exchange phase the server sends its public key to the client, which the client then uses to securely establish a shared symmetric key for the session.
Once the initial key exchange is complete, the bulk of the data transmission occurs using symmetric encryption algorithms such as AES . This approach provides a good balance of security and efficiency in secure communication over the internet.
PGP (Pretty Good Privacy) is also an example that uses a combination of symmetric and asymmetric encryption.
When you encrypt a message using PGP, it typically follows this process:
- PGP generates a random symmetric session key for each message. This session key is used for encrypting the actual message content.
- The recipient's public key is used to encrypt the session key. it is used here because it allows for secure key exchange without requiring the parties to share a secret key beforehand.
- The encrypted message, along with the encrypted session key, is sent to the recipient.
- When the recipient receives the message, he uses their private key to decrypt the session key. Once the symmetric session key is decrypted, it is used to decrypt the actual message content.
So I would not rule out Symmetric key cryptography on a small MCU and if @kb1sph1 finds a secure way to perform the initial key exchange phase then why not ?
anyway, that's far away from using memcpy() which should be the focus of this post 