Hacker News Reader

Comment by colinlm | Hacker News Reader

According to people at CryptoAncienne (https://github.com/classilla/cryanc), a 25MHz 68030 needs about 22 seconds of maths to handshake a modern TLS server. During that time, most servers close connection.

So on an 1MHz 6502, I think it'd be minutes just for handshaking.

View on HN

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.

Yes, although the zeropage is quite cramped. There's only about 8 bytes free there if you don't want to overwrite anything. Accessing the zero-page only gains 1 cycle out of 4 needed to access non-zero-page memory locations, anyway, so that's only a 25% performance gain in very limited applications.

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.

Most of us throw that in the form of an HTTPS-stripping proxy on a Pi :)

I mean, that would be the sensible approach. I was just thinking that designing an FPGA board for my Apple II might be...fun.

It does sound fun, although I shudder at trying to prove that such a thing would be free of side channel attacks.

Reply on news.ycombinator.com