3 ms·

According to people at CryptoAncienne (https://github.com/classilla/cryanc https://github.com/classilla/cryanc), a 25MHz 68030 needs about 22 seconds of maths t

According to people at CryptoAncienne (https://github.com/classilla/cryanc 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.

eschneider 3y ago
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.
- colinlm 3y ago
  Most of us throw that in the form of an HTTPS-stripping proxy on a Pi :)
  - eschneider 3y ago
    I mean, that would be the sensible approach. I was just thinking that designing an FPGA board for my Apple II might be...fun.
    - kibwen 3y ago
      It does sound fun, although I shudder at trying to prove that such a thing would be free of side channel attacks.
kibwen 3y ago
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.
hisham_hm 3y ago
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!)
Maken 3y ago
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.
StillBored 3y ago
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.
js2 3y ago
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.
- colinlm 3y ago
  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.

eschneider 3y ago

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.

colinlm 3y ago
Most of us throw that in the form of an HTTPS-stripping proxy on a Pi :)
- eschneider 3y ago
  I mean, that would be the sensible approach. I was just thinking that designing an FPGA board for my Apple II might be...fun.
  - kibwen 3y ago
    It does sound fun, although I shudder at trying to prove that such a thing would be free of side channel attacks.

kibwen 3y ago

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.

hisham_hm 3y ago

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!)

Maken 3y ago

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.

StillBored 3y ago

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.

js2 3y ago

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.

colinlm 3y ago
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.