[Sohcahtoa82]

Just getting HTML working would be mind-blowing on a Windows 1.0 machine, assuming you were running the typical hardware of the time.

From what I can tell, the 80286 was still a server-grade CPU in 1985, and most PCs were still running an 8086 or 8088, which maxed out at 1 MB of RAM. Just the HTML for the Wikipedia article on the 8086 [0] is nearly 224 kilobytes, nearly 1/4 of the RAM available.

https://en.wikipedia.org/wiki/Intel_8086

[hnlmorg]

Good point.

It definitely wouldn’t be powerful enough to do TLS encryption either.

[Sohcahtoa82]

Think so?

I'd think it could do TLS encryption, it just wouldn't do it FAST. It would also probably be limited in the ciphers and key exchange algorithms it would support.

[hnlmorg]

While you’re technically correct, I don’t think it captures the spirit of my comment.

Modern (in comparison) CPUs contain instructions to aid with performance, such as AES extensions. If you’re doing everything in software then you’ll be limited to the older ciphers, most of which might not even be supported by modern sites given TLS1.3 is the recommendation. 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. But then you’re looking at days or even weeks just to complete the handshake, let alone pulling an HTML content. By which point the novelty of getting an 8088 online would long since have worn off.

So to say TLS wouldn’t be fast is an understatement. Calling it an understatement is itself an understatement :)

If you remove TLS from the equation things get dramatically simpler. I’ve got a 64k 8bit micro (Amstrad CPC 464) with a WiFi adapter. The adapter handles the wireless protocols but beyond that I wrote a very simple HTML browser. Though most other similar projects I’ve seen have used a Raspberry Pi hooked up via serial to provide offloading. But that’s basically turning your 8bit Micro into a dumb terminal and thus feels somewhat like cheating.

[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