Mikrotik and ED25519 Keys

Well, it seems miracles do happen. According to the 7.9 testing release notes, Mikrotik will finally support ED25519 host keys. But, is this even important? I would argue yes.

First of all, ED25519 keys are MUCH shorter and significantly faster while providing higher security margin than 2048-bit RSA keys. If you want to use the same key to centrally manage your network and you have some underpowered clients, you will definitely feel RSA slowness when establishing connection - especially when dealing with high-ping situations. And shorter keys are not anything to frown upon either as they get much easier to copy/paste than wall of text RSA provides.

Secondly, security of ED25519 seems quite robust and sits somewhere between 2048-bit and 4096-bit RSA key. Unless there is a major breakthrough in cracking ED25519, this is good enough for foreseeable future. When/if quantum computers become a reality, both RSA and ED25519 are fcked so you’re in a losing battle. However, ED25519 keys seem to have a quantum-resistant NTRU-X25519 key exchange in OpenSSH while there is nothing similar for RSA.

Albeit I’m not cryptographer, I do listen to a lot of smart ones and most of them assume any quantum scaling breakthrough necessary to break ED25519 keys will buy a few years at most for RSA algorithm. In short, while both RSA and ED25519 may be doomed at undefined time in the future, it seems unnecessary to avoid faster algorithm ED25519 is today.

Lastly, for me this will mean I can use a single management key once more as, at this time, I’m using ED25519 for most of my needs with RSA being exclusively kept for the purpose of managing Mikrotik. Finally, I’ll be able to use one key to rule them all.

Good luck with upgrade!

[2023-05-04: Unfortunately, ED25519 support is partial at best. If you try to assign key to a user, you’ll get unable to load key file (wrong format or bad passphrase]

[2023-08-18: Well, while ED25519 support has been with us since 7.9, one couldn’t import any ED25519 keys. If 7.12 beta 1 release notes are to be believed (“ssh - added support for user ed25519 public keys”), we should finally have it done fully and properly. Let’s see…]

[2023-11-15: At last, ED25519 is supported by Mikrotik as of RouterOS 7.12]

Hashing It Out

While .NET finally includes CRC-32 and CRC-64 algorithms, it stops at bare minimum and offers only a single standard polynomial for each. Perfectly sufficient if one wants to create something from scratch but woefully inadequate when it comes to integrating with other software.

You see, CRC is just the method of computation and it’s not sufficient to fully describe the result. What you need is polynomial and there’s a bunch of them. At any useful bit length you will find many “standard” polynomials. While .NETs solution gives probably most common 32 and 64 bit variant, it doesn’t cover shorter bit lengths nor does it allow for custom polynomial.

Well, for that purpose I created a library following the same inheritance-from-NonCryptographicHashAlgorithm-class pattern. Not only does it allow for 8, 16, 32, and 64 bit widths, but it also offers a bunch of well-known polynomials in addition to custom polynomial support.

Below is the list of currently supported variants and, as always, code is available on GitHub.

Mikrotik Upgrade via SSH

New Mikrotik version came out and my firewall was just a bit too tight to allow remote WinBox connection. But I did have SSH…

And yes, upgrading to new version is easy enough from command line too. It’s just that one needs to execute two (you can omit the check) commands for the same GUI experience.

/system/package/update check-for-updates /system/package/update download /system/reboot

And that’s it, the new version is in.

Start Application Without the X Bit Set

When one plays in many environments, ocassionally you can expect issues. For me one of those issues was starting Linux application from a shared drive. For reasons I won’t get into now, except to say security-related, executable (aka X) bit was removed. Thus it wasn’t possible to start application.

But, as always in Linux, there are multiple ways to skin a cat. For me the method that did wonders was usage of ld-linux library. For example, to start a.out application, one could use the following command:

/usr/lib64/ld-linux-x86-64.so.2 ./a.out

PS: This is for applications (e.g., files with ELF header). If you want to run a script without executable bit set, just call the interpreter directly, e.g.:

bash ./a.sh

Sleep Until the Next Full Second

For a bash script of mine I had to execute a certain command every second. While this command lasted less than a second, its duration was not always the same. Sometimes it would be done in 0.1 seconds, sometime in 0.5, and rarely in more than 1 second (that’s curl download for you). This variance made using a simple sleep command a bit suboptimal.

What I needed was a command that would wait until the next full second. What I needed up with was this

SLEEP_SEC=`printf "0.%03d" $((1000 - 10#$(date +%N | head -c 3)))`
if [[ "$SLEEP_SEC" == "0.000" ]]; then SLEEP_SEC="1.000"; fi
sleep $SLEEP_SEC

The first line is just taking the current nano-second count and trimming it to the first three digits that are then subtracted from 1000 and prefixed with 0.. This essentially gives millisecond precision count until the next full second. For example, if current nanosecond counter is 389123544, this would result in 0.611. And yes, you lose a bit of precision here as number gets truncated but the result will be precise enough.

If you wonder what is 10# doing here, it’s just ensuring numbers starting with 0 are not misdetected by bash as octal numbers.

The if conditional that follows is just to ensure there is at least 1 second of sleep if the previous command took less than 1 ms. Rare occurrence but cheap enough to protect against.

Finally, we send this to the sleep command which will do its magic and allow the script to continue as the next second starts. And yes, it’s not a millisecond precise despite all this calculation as sleep is not meant to be precise to start with. However, it is consistent and it triggers within the same 2-3 milliseconds almost every time. And that was plenty precise for me.