# Network hardware encryption?

Hi,

We all know both the z80 and the r800 are too slow to handle https or any other secure protocol fast enough. That's too bad, specially now that TLS is becoming mandatory in all Internet protocols.

I'm not a hardware specialist, but I'm pretty sure there are specialised chips for IoT that are able to handle encryption by themselves, liberating our favourite obsolete computers to do this task.

How difficult (if possible) would be to implement this in a new network card?

Login sesión o register para postear comentarios

At least things like hashing of passwords using modern algorithms should still be within the realm of the Z80’s abilities.

But I agree, more and more sites are using HTTPS, so less and less content is accessible to our favourite 8-bit system.

Ok, anyone can explain the algorithms and math behind "hardware encryption" so that it can be implemented?

TLS is widely used nowadays. That's what I meant when talking about encryption: https://en.wikipedia.org/wiki/Transport_Layer_Securit

And here some info on SSL / TLS acceleration

Possibly it could be done in FPGA?

why is there not a 12c card for msx? its a light old protocol and makes it easyer to conect modern dev. to your msx

Eugeny_Brychkov wrote:

Ok, anyone can explain the algorithms and math behind "hardware encryption" so that it can be implemented?

RSA is probably the easiest to understand of the many encryption algorithms that you need to support for TLS.

With RSA each portion of the original message, p, is transmitted as (p^n) mod m. All three of those numbers are very large; 1024 bits is the normal RSA minimum nowadays. So you're talking about exponents and modulos in 1024-bit arithmetic, for every 1024 bits you want to transmit.

(Aside: the same function is applied for decoding but subject to a different power; that value is never revealed. You're given only (n, m). So you can encode, but you can't decode without doing an intractable amount of factoring work to derive the unknown power. E.g. the largest RSA key known to have been cracked was 768 bits, was cracked in 2009, and took two years of work, amounting to 2000 years of computing on a 2.2Ghz Opteron of the time. That was just the one specific key they cracked, they didn't find a flaw in the algorithm. So the 2000 years of processing would have to be repeated for every stolen data stream.)

Hardware encryption just means that you supply the original plain text, and any necessary encryption keys, and the hardware does the maths. Definitely a lot more realistic than doing it on a Z80.

EDIT: I should add, these are all things I think I recall from my undergraduate degree (other than the successful 2009 attack, which I looked up earlier). So they're things I learnt, ummm, "a while ago". Corrections may be appropriate, and if so then they're welcome.

Quote:

Ok, anyone can explain the algorithms and math behind "hardware encryption" so that it can be implemented?

I like when Eugeny makes that kind of question. It signals good things at the horizon...

TomH wrote:
Eugeny_Brychkov wrote:

Ok, anyone can explain the algorithms and math behind "hardware encryption" so that it can be implemented?

RSA is probably the easiest to understand of the many encryption algorithms that you need to support for TLS.

With RSA each portion of the original message, p, is transmitted as (p^n) mod m. All three of those numbers are very large; 1024 bits is the normal RSA minimum nowadays. So you're talking about exponents and modulos in 1024-bit arithmetic, for every 1024 bits you want to transmit.

(Aside: the same function is applied for decoding but subject to a different power; that value is never revealed. You're given only (n, m). So you can encode, but you can't decode without doing an intractable amount of factoring work to derive the unknown power. E.g. the largest RSA key known to have been cracked was 768 bits, was cracked in 2009, and took two years of work, amounting to 2000 years of computing on a 2.2Ghz Opteron of the time. That was just the one specific key they cracked, they didn't find a flaw in the algorithm. So the 2000 years of processing would have to be repeated for every stolen data stream.)

Hardware encryption just means that you supply the original plain text, and any necessary encryption keys, and the hardware does the maths. Definitely a lot more realistic than doing it on a Z80.

EDIT: I should add, these are all things I think I recall from my undergraduate degree (other than the successful 2009 attack, which I looked up earlier). So they're things I learnt, ummm, "a while ago". Corrections may be appropriate, and if so then they're welcome.

One important aspect of TLS is the negotiation of the cipher. Modern web servers and browsers support a multitude of ciphers and during initial communication a negotiation takes place to select which cipher will be used (like RSA, SHA1 or even MD5). Now I don’t think you have to implement all ciphers for MSX just one that is accepted by enough web servers (enough is of course difficult to quantify).

This would be very useful.
I'm struggling to find ways to convert SSH to TELNET in order to be able to use it in the MSX.

I think the best way to go is to use a Raspberry Pi or PC as a proxy.

You can TELNET to the Pi, then run an SSH client on the Pi to get out to an SSH server. Really, that's not any different than back in the dialup days, where we'd dial into a host system and use that to communicate with other systems. In fact, on my first ISP, I used to download files directly to my shell account, then transfer them to my PC with ZMODEM. That actually seemed to go faster than direct http downloads over dialup.