• Please review our updated Terms and Rules here

Crypto Ancienne: TLS for the Internet of Old Things

C

ClassicHasClass

Veteran Member
Joined
Mar 22, 2013
Messages
1,809
Location
(not so) sunny (No) So Cal
I'm pushing out an initial release of Crypto Ancienne, a TLS library intended for pre-C99 and the older architectures that run it, with support for TLS 1.2 with SNI and most current algorithms. It is tested on NeXTSTEP 3.3, Rhapsody 5.6, Mac OS X, Linux, NetBSD, AIX 4+ (4.1.5 and 6.1 specifically), Power MachTen 4.1.4 and A/UX 3.1. Ports to IRIX, SunOS 4 and maybe Tru64 are forthcoming. Most platforms with gcc 2.5 or better, 64-bit ints (usually long long) and stdarg.h will build it.

https://github.com/classilla/cryanc

Crypto Ancienne includes an example application called carl (a desperate pun on curl). carl allows you to grab HTTP and HTTPS resources, but also can act as a proxy when connected to inetd or an inetd-like environment. Combine this with an appropriately agreeable browser and you can bolt TLS 1.2 onto old browsers as well hosted even on the same system. Here are examples with OmniWeb, two NCSA Mosaic flavours and MacLynx.

https://oldvcr.blogspot.com/2020/11/fun-with-crypto-ancienne-tls-for.html
 
So, having written this, let me ask this.

What do you think is the slowest machine this could be practically used on?

Could this run on a 8088 at 4.77Mhz? a 286? a 386? 16Mhz, 20, 25, 33Mhz?

Just curious.

All of them "could do it", but I mean do it practically. Being able to shove the data over a TCP socket without consuming 100% of the CPU just for the encryption.
 
In the Github I give a real world example with a Macintosh IIci (25MHz 68030) running NetBSD. It has no L1 cache card because it actually makes it less reliable (periodically the cache card fails -- over the many years it's been in service it's blown through a few, even recapped ones, so I don't have one in it anymore).

This little machine takes about 20ish seconds to complete a TLS 1.2 transaction to a local server. Some servers refuse to wait that long which sets the artificial floor. Based on this single datapoint, I'd hazard the bottom edge for general usage is probably early-to-mid 1990s systems, so we're talking 68040s, 486s and early RISC (a PA-7100C is demonstrated), though if you were willing to wait it would be fine for more tolerant machines and applications.
 
Great project, shame my DS10L that runs Tru64 is currently not set up. I wonder if it would compile on OpenVMS somehow...
 
There's not a lot in the core library that's highly system dependent. carl.c might need some hacking for VMS, though. I have a VAXstation here but I think the C compiler license expired on it.
 
Citing from blogspot:
ClassicHasClass said:
So, since Mac Mosaic 3.0b4 is persnickety and crashy as heck, do we have an alternative that can be configured in the same way? Not the usual suspects, no: not Netscape, nor MSIE, nor NetShark, nor MacWeb.
Click to expand...
Why not? Is there a fundamental reason? Would it be even conceivable to add Cyberdog to usual suspects?
 
vldmrrr said:
Why not? Is there a fundamental reason? Would it be even conceivable to add Cyberdog to usual suspects?
Click to expand...
Never mind, I just realized the reason is described earlier in the blog post.

But here is an idea. What if carl would tunnel through https any http request to specifically modified host names, and in response replace in html content any https url with http url to modified host names? Prefixing with hyphen seem to be safe.

So for example, http://-google.com would go to https://google.com and in response replace all occurrences of "https://" with "http://-"
 
I've kinda abandoned most subjects on backporting TLS to older platforms because of the amount of effort needed but you mentioned that a release for Irix is on the way.
Is this library for recompiling browsers or does this snap-in to existing browsers such as Netscape where it is somewhat integrated into Irix but Netscape itself that I am aware is is not available in an uncompiled format.
 
vldmrrr said:
Never mind, I just realized the reason is described earlier in the blog post.

But here is an idea. What if carl would tunnel through https any http request to specifically modified host names, and in response replace in html content any https url with http url to modified host names? Prefixing with hyphen seem to be safe.

So for example, http://-google.com would go to https://google.com and in response replace all occurrences of "https://" with "http://-"
Click to expand...

I think something like this already exists (ISTR such a proxy but it's not coming to mind). It wouldn't be especially difficult to do this here, but it would probably make carl more complex than it already is and thus rather less suitable as a demo application. But it would plausibly work.

I did try Cyberdog, btw. No joy.

NeXT said:
I've kinda abandoned most subjects on backporting TLS to older platforms because of the amount of effort needed but you mentioned that a release for Irix is on the way.
Is this library for recompiling browsers or does this snap-in to existing browsers such as Netscape where it is somewhat integrated into Irix but Netscape itself that I am aware is is not available in an uncompiled format.
Click to expand...

It's more for recompilation, though carl covers the situation for those browsers (admittedly a minority) where you can redirect https to a separate proxy. The available browsers for IRIX don't fall into that category (I don't think) with the exception of Mosaic, which I need to fix to compile again and should work.
 
I built it on IRIX 6.5.30 (with the new RSE dev env which uses GCC9) and it built as POSIX-SUS. I will try it using the standard MIPSPRO compilers soon and post back. I'll submit a PR on GH if it requires any real changes...


[sgugshell dillera@fuel cryanc]$ gcc -O3 -o carl carl.c
In file included from carl.c:22:
cryanc.c:150:2: warning: #warning compiling for POSIX-SUS [-Wcpp]
150 | #warning compiling for POSIX-SUS
| ^~~~~~~
[sgugshell dillera@fuel cryanc]$

[sgugshell dillera@fuel cryanc]$ which gcc
/usr/sgug/bin/gcc


[sgugshell dillera@fuel cryanc]$ gcc --version
gcc (GCC) 9.2.0 20190812 (sgugver-0.2.0-mips3-ng)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
So, it turns out it doesn't work with gcc either. I'll probably do the work on that next.

Anyway, issues with A/UX and MachTen are fixed in tip (turned out to be a compiler irregularity). They now pass all the same tests all the other platforms do.
 
Officially tagging 1.5. The biggest change is that Crypto Ancienne now runs on classic BeOS, including PowerPC, and compiles under Metrowerks C. This required some hacking, which I detail here, along with what I think is the first inetd-like environment for pre-Dano: https://oldvcr.blogspot.com/2021/02/make-bebox-great-again-tls-12-inetd-and.html

However, this version also includes improved TLS 1.2 compatibility and now adds the following ports:

* IRIX 6.5 (with MIPSPro)
* Tru64 5.1B (with Compaq C)
* SunOS 4.1 (and Solbourne OS/MP, which it was developed under)
* BeOS R5 (mostly working, does NOT require BONE!)

and contributed patches for (thanks larb0b)

* Professional MachTen 2.3
* Haiku R1 (actually didn't need any, unlike its ancestor)
* Solaris 9
* 68K NeXTSTEP 3.3
* Mac OS X Public Beta through 10.1

in addition to its previous support for

* Linux, *BSD
* Mac OS X (10.2 to at least 10.4, PowerPC and Intel)
* AIX 4+
* Rhapsody/Mac OS X Server v1.2
* PA-RISC NeXTSTEP 3.3
* A/UX 3.1
* Power MachTen 4.1.4

I think the next frontier is to try to work it into a codebase, probably Mosaic or Chimera, and shake out library bugs.

https://github.com/classilla/cryanc
 
Officially tagging 2.0. The big news in this version is TLS 1.3 (yes!) and ChaCha20Poly1305 now works on big-endian. The only platform that didn't get TLS 1.3 is BeOS due to technical issues I couldn't fix (see https://oldvcr.blogspot.com/2022/07/crypto-ancienne-20-now-brings-tls-13-to.html for the entire story), but it still has 1.2, and working ChaCha20.

There are also new contributed ports for HP-UX 10.20, 11.11+ and 11.31 (on both Itanium and PA-RISC) and OpenServer 6, in addition to ongoing support for Linux, BSD, Mac OS X (PowerPC, Intel), macOS (Apple silicon), AIX 4+, Rhapsody/Mac OS X Server v1.2, NeXTSTEP 3.3, A/UX 3.1, IRIX 6.5, Power MachTen 4.1.4, SunOS 4.1 (OS/MP), BeOS R5 (PowerPC), and Tru64 5.1B, and contributed ports for Professional MachTen 2.3, Haiku, Solaris 9 and the Mac OS X Public Beta.

See screenshots of actual old browsers with proof of crypto: https://oldvcr.blogspot.com/2022/07/crypto-ancienne-20-now-brings-tls-13-to.html

https://github.com/classilla/cryanc
 
whartung said:
So, having written this, let me ask this.

What do you think is the slowest machine this could be practically used on?

Could this run on a 8088 at 4.77Mhz? a 286? a 386? 16Mhz, 20, 25, 33Mhz?

Just curious.

All of them "could do it", but I mean do it practically. Being able to shove the data over a TCP socket without consuming 100% of the CPU just for the encryption.
Click to expand...

I see this is an old post, but I did some experimentation a while back with testing the unoptimized C "supercop" version of curve25519 key exchange on some old machines.

Key exchange is just one part of TLS, but is the most computationally expensive. curve25519 would be used by SSH, not TLS, but it's the same idea.

Curve25519 took about 6 seconds on a 386DX-40, and 32 seconds on a 286-16.

The algorithm uses 32-bit multiplies which is the killer on a 286 since they must be emulated in software. You can do the math of how many multiples of that it would take on an 8088 and it's longer than anyone is willing to sit around. But quite possible on a 386. In fact, the Links2 web browser project offers a DOS version (386+ only) with up-to-date OpenSSL TLS and I've been playing with it on the above mentioned 386DX-40, and it is usable.

What I never got to test is doing some of the computations on the x87 so I've got to look into that again...

The next issue is symmetric encryption, where modern ciphers like ChaCha20 are a screenful at most of instructions on a 32-bit processor but lots of shuffling between registers and memory to do it with 286 instructions (I did this, for fun and practice). This is opposed to something like RC4 which is byte oriented rather than DWORD-oriented and so there is no "emulation" penalty on a 286 beyond just being slow.
 
I have been working on TLS support for 80286, although it is slow going. (TLS 1.2 can use curve25519 for key exchange as well, not only SSH.)

My 286/12 can do a curve25519 multiplication in about 30 seconds, but there is still lots of room for optimization (my code is based on tweetnacl and uses 64-bit arithmetic). A TLS 1.2 handshake requires two such operations, but can be reduced to one (giving up pretense of security). It is also be possible to efficiently implement AES128 using 16-bit arithmetic, although I only have working code for encryption so far (decryption is slightly more complicated).

Modern encryption is feasible on any 386 without problems (Internet Explorer 5.0 runs well enough, so it is possible).
A 286/12 should not have any problem handshaking. Throughput will be slow, but might be acceptable.
Supporting an 8086/8088 will be challenging: If handshaking is too slow, the server will kill the connection before it is established. Maybe.
I don't think any classic 8-bit processor (6502, 8080, Z80) can handle the handshake, therefore encryption speed doesn't matter.

The x87 is probably not going to be helpful - crypto is specified on integer math. But since it can run in parallel to the CPU, maybe it can speed up the handshake a bit.
 
Svenska said:
I have been working on TLS support for 80286, although it is slow going. (TLS 1.2 can use curve25519 for key exchange as well, not only SSH.)

My 286/12 can do a curve25519 multiplication in about 30 seconds, but there is still lots of room for optimization (my code is based on tweetnacl and uses 64-bit arithmetic). A TLS 1.2 handshake requires two such operations, but can be reduced to one (giving up pretense of security). It is also be possible to efficiently implement AES128 using 16-bit arithmetic, although I only have working code for encryption so far (decryption is slightly more complicated).

Modern encryption is feasible on any 386 without problems (Internet Explorer 5.0 runs well enough, so it is possible).
A 286/12 should not have any problem handshaking. Throughput will be slow, but might be acceptable.
Supporting an 8086/8088 will be challenging: If handshaking is too slow, the server will kill the connection before it is established. Maybe.
I don't think any classic 8-bit processor (6502, 8080, Z80) can handle the handshake, therefore encryption speed doesn't matter.

The x87 is probably not going to be helpful - crypto is specified on integer math. But since it can run in parallel to the CPU, maybe it can speed up the handshake a bit.
Click to expand...
Ah, I haven't been staying totally up to date with TLS developments, I guess curve25519 would fall within the ECDHE cipher suites. Is that pretty recent as my openssl ecparam -list_curves doesn't list it. And of course there is classical RSA key exchange to support too.
Peeking at openssl ciphers -v, looks like the only symmetric ciphers still around are the various modes of AES and ChaCha20-Poly1305. I wonder which between AES and ChaCha20 fits a 286 better once the implementation is fully optimized.
 
The relevant standard would likely be RFC8422 (Aug 2018).

A very helpful visualization is available at https://tls12.xargs.org/.

I don't know how widely supported curve25519 is, but since TLS 1.0/1.1 are phased out and trust in the NIST curves is basically gone, I assume that all relevant servers support it by now. Anyone else probably hasn't updated their server in years and is likely to still support unencrypted HTTP.
 
Tagging 2.2. Support was added for SCO UNIX 4.2 (ODT), but there are now non-Unixy ports: AmigaOS (using ixemul.library, yes, yes, but it works), and classic Mac OS with MPW (with GUSI, but only Amiga users complain about ixemul -we're totally fine with GUSI in Mac-land). Also in the SerenityOS ports tree. Various bug fixes as well.

oldvcr.blogspot.com

Crypto Ancienne 2.2: now supported on AmigaOS and classic MacOS/MPW

As threatened we're up to the next checkpoint with Crypto Ancienne, the TLS 1.2/1.3 library we maintain for pre-C99 vintage compilers and...
oldvcr.blogspot.com oldvcr.blogspot.com
github.com

GitHub - classilla/cryanc: TLS for the Internet of Old Things

TLS for the Internet of Old Things. Contribute to classilla/cryanc development by creating an account on GitHub.
github.com github.com

I suppose a Windows port should be next.
 
You must log in or register to reply here.
Back
Top