JNIOR Updates

[Bruce Cloutier]

Just a heads up...

We released JANOS v2.5 which is the operating system firmware for the Series 4 JNIOR automation. The update will appear on our website next week. That lags the release a bit.

Of note is the fact that this will now support connections from SSH clients. The system now recognizes color terminals and offers a more familiar look especially for those of you who work with Linux based systems. Be sure that your update project includes the /flash/www/config.zip file update as that will provide the new terminal features in the Console tab of the WebUI.

This build benefits from some more sophisticated optimization algorithms. As a result we see improvements in performance. Not that there were problems in that area before, but it is always good to make such advances. And, yes, we took several months to VERY cautiously evaluate this new compiler so as to be comfortable that we have not created any problems.

We took a little time to evaluate compatibility with Unicode character sets and UTF-8 owing to the international use. There were several adjustments made. For instance these characters used to cause issues with filenames. Note that we enabled the Ctrl-U keystroke to help with Unicode entry. This is unique and worth some experimentation. I would appreciate feedback. Basically during character entry you can enter a base character (say an 'e') and then repeat Ctrl-U to toggle that character through the various forms/accents. If your favorite character is missing let me know.

The built-in text editor EDIT got better. Our PHP-like scripting language has some improvements. We uniquely use that same language to render web pages as well as batch files and command line logic.

There are some diagnostic enhancements that will assist in technical support. These are things like memory leak detection and process/thread monitoring. Mostly this will help us catch issues with application programs (like cinema.jar) if any should exist (and for us to do that before you encounter them).

There are bug fixes but there were notably very few needed. We just polished a lot of things up. The HELP system provided with every unit will be updated assuming that the /flash/manpages.zip file is also in your update project.

** We are also past the supply chain issues and are fully committed to the ongoing availability of the Series 4 JNIOR.

[Bruce Cloutier]

So an SSH connection relies now on newer elliptic curve cryptography and the buzz-brains who specify that (FIPS etc) don't get it that Security is for everyone and not just those running at Ghz+ clock speeds. My elliptic curve implementation is using the faster algorithms but it still can take several seconds to establish a connection. They even elected to use the slower (Edwards) curves. Our TLS does elliptic curve but the faster version (in Montgomery space).

I had thought it would be appropriate to somehow play a sound clip of a modem connecting.

The SSH not-really-a-negotiation negotiation lets the client dictate the level of security and not the server. In my mind it should be the reverse. Because when you connect to a JNIOR you aren't protecting a Fort Knox account. So instead, you would elect to make a faster Telnet connection and the result of their over-zealous security demands is your election to not be secure. Dumb!

Still it works. Once you connect it is extremely fast and secure.

If you've generated a key-pair (ssh-keygen) you can upload the key to the JNIOR with the command

ssh username@ipaddress copy-id

after which connections should not require a password entry. The issue though is that this requires 2X elliptic curve calculations and therefore like 15 seconds. Works in Win10 command line - not only in Linux. You can also issue single commands on the JNIOR from the SSH command. There is no SFTP or tunneling. And, JANOS cannot make an outgoing SSH connection.

Anyway, if you have trouble let me know. The implementation is not as robust as maybe it needs to be. You may need to update your client. I plan to refine it some for a future release. I will optimize some more but I'm not looking at the potential of any significant speed improvement. Not without hardware changes.

All that said... a lot of the normal JNIOR stuff seems to run faster and smoother with this new compiler.

[Frank Cox]

Why would your gadget be required to have a FIPS-compliant implementation of ssh?

There's oodles and oodles (and even more oodles) of stuff in more mission-critical applications than cinema automation that uses standard rsa keys.

[Marcel Birgelen]

Why would your gadget be required to have a FIPS-compliant implementation of ssh?

There's oodles and oodles (and even more oodles) of stuff in more mission-critical applications than cinema automation that uses standard rsa keys.

Because someone checked that checkbox on their form...

I still remember that in a certain project, we had to go out of our way to deliver a machine with 3.5" floppy drive, because someone put that into the requirements and during any odd audit, the entire setup may have been deemed non-compliant without said 3.5" floppy drive during an eventual audit, even though this drive would serve no purpose at all and subsequent replacements of that machine, came without one.

Likewise, a JNIOR may find itself as a management device in some FIPS compliant network for whatever reason, requiring all checkboxes for minimum level of encryption to be checked on ALL devices within that network, wether or not they will ever be involved in any relevant financial transactions for example.

[Frank Cox]

If that's the case, and considering the downside Bruce listed about, wouldn't it make sense to have that as a configurable option in the device setup?

[Bruce Cloutier]

Actually, my gadget isn't required to be FIPS nor has any site using it (that might have elevated security requirements) raised any concern about it. The JNIOR can in fact handle 2,048 bit up to 4,096 bit RSA keys, elliptic curves, and the presently preferred digests. I coded all of that. Lot's of fun. Very educational.

The problem is that this takes A LOT of processing and is slow (at 100 MHz). If you, like me, have limited patience your choice is to NOT use the secure connection. I don't think THAT is the desired goal.

The real issue is in the SSH protocol. If your PC (i.e. "client") is using the FIPS compliant OpenSSL library it will only connect to FIPS compliant servers. So the 'server" cannot say "I am just an unimportant gadget" and allow you to make an encrypted, faster and not as secure connection. This to keep the honest honest so it is said. Nope. My gadget has to be offering only the computationally expensive level of security.

The protocol talks about a "negotiation" but there is no negotiation. I have to accommodate your client. In fact, recent versions of security protocols frown on attempts to downgrade security levels classifying them as attacks.

RSA was developed long ago when 2 MHz was fast. They were smart. You may notice that the "public" key is a small number with only a couple of bits set. This makes public key calculations fast even when the modulus is 4,096-bits, The private key RSA calculation though is computationally expensive. The elliptic curve cryptography cannot create that asymmetric situation and while supposedly the key sizes need not be as great they are even more work than the RSA.

My gripe is that the heads that make these decisions as to what the minimum levels are and what legacy security capabilities are not to be used, they forget that everything isn't running in the multi-GHz clock range. With this mistake they are preventing gadgets from using security at all. Not every connection carries Top Secret information (about golf tee times) or logs into all of our bank accounts with 9-figure balances. And, no, they aren't developing a quantum computer so they can break into JNIORs.

It is not like your OpenSSL library when encountering some gadget with limited security capabilities would ask you if you wanted to proceed. SSH connections aren't browsers that put up a warning. Even those warnings are phrased to make you think that by connecting (using HTTPS) to a JNIOR you are risking the loss of everything dear to you on your PC. And, that the resulting connection is "not secure" when it is.

Some gadgets are adding hardware accelerators at added cost in order to accommodate this. We are debating moving to 300 MHZ (at added cost) to accommodate this.

Most of you communicate with our boxes behind your firewalls anyway. Not always the case in other markets.

[Bruce Cloutier]

BTW this isn't about FIPS so much. Sure that is an issue.

The SSH elliptic curve has a set key size and the latest SSH clients are programmed to use the elliptic curve (Ed25519) in preference to RSA. So to make a SSH connection to the JNIOR with an updated client you are forced to use the elliptic curve and JNIOR has to perform at least one several-second calculation before it can generate the shared secret required for further encrypted communication.

JNIOR ships with a 512-bit RSA key. If you make a TLS connection it is pretty quick. In that negotiation we put the RSA at a priority over the elliptic curve. Can't play that game with SSH.

Also TLS uses the Curve2519 which has characteristics allowing you to do faster calculations. The two curves are equivalent and equally secure. I think they think that the more work you have to do the better the security. So they elected the slower one for SSH. You can find articles suggesting that I could convert the keys for the Ed25519 curve to their equivalents for the Montgomery curve and perform the calculations there. But the conversions take time and I don't think the overall gain is significant enough to warrant the effort.

Not that any of this benefits cinema. So here it is no big deal.

Also, the JANOS v2.5 update has made it to our site. So you can grab it if you are bored and throw it on a spare (you all have spares?) and play with this.

[Frank Cox]

15 seconds is a lot.

If it's truly unavoidable you might want to put a sticker on your new devices saying something that it's going to take a long time.

Otherwise you're going to have a lot of guys on the horn saying that the thing appears to be dead or defective.

[Bruce Cloutier]

Well I was thinking of playing the modem negotiation audio. But can't.

That 15 seconds is only if you copy the public key to the JNIOR (ssh-copy-id) and then connect in the future not needing then to enter the password. It is half that for the normal password reliant connection. This is only for SSH and does not affect the use of the product as you have for years in any way. This is why I am bitching about the idiot security people that make these decisions. The 6-7 seconds is palatable but definitely sucks the big wazoo. Once the connection is made it flies. It is just in negotiating the connection. There is like no choice because your client dictates everything. And, the 15 seconds to dial-up wasn't a big deal, um, 30 years ago.

If I don't offer (the slow) elliptic curve crypto and only support the RSA some SSH clients will not connect. They require the elliptic curve and that is that.

I have tested SSH from Ubuntu Linux, Linux Mint, Windows 10/11 and PuTTY. Older versions connect with RSA but once you update some won't. So I have to provide the elliptic curve and then they all use it no matter.

PuTTY actually has a weird quirk. In debugging that I actually tracked down Simon Tatham the original author who was very helpful in zeroing in on the issue.

The 15 seconds is completely avoidable. Don't use SSH. Kind of sucks that I went through the effort of implementing it. Use Telnet as always and the heck with being secure. Most of you use the WebUI Console tab but unless you connect using HTTPS (which isn't painfully slow) you are still not secure. But in the theatre you are secure enough being behind the firewall... maybe.

Most of you leave the default passwords anyway.

[Frank Cox]

Our expectations have changed over the past decades.

I remember putting a disk into my C64, 'load "*",8' and going to make a sandwich and a cup of tea, returning with the sandwich in hand and we're still not quite done loading.

Today... well again, 15 seconds is a lot.

[Bruce Cloutier]

I log into Windows now and go get coffee. I wish that took 15 seconds.

The Series 3 JNIOR takes around a minute to boot. It never had the processing power to support secure connections. The Series 4 boot takes just a few seconds.

So, yeah, use the SSH but don't bother to copy the public key. I am not happy with 7 seconds but it is not a show stopper.

[Marcel Birgelen]

Our expectations have changed over the past decades.

I remember putting a disk into my C64, 'load "*",8' and going to make a sandwich and a cup of tea, returning with the sandwich in hand and we're still not quite done loading.

Today... well again, 15 seconds is a lot.

Did you load it from floppy or from tape? *

Sometimes, I'd really want to go back to those pioneering days of Personal Computing... You know, the time where not every problem had 200 solution, each introducing 3000 new problems. Simpler, more monochrome times, when film was still just a bunch of light filtered through 24 pictures a second, printed on transparent celluloid...

Also TLS uses the Curve2519 which has characteristics allowing you to do faster calculations. The two curves are equivalent and equally secure. I think they think that the more work you have to do the better the security. So they elected the slower one for SSH. You can find articles suggesting that I could convert the keys for the Ed25519 curve to their equivalents for the It's and perform the calculations there. But the conversions take time and I don't think the overall gain is significant enough to warrant the effort.

Ed25519 was developed by, among others, Daniel J. Bernstein (aka "djb") and Tanja Lange, two cryptographers I highly respect. I've read quite a lot of their work in the past, not that I'd claim to understand all of it though... Interestingly, Ed25519 was chosen for the relative good compromise between speed and security. It was designed to be less susceptible for bad random number generators and SHOULD be a few factors faster than any RSA implementation with equivalent key strength.

For some reason, I find it interesting that Curve25519 (also first published by "djb") is so much faster on your hardware. I'm not too deep in this, neither do I want to hurt my brain too much, but I guess Twisted Edwards Curves need scalar multiplication in "Twisted Edwards Space" rather than "Montgomery space" and the whole Montgomery ladder thing isn't flying? Sorry, this is coming from somewhere far...

You can thank the NSA for nobody trusting RSA ever again, as RSA is very susceptible to badly generated "random numbers"...

The real issue is in the SSH protocol. If your PC (i.e. "client") is using the FIPS compliant OpenSSL library it will only connect to FIPS compliant servers. So the 'server" cannot say "I am just an unimportant gadget" and allow you to make an encrypted, faster and not as secure connection. This to keep the honest honest so it is said. Nope. My gadget has to be offering only the computationally expensive level of security.

I do agree with this "to keep the honest honest" principle though. If you mandate a minimum level of security, the weakest link is your problem, so you can't have ANY device in your secure network not conforming to the minimum standard. That being said, I doubt there is very much use for a JNIOR in any of that. Still, times are a-changin'... nowadays, "anything with a ping" is considered to be a target.

The problem with Telnet is that the telnet client is slowly getting eradicated from standard distributions, to my frustration, as I often use it for some basic TCP debugging: Is that port actually listening? Windows has removed it from the base install quite a while ago, it's gone from MacOS X nowadays and it's even not standard anymore on most recent Linux distributions. FreeBSD is still shipping a telnet client as part of the base distribution though.

Edit: Bruce had to interfere while I was doing my thing.
* Edit 2: This actually had me looking up the LOAD statement of C64 DOS/BASIC... the LOAD command was used to load stuff from disk. In order to load from tape, you held the SHIFT key, pressed play on the tape player and waited until the "FILE xxx FOUND" message appeared. It's all coming back now...

[Frank Cox]

I just happen to have the C64 User's Manual.

You just type LOAD and the machine says PRESS PLAY ON TAPE.

Then you go for lunch.

So sez page 28.

[Marcel Birgelen]

Yeah, that was it... but I also vaguely remember the "shift" thing, someone mentioned on the first Google post I found?

Also, there were cartridges, or at least, there was a slot, but I never had a cartridge. I did have cartridges for the TI99/something though.

[Bruce Cloutier]

Um, the PDP-8 loaded from "high-speed" paper tape. It didn't take that long but you had to first toggle in the bootstrap from memory (self-modifying code). But you didn't dare walk away in case the feeder needed help refolding the tape. ;-)

Looks like the first field updates to JANOS v2.5 occurred in Germany. Nice.