Crypto Ancienne 2.0 brings TLS 1.3 to the Internet of Old Things (except BeOS) | Hacker News Reader

Crypto Ancienne 2.0 brings TLS 1.3 to the Internet of Old Things (except BeOS)

oldvcr.blogspot.com

62 pointstodsacerdoti15 comments

One thing that struck me as I read through was that the computational cost for TLS 1.3 is so expensive that it becomes infeasible to run on the slower machines, resulting in timeouts and failed connections while setting them up.

Yet those old machines had full GUI OSes and performant apps and snappy interactivity in their day. Is the sheer amount of computation required to facilitate TLS 1.3 really more than what was needed to run entire interactive GUI operating systems of that era?

Kind of mind boggling if so.

What if curvecp had won? Perhaps it still has a chance.

Yup, the post makes it very clear that running modern crypto with reasonable speed requires quite a beefy machine by early-1990s standards. 40 MHz clock speed is mentioned as a reasonable minimum.

My Amiga back in the day had a very snappy gui. But I remember it took 1 minute for a 512px jpeg to decode using FastJpeg which was written in assembly language, and I'd leave my computer running all night to draw a mandelbrot set or perform a simple 3d render.

Not to mention that if you wanted to use floating point arithmetic, you had to do it in software via a library, or use fixed point routines. Floating point units were expensive hardware add ons that were eventually integrated with the cpu.

It is to the credit of the gui toolkits on those machines that they seemed so fast, until you tried to do serious computation. Then you became fully aware that you only had a 7mhz cpu!

And they had hardware acceleration for graphics (not a GPU as we understand it today, but the graphical composition was done in hardware).

I think it is forgotten just how simple thing a basic gui is graphically. Ofc, things look nicer now, but still. It is not very complex thing.

On other hand, also always make me question what are we really doing these days. Some tricks are nice and make things better, but how much is wasted on billions of devices every day...

That things look nicer now is highly debatable. More complex, but just perhaps. How many pages I've seen scrolling on HN showing how the proper "toggle button" needs to work and animate in order not to be confusing where a checkbox still looks infinitely better to me? Or overlay scrollbars, that save essentially no space (which is given to padding instead!!!), hide the position are more difficult to grab?

I still think the W95/Motif-CDE/late Amiga years had very decent UIs even by today standards. Especially on Amiga, everything was expected to be interacted with with minimal latency. Everything was absolutely super-responsive. The UIs were legible, functional, and had tremendous information density.

That is the total opposite of today.

> Yet those old machines had full GUI OSes and performant apps and snappy interactivity in their day. Is the sheer amount of computation required to facilitate TLS 1.3 really more than what was needed to run entire interactive GUI operating systems of that era?

Yes.

Some is raw speed - we are talking about going from 10Mhz 16 bit (on a 286 or 68020) to 2.4Ghz+, multiple cores and 64 bit. This probably sums it up best: you needed a processor capable of about 2 MIPS (386sx, 68020) (yes MIPS is a naive benchmark) to run a color GUI nicely. You bog-standard modern i7 laptop does around 100,000 MIPS.

I think a better conclusion is how much more resource intensive entire interactive GUI operating systems have become since. Cryptography inherently relies on algorithms that are as secure as possible given currently reasonable hardware requirements. More security means bigger keys, more cycles, more work.

Windows 95 could boot on 4 megabytes of RAM. It could work comfortably on 16 megabytes of RAM! Visual Studio 5, an entire systems IDE, ran comfortably with 32MB of RAM and a Pentium chip! Even if you ignore the extended screen buffer, you'll be hard pressed to find even a basic text editor that will run that lean. What's notepad.exe even doing with all that memory?

You don't need all that much for a GUI if you optimise well. Today's GUIs are built to be quick to develop, not easy to run, because everything needs to be done quickly and only optimised later if people complain about it. Real sad, in my opinion.

Sometimes I wonder what my system is doing with the 2 to 3 gigabytes of RAM and five percent of a quad core CPU running a several gigahertz clock; it's using right after boot; it's certainly not running 500 times the complexity of Windows 95!

You can have a complete tcp/ip stack and an embedded web server in a 8bit micro using only a handful kilobytes of ram. This is (used?) to be a good way to service super-simple configuration to the user without having to connect through a serial cable and without too many additional parts.

There's absolutely no chance that 8bit can do TLS though, and with browsers refusing to connect without https what is often done in the embedded space is to have a separate mcu which is just doing wifi+tcp+webserver. That mcu is 32bit or better (any of the espressif families for example), often eclipsing the power of the rest of the entire system.

This reminds me of the TLS 1.3 implementation for older Android phones. It's being provided via a library called Conscrypt: https://github.com/google/conscrypt

And it goes all the way back to Android 2.3

It does add quite a bit of size to APKs (about 4-5 MB) but I think it's worth it to provide better security and connectivity regardless of OS and device age.

4 or 5 mb is pretty big for a gingerbread phone. I'd wonder if there's ways to make that smaller. Cutting out unnecessary ciphers would likely help, looks like conscrypt supports a lot of things; if you're including this to support your own servers, you probably know which ciphers are actually used and don't want to include anything else.

It wasn't immediately clear if conscrypt does its own certificate parsing; that's a lot of code if it's not strictly needed. (But it might not be possible to support ecdsa signed certificates without that)

(Regarding BeOS port:)

> What finally got it to behave was a combination of [various things...]; changing to less-sensitive library routines that could handle a little corruption; ...

(Insert Spock's-raised-eyebrow.)

Author here. Yes, I still can't wash the disgust off myself, but it does work!

There seems to be a conspicuous lack of PC platform OSs.

Reply on news.ycombinator.com