fragmentfi wrote on 2021-04-14, 18:40:The original SSH2DOS was last updated in 2006 and the protocols and ciphers it uses are outdated and basically it does not work […]
Show full quote
The original SSH2DOS was last updated in 2006 and the protocols and ciphers it uses are outdated and basically it does not work anymore. I've patched the program to be up to date (as of 2021).
The old programs can be still used if the ssh server configuration is changed to allow using less secure connection methods. The patched ones have been tested with the latest Ubuntu (20.04.2 LTS) release and needs to changes to ssh server configuration.
Old protocols and ciphers have been replaced as follows:
diffie-hellman-group1-sha1 -> diffie-hellman-group14-sha256
aes128-cbc -> aes128-ctr
hmac-sha1 -> hmac-sha2-256
I have only tested ssh and scp clients with password authentication. Key based authentication is most likely broken and needs some more work. Other changes to the program are minimal, the goal was just to get it working again with minimum effort.
I'm open for comments, bug reports and improvement ideas!
Source and binaries are available on GitHub:
https://github.com/AnttiTakala/SSH2DOS/
Hey fragmentfi,
Since performance will be crucial for your SSH implementation on DOS systems with slow 8086/186/286 CPUs, here's something you can try to speed things up:
I've come across a very nice, extremely simple implementation of the XOR shift register (Xoshiro) type of random number generators that produces random numbers "nearly as good" as CPU intensive LCG (Linear Congruential type) RNGs,
and better random numbers than rand() (and faster too).
I've been writing an unbiased path tracer (a sort of GI ray tracer) in MS-DOS during the last few weeks for an upcoming video on my 200LX YouTube channel,
and since path tracing requires lots of random numbers (just like SSL encryption does in your SSH2DOS) and requires an RNG with good periodicity and high quality "randomness",
I initially used an LCG similar to linuxs' rand48() with good, but slow results, as there's more than a dozen multiplications and additions per number in the function.
After switching from the LCG to this XOR shift register RNG I've got nearly identical quality random numbers with a high periodicity and no observable patterns (int32_t only though, but that's enough as my renderer uses single precision floats throughout),
but my engine speed increased from 49 minutes to 31 minutes per frame! 😀, with identical quality results. I'm using the Borland C++ 3.2 IDE and compiler/linker for MS-DOS.
For security reasons you might want to leave the current RNG in there (or add a better one like an LCG), and maybe add a command line option to use the RNG you already use, or the LCG, or, this one, so users on slow systems like PC/XTs can use the command line switch to use this XOR shift RNG to get a nice speed boost... (although with less security, but you can't have it all 😀 )
It's really simple too, only 3 bit shifts and 3 XORs on an unsigned 32bit integer, here's the function:
// Fast Xor Shift 32bit precision RNG
static uint32_t _fXorState = 2171454626; // RANDOM SEED & STATE
inline uint32_t fXOrShift32(void)
{
fXorState ^= fXorState << 13;
fXorState ^= fXorState >> 17;
fXorState ^= fXorState << 5;
return fXorState;
}
With old C/C++ compilers on DOS, with a 16 bit target, you'll have to typedef uint32_t as an unsigned long int, but I'm sure you know that already 😀
The 80186 CPU (HP 200LX) does multi bit shifts 3x to 4x faster than a 8086/8088, as does the 80286,
so it's even better on those platforms...
All you have to do is find a good way to get a good random seed (_fXorState ) for the RNG...3
Cheers,
Radiance