Excellent! I especially like the attention to detail with the random number generation.

mbbrutman wrote on 2026-11-03, 15:40:

Excellent! I especially like the attention to detail with the random number generation.

Thanks!

DOSSSH 1.1 is out, with some significant speed improvements.
1.2 will follow as soon as we get my mTCP fixes sorted out on GitHub. 😀

Is public-key user login planned or is it just not feasible? Tried to use it but as I only allow key logins on all my servers I can't really use it.

Honestly, no idea yet. First, I need to get what’s already there into decent shape and figure out its limitations and how useful it actually is.

Thank you for this and for the FTP project. It looks like you actually put some effort into it and didn't just vibe code it and have the AI spit out a 100,000 word emoji-filled triple-redundant novel in the readme.md like so many other projects these days.

Thanks! FTP2P was written the old-fashioned way. For this project, I used AI to check the existing crypto code and verify protocol compliance. I know the basics and have some experience with cryptography, but it's not really my field. AI is good at finding security vulnerabilities, so I think it's worth taking advantage of that while we can.

radozd wrote on 2026-11-06, 05:28:

Thanks! FTP2P was written the old-fashioned way. For this project, I used AI to check the existing crypto code and verify protocol compliance. I know the basics and have some experience with cryptography, but it's not really my field. AI is good at finding security vulnerabilities, so I think it's worth taking advantage of that while we can.

Appreciate the full disclosure, thanks 😁
I guess you know this already, but something to bear in mind is the LLM sycophancy. Meaning they don't really aim to produce the correct answer, but one that people are likely to find agreeable 😁
I'm not sure if this problem has been tackled with the frontier models (I tend to avoid the cloud).
With the smaller models I got the best results when I had some domain knowledge myself.

I'm not sure how sycophancy is relevant in this case.

There's a cryptography research paper I'm referring to, and the code is based on that paper. I link to both in the project description. I assume the paper has been peer-reviewed, while the code probably hasn't, even though it already works.
My approach is to give the existing code to AI and ask it to look for weaknesses. Some of these are things I could find myself, but that would require diving pretty deep into the subject. I'm not sure that's the best use of my time. The alternative is to find an expert and ask or pay them to do an audit. But how do you assess how good that expert is? I spent 10+ years in academia and have seen this problem firsthand.
We see examples of AI finding vulnerabilities that human developers and experts have missed. I think it's worth using this capability while we have it.

Of course, if someone is willing to review the code for free and put their name on the results, I'd be happy to have them do it.

And just to be clear: I'm not asking AI to praise my code or vibe-code something and then praise its own work. I'm asking it to find problems.

Yes, I think that's a good approach. If you can somehow demonstrate a problem exists in the code, it doesn't really matter how it was found.
They are doing the same with the Linux kernel, can't really argue with the results.

EDIT: To elaborate a bit, I don't think that LLM sycophancy problem affects you because the model isn't generating anything you can't verify yourself.

I've made a few more updates since v1.1. Modifier keys are now supported in the terminal, and I've added mouse support, so you can use the mouse in MC now too. I also made the first-run setup a bit simpler.

Everything seems to work well now, and I'm pretty happy with it. I think it's ready for everyday use. Still haven't decided what to do about public-key authentication. Need to look into that when I have time.

Here's a question. Since it's in 16 bit real mode, why not produce a version that doesn't require a 386?

I am also seconding the motion for public key auth.

keenmaster486 wrote on Yesterday, 21:57:

Here's a question. Since it's in 16 bit real mode, why not produce a version that doesn't require a 386?

I am also seconding the motion for public key auth.

Anything older than a 386 doesn't have 32-bit registers and is thus too slow.

radozd wrote on Today, 04:23:

Anything older than a 386 doesn't have 32-bit registers and is thus too slow.

Too slow to connect? Or too slow during usage?

Because I'm willing to wait longer to connect. Otherwise I understand.

Are there compromises that could be made to gain speed at the expense of security, perhaps?

keenmaster486 wrote on Today, 16:07:

radozd wrote on Today, 04:23:

Anything older than a 386 doesn't have 32-bit registers and is thus too slow.

Too slow to connect? Or too slow during usage?

Both. Even on a 386, using 16-bit registers is still too slow for SSH. 32-bit code, on the other hand, works wonders.