Thanks for that, I was going to point out its the public key, and cert validation that is going to be the problem more than the actual data encryption. I had this problem a couple years back with a project on a esp8266, which was taking on the order of 5 seconds at 160Mhz to setup a TLS connection. And it got worse with longer key lengths, and validating a cert chain.

So, ballpark it probably takes multiple minutes, and probably consumes most of the RAM for the intermediate steps with longer keys.

OTOH, I switched to an ESP32 because it has RSA offload, and something like that could be attached to an apple ][ fairly easily, to provide a connection offload accelerator.

I wonder if it would be possible to make a usable dedicated hardware encryption card for the Apple II using 80s tech.

(Of course, it has the downside that upgrading to a new protocol would require a new card, but hey... we're just having fun musing on retro-futurism here!)

The 68030 is also a 32-bit processor with 8 general purpose registers. The 6502 is an 8-bit processor with one accumulator and two index registers, though it could use the first 256 bytes of memory (zero page) as pseudo-registers.

Not that anyone would find this useful or practical, but I wonder if it would make sense to define an alternate protocol where the handshake is asynchronous and doesn't require the server to hold a continuously open connection while the client performs the encryption. This might be a non-starter for interactive applications, but for batch things like downloading emails (where you could get away with checking for new mails every hour or so) this could be tolerable.

That does make sense. I was assuming that HTTPS would be possible but slow in 80s' hardware, I was not considering that the slowdown would be so massive modern hardware would consider it a lost connection.

It should be possible to drop in a coprocessor board to handle the encrypt/decrypt. It's compute bound rather than bus bound so it should speed up nicely.