Russtopia
/
xs
mirror of https://gogs.blitter.com/RLabs/xs
2
1
Fork 0
Code Issues Projects Releases Wiki Activity

Update page 'FAQs'

Russtopia 2023-10-16 23:41:13 -07:00
parent 33ebcc1b15
commit f3a6c277f7
1 changed files with 13 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
FAQs.md

@ -6,26 +6,33 @@ This is a remote access client and server solution with encrypted communication,
### Why write this when `ssh` already exists?
Because sometimes the best way to learn about something is to recreate it. A sculptor doesn't become proficient by just looking at others' works, they need to do some sculpting themselves :)
Because sometimes the best way to learn about something is to recreate it. An artist doesn't become proficient by just looking at others' works, they need to do some creation themselves :)
That and, to be honest, I found the existing openssh codebase to be pretty heavy; and after many evenings of dead ends trying to properly add support for new algorithms (I could get the negotiation tables working, but could not figure out how the heck one communicates the session keys to each newly-opened channel... fork() hell), I realized that Go (golang), with its extremely clean concurrency model and strong standard library might allow a much cleaner implementation of what I wanted.
And, to be honest, I found the existing openssh codebase to be pretty heavy, burdened by a lot of history. After many evenings of dead ends trying to properly add support for new algorithms (I could get the negotiation tables working, but could not figure out how the heck one communicates the session keys to each newly-opened channel... fork() hell), I realized that Go (golang), with its extremely clean concurrency model and strong standard library might allow a much cleaner implementation of what I wanted.
Yes, yes, I know openssh is what it is because it has been battle-hardened over about two decades, and a lot of the complexity there is there for a reason. However, a lot of it is *also* there because C is much lower-level, especially in its string- and buffer-handling, a minefield of security 'oopsies'. (I still love you, C!)
Yes, yes, I know openssh is what it is *because* it has been battle-hardened over around two decades, and a lot of the complexity there *is there for a reason*. However, a lot of it is *also there because C is much lower-level*, especially in its string- and buffer-handling -- a minefield of security 'oopsies'. (but I still love you, C!)
### Has `xs` been audited for security?
Nope. Have at it, please. Feedback is welcomed, and the more secure it can be made, while keeping idiomatic Go code, the better.
Nope. Have at it, please. Feedback is welcomed, and the more secure it can be made, the better.
That said, using Go greatly diminishes the attack surfaces for buffer overflows, code injection and so on due to Go's cleaner string/slice infrastructure, and the fact that Go by default panics and dies early on any violation of uninitialized pointers and bounds exceptions. The client and server code itself contains no `unsafe`-style blocks which turn off such protections, and any underlying crypto algorithms which aren't written in pure Go are from the standard Go crypto libraries which have been externally audited for security. The same can be said for login, logout, logging and terminal handling libraries, which are also from the Go standard library, which sit atop the Linux/BSD/Windows OS APIs, so those are also heavily scrutinized.
That said, I think it can be objectively said that using Go *greatly diminishes the attack surfaces* for buffer overflows, code injection and so on due to Go's native string/slice facilities, and the fact that Go by default panics and dies early on any violation of uninitialized pointers and bounds exceptions, rather than merrily stomping memory. The client and server code itself contains no `unsafe` blocks which turn off such protections, and any underlying crypto algorithms which aren't written in pure Go are from the standard Go crypto libraries which have themselves been externally audited for security. The same can be said for login, logout, logging and terminal handling libraries, which are also from the Go standard library, which sit atop the Linux/BSD/Windows OS APIs, so those are also heavily scrutinized.
*However*, as mentioned in the README.md, all of the KEx/KEM algorithms are experimental, so one should keep up to date on the security of those. That's the main purpose of this project, to use those algorithms to prove their practicality and to offer alternates to those used in the main `openssh` ecosystem.
**2023-10-xx: for example, djb (Daniel J. Bernstein) has recently asserted that the NIST analysis of the KYBER PQC KEM makes an error (intentional or not, hello there NSA!) that overestimates the strength of KYBER-512, so KYBER-768 and above are probably recommended as mimima when choosing that algo ...**
As mentioned in the README.md, all of the KEx/KEM algorithms are experimental, so one should keep up to date on the security of those. That's the main purpose of this project, to use those algorithms to prove their practicality and to offer alternates to those used in the main `openssh` ecosystem.
### But forks of `openssh` exist with PQ (Post-Quantum) KEx/KEM support.
Sure, but again this was a learning project, and those are also written in C, within the greater complexity of the `openssh` codebase. I see Go as being more inherently secure, and the source code easier to maintain, which also aids in security when making future changes. Diversity in solutions for network shell access is also good.. we've all relied exclusively on `openssh` for a long time, and a monoculture is dangerous.
### But openssh has keystroke timing obfuscation.
Yeah, I did that early on with this project, about two years prior; it could probably be improved, but I can say with confidence that xs did keystroke timing obfuscation *before it was cool*. :P See the discussion on 'chaffing' in general elsewhere in these docs.
### You should have written it in Rust!
Go away. Just kidding. Well, half-kidding. I plan to learn Rust someday, but not today. Feel free to port `xs` to Rust if you're a wiz, and I'd be interested to compare the implementations, really! I'll still prefer the solution which is easier to read and with lower SLOCC, which I honestly doubt Rust will achieve... I may be proven wrong, and I'll happily buy a round of beer at the release party where this is demonstrated.