> I would love to understand the software process breakdowns that allow that "Charlie" code to make it into production!
In embedded systems FW-space is at a premium.
If you can avoid embedding a full crypto-stack in your firmware and replace it with 5 lines of C, which provides at least some safety, more often than not (depending on the use-case), that might be the right decision.
I mean, even if the encryption used here was proper RSA, the method discussed in this article might lead to disclosing the key and cracking the protocol anyway.
And if we're talking megabytes, there's no excuse not to do proper crypto. MbedTLS, for example, gives you a basic TLS stack in 64kB ROM + 64kB RAM, and a pretty splurgy one in 200kB.
Of course this can be way too much for small embedded systems, but if you can afford to run Linux and use phrases like "individual megabytes matter", you can definitely do proper crypto.
In embedded systems FW-space is at a premium.
If you can avoid embedding a full crypto-stack in your firmware and replace it with 5 lines of C, which provides at least some safety, more often than not (depending on the use-case), that might be the right decision.
I mean, even if the encryption used here was proper RSA, the method discussed in this article might lead to disclosing the key and cracking the protocol anyway.