Russtopia/xs
2
1
Fork 0
mirror of https://gogs.blitter.com/RLabs/xs synced 2024-08-14 10:26:42 +00:00
Code Issues Projects Releases Wiki Activity
Page: Home
Pages
Client Block Diagram Connection Protocol FAQs Home SLOC of openssh portable vs. xs Server Block Diagram Session Protocol
72 Home
Russtopia edited this page 2024-05-02 00:16:56 -07:00
Table of Contents

The xs

Xperimental Shell (xs) - A from-scratch alternative to ssh, written in Go

Introduction

This project began as an excuse to

  1. Learn Go networking and Go in general
  2. Explore the idea of a from-scratch alternative to SSH
  3. Try out ideas relating to traffic obfuscation (traffic/endpoint chaffing and other concepts)
  4. Have fun porting experimental key exchange and symmetric encryption algorithms to Go (see below)

xs is a Golang implementation of a simple remote shell client and server offering:

  • encrypted interactive sessions (remote shell)
  • remote command execution, either with interactive authentication or with pre-arranged auth tokens for scripted operation
  • local-to-remote and remote-to-local file copying
  • secure tunnels

.. in other words, most of what ssh and scp do.

The client shell and copy (xs/xc) and server (xsd) programs build upon the Go standard lib's pkg/net facilities: net.Dial(), net.Listen(), net.Accept() and the net.Conn type, offering the same core interface with embellishments where necessary in order to support automatic negotiation of keying material, session configuration (ie., one-shot command vs. interactive shell vs. file copying) and other session parameters for secure sockets using new and promising public-key exchange and key encapsulation mechanisms such as

The xs client follows a standard Golang client connection style, but replaces calls to raw net.Dial() with xsnet.Dial(), and likewise the xsd server uses xsnet.Listen() to obtain connections conforming to the basic net.Conn interface.

Upon Dial(), the key exchange is initiated (whereby client and server independently derive the same keying material) and an agreed-upon session key and crypto algorithm are used to secure the individual session.

Above the xsnet.Conn layer the server and client (xsd and xs) negotiate session settings (cipher/hmac algorithm, interactive/non-interactive, etc.) to be used for further communication.

Packets are subject to random data padding (randomly pre- or post-payload), and the client and server channels both can optionally send chaff packets at random defineable intervals, of a configurable random size range, to help thwart analysis of the encrypted session's contents and timing, eg. interactive shell and keyboard activity.

**

NOTE: THIS PROJECT IS EXPERIMENTAL. This package SHOULD BE USED WITH CAUTION and absolutely SHOULD NOT be used for any sensitive applications. A full security audit of this product has yet to be performed. USE AT YOUR OWN RISK. NO WARRANTY OR CLAIM OF FITNESS FOR PURPOSE IS EXPRESSED OR IMPLIED.

**

HERRADURA KEX

As of this time (Oct 2018) no verdict by acknowledged 'crypto experts' as to the level of security of the HerraduraKEx algorithm for purposes of session key exchange over an insecure channel has been rendered. It is hoped that experts in the field will analyze the algorithm and determine if it is indeed a suitable one for use in situations where Diffie-Hellman or other key exchange algorithms are currently utilized.

KYBER IND-CCA-2 KEM

As of this time (Oct 2018) Kyber is one of the candidate algorithms submitted to the NIST post-quantum cryptography project. The authors recommend using it in "... so-called hybrid mode in combination with established "pre-quantum" security; for example in combination with elliptic-curve Diffie-Hellman." THIS PROJECT DOES NOT DO THIS (again, THIS PROJECT IS EXPERIMENTAL.)

NEWHOPE NewHope1024-CCA-KEM and 'NEWHOPE-SIMPLE'

Similar caveats to the above KYBER IND-CCA-2 KEM should be observed.

The client and server programs are written in such a way that it is relatively simple to extend or swap out the key agreement phase to use other algorithms (for instance I was able to add KYBER as a second key exchange mechanism in a single evening.)

Finally, within the xspasswd/ directory is a password-setting utility using its own user/password file distinct from the system /etc/passwd, which can optionally be used by the xsd server to authenticate clients.

Installing and Running

See README.md in the repo top directory.

Architecture

Planned Work

The author's experimentation with the HerraduraKEx algorithm and its implementation in Go, combined with a desire to devise an independent implementation -- or alternative to -- ssh, served to inspire this project. Subsequent work to support other key exchange/encapsulation algorithms made it seem prudent to rename the project from hkexsh to xs, as it was no longer a remote shell exclusively reliant on the initial KEx/KEM algorithm used.

Candidate PQC algorithms implemented since the initial proof-of-concept:

Other algorithms considered, but not yet implemented:

SLOCC (Standard Lines Of Code Count)

xs versus openssh-portable SLOCC