[Sohcahtoa82]

> For example OpenSSL doesn’t support RC and AES will benchmark much slower on CPUs (when compared with RC) without AES instructions and smaller L1 cache.

> Sure you could workaround that by supplementing cache with writing to persistent storage and just throwing more time at the problem.

I think my question is...if you only supported a single key exchange algorithm and AES-128, and didn't verify server certificates, how much code would a TLS negotiation take? My understanding is that TLS libraries get large because they support dozens of key exchanges and ciphers, plus support previous versions of TLS, and a huge suite of features that most people probably don't even use. I would THINK you could achieve a bare minimum that an 8088 could run in under 100K of code.

Damn, now I'm tempted to actually try this. Know any way to emulate an 8088 at an accurate speed? ;-)

[hnlmorg]

The problem isn’t code size for unused cyphers. The very first part of any SSH or TLS handshake is agreeing to what cypher suit to communicate on.

The problem is purely the computational overhead of the encryption itself. This is why modern CPUs have instructions to offload some of that overhead to hardware.

You can think of this as the same kind of problem of MPEG encoding and decoding in software vs hardware. The difference in performance is massive. Then try to do that on a 40 year old 16 bit CPU with virtually no cache and only 1 MB of RAM to play with