> Is modern encryption a challenge to those old machines?
Ooooooh yeah. It's got some serious overhead on single core systems several-hundred-megahertz systems without the instructions that are used to accelerate encryption these days. AES is what modern CPUs use to help with that. It wasn't until Power7+ before encryption was accelerated on that class of CPUs. The latest Mac to use Power CPUs was discontinued 6 years before that.
Once you have authenticated each other and agree to a nice symmetric cipher and exchange the keys for that, yes. Bytes, even kilobytes per second. But note the "once you have authenticated". Public key crypto is brutal number crunching and takes minutes to hours on systems of the 80s, and some noticeable seconds even in the late 90s. I think that's why something like RSA-4096 was not just universally adopted 30 years ago. It was too expensive to compute for casual use.
Since you mention EC, it uses floating point. Good ol' FLOPS is not a wholly useless metric there. The first commercial processor sold with a floating point unit integrated was the 486 in 1989. Some rough, unsourced numbers:
I am making the same mistake that the other poster did, in assuming too much background familiarity. Those are 90s chips. This software runs on machines from the late 1980s. The trend scales further back as it does forward. Five years is always a long time in computer performance.
The 486, the slowest chip on my list blasts the early Macs (which this software runs on) out of the water by 100x. I went and researched it and the the 68882 FPU at 25 MHz is about 0.25 MFLOPS: http://www.faqs.org/faqs/motorola/68k-chips-faq/
Stunning, but that is the difference between 1985 and 1989 technology.
The first Macs were 8 MHz 68000 chips. The GUI was still very responsive. The menus popped down and Quickdraw (the graphics library) properly handled arbitrarily shaped overlapping windows. There was a demo with a round window and windows in the background updated perfectly. Bill Atkinson invented the Regions data structure (and the rest of Quickdraw) that allowed among other things, background windows graphics calls to be clipped to arbitrary combinations of foreground windows super efficiently. Atkinson is one of the greats.
> I am making the same mistake that the other poster did, in assuming too much background familiarity. Those are 90s chips. This software runs on machines from the late 1980s. The trend scales further back as it does forward.
my point was on interactive use (i.e. using AES or ChaCha)
you are the one that diverted the topic towards RSA-4096 (which no-one uses), moving the goalposts (twice)
Yep. AES will run fine on any of these machines. These machines are in practice still sort of usable with SSH, with some patience for login depending on protocol.
I deleted the post because I was a bit too aggressive, but apparently the damage was done. I apologize for lecturing you like a prat.
It just occurred to me while reading this comment that people born after Intel CPUs mostly leveled out perfwise are probably peers now. That realization came hard, it came fast, and I wasn’t ready to live with that knowledge by a long shot.
It was a long, long road to your 2014 laptop, friend. There was a time when division was a luxury, and desperate folk offered their firstborn for forbidden tricks to compute inverse square root. Elliptic curve, you say? You mean floating point math? Whoo-ee!
Power7+ came out in 2012 which was the first gen of Power CPUs to include AES acceleration. [1]
The most powerful Power Macs with non Intel CPUs were discontinued in 2006. (G5, released 2003.) [2]
Your laptop from 2014 was already running at LEAST a 64bit CPU and likely has AES instructions as they were introduced in 2010 [3]
So even if your laptop from 2014 onward didn't include AES instructions like some Intel Atom/Celeron/Pentium models... (Acer C720P Chromebook, for example came out in 2014 and has a Intel Celeron 2955U [4] and [5]) It was still an architecture that is/was ELEVEN YEARS NEWER. A Celeron 2955U is roughly equivalent in performance to a Core 2 Duo E4700 or an AMD Athlon 64 x2 5200+ ... which is still quite ahead of a PowerMac G5. [6] and [7]
TLDR: Time marches on and along with cpu improvements come instructions and other benefits not immediately visible to the end user.
Try using your old 2003-era system to generate keys again and tell us how fun it is. Bonus if you try it on a Pre-2000 era Performa Mac as a user typically had with SystemOS 7, 8 and 9. Those ran at 16 to 66mhz. [8]
For reference, SystemOS 7 came out in 1991. [9] OS8 came out in 1997. [10] And OS9 came out in 1999. [11]
The CPUs inside the Performa Macs running System 7, OS8 and OS9, at best, can be compared to the 486s on the Intel side. Not even Pentium level. This places the architecture at LEAST a dozen architecture generations behind what you're generating keys on. This means if the CPUs we're looking at here were aged up, your laptop is starting first or second grade while the actual CPUs of the time are now finishing their masters' degrees with a kid or two on the way.
Rather than naively using your extremely modern in comparison 'crappy laptop' cpu as a reference point, perhaps you should use something more typical from the time these OSes were considered relevant.
You must be young. The gap between 1989 and 1999 in computer terms is inmense, far more than the gap between 2010 and 2020. You could emulate a 1989 m68k Mac/Amiga on a Pentium 3 from 1999, for example with BasiliskII/UAE.
Performance increase did not stop; smaller, better designs. The exponential is just a bit lower.
We don't realize it, just as someone using a text terminal may have not realised it between 1985 and 1995, if every response after a key press was already instant.
For typical GUI interfaces, tasks like tossing video data around, and so on, computers became approximately inifinitely fast sometime c. 2005 - 2010.
It's the encryption. For Crypto Ancienne, it may take 20 or more seconds for a cacheless 25MHz '030 to do a local TLS 1.2 transaction, and that's with skipping a whole bunch of steps. Pretty much anything under 40MHz will have timeouts because most servers won't wait.
For reference, using modern ssh to connect to a 15 MHz m68030 Mac LC II with 16 bit memory bus takes literally just under ten minutes (NetBSD 9 to NetBSD 9). An LC III+ with 33 MHz, 32 bit bus m68030 takes a little over 3 minutes.
the crypto code actually has some 68020 assembly (credit to the mbedtls devs), it could probably be made faster, but I would need to sharpen my assembly skills a lot
doing the initial key exchange before timeout is barely possible for a 68030 at 16MHz, takes the better part of a minute!
of course, on the later PPC machines it's a complete non-issue
> Is modern encryption a challenge to those old machines?
I've used modern encryption/mac routines on small embedded micro's and they seem reasonably efficient. Couple of operations per byte. They have to be fast because they are used for decrypting stuff like streaming video. I think an exception is password hashing algorithms which are slow by design.
That said some of the older algorithms are really inefficient. Hundreds of ops per byte.
Depends in part on the cipher suite. For software implementations, the current generation of chacha20-poly1305 and ed25519 are tolerable. But earlier generation ciphers were designed with hardware acceleration in mind.
This tool is relying on libssh2 for its SSH implementation core. chacha20-poly1305 and ed25519 are both extensions and are not included.
Yes, modern SSH is a challenge even on the fastest 486-class machines, which are very roughly comparable to this 68030. Takes several seconds to complete a connection.
For real. I’ve tried porting several modern UI libraries to classic Mac, such as Nuklear, uGUI, and a couple of others. And I’ve succeeded in getting them working, but as soon as you start doing something with text, they fall on their face. Just having a text input is nearly impossible on an 8MHz 68000!
Is modern encryption a challenge to those old machines? Is it because of specialized encryption hardware or sheer brute force?
Or is it just this implementation that's slow?
I used telnet back in the 68k days.