That will depend entirely on the features that you select and the choices you make for the underlying implementation. Our hash functions and block ciphers are configurable to tune RAM, ROM, and performance to customer needs. You can choose a fast implementation and burn flash with precomputed lookup tables, or a lean implementation and run a little slower, using less RAM and ROM.
|17 kByte||emSSL with the smallest single cipher suite, RSA_WITH_RC4_128_SHA, and TLS protocol version 1.2, used in an emNet application with the emWeb web server.|
|19 kByte||emSSL with one single cipher suite, RSA_WITH_AES_128_CBC_SHA, and TLS protocol version 1.2, used in an emNet application with the emWeb web server. All current major web browsers can establish a HTTPS connection to the server with this cipher suite.|
|43 kByte||emSSL with all supported all cipher suites, all prime elliptic curves, TLS 1.0, TLS 1.1, and TLS 1.2, used in an emNet application with the emWeb web server.|
*Tested with SEGGER Embedded Studio, Cortex-M4, compiler optimizations for size. The values do not include the server certificates, which add another ~1.5 kByte per certificate.
|Following components are required in order to use RSA_WITH_AES_128_CBC_SHA and TLS 1.2:|
|Signature algorithm||SHA with RSA|
|Pseudorandom function (PRF)||SHA256|
|Message authentication code (MAC)||SHA1, SHA256|
Again, this depends upon the cipher suites and how many simultaneous TLS connections you make.
The overall static RAM requirement of TLS of the order of tens of bytes. When you create a connection, the amount of RAM required spikes during TLS negotiation because keys need to be exchanged, certificates parsed, and so on.
We also cannot control the record-layer packets sent by the server and, in this case, it wholly depends upon the server -- if the server cannot support the TLS record fragmentation extension. The smallest case is one DES-RC4 cipher suite, a single connection, which is currently in the range of 1.5 kBytes.
What we have done is tune emSSL such that it uses very little memory. We know it's going to be used in resource-constrained controllers. We know every byte is precious and we are working on trimming things even further.