Great Renaming (hkexsh -> xs)

Russtopia 2019-10-29 22:46:17 -07:00
parent 45bd46c534
commit 7121b72e2f
1 changed files with 12 additions and 12 deletions

24
Home.md

@ -1,5 +1,5 @@
## The HKExSh
### **H**erradura**K**yber **Ex**change **Sh**ell
## The xs (formerly HKExSh)
### **X**perimental **S**hell (formerly **H**erradura**K**yber **Ex**change **Sh**ell)
Introduction
@ -18,7 +18,7 @@ This project began as an excuse to
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)
HKExSh is a Golang implementation of a simple remote shell client and server offering:
```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
@ -26,17 +26,17 @@ HKExSh is a Golang implementation of a simple remote shell client and server off
.. in other words, most of what ssh and scp do.
The client and server programs (`hkexsh`/`hkexcp` and `hkexshd`) 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 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 experimental HerraduraKEx key exchange algorithm, first published at [Omar Elejandro Herrera Reyna's HerraduraKEx project](http://github.com/Caume/HerraduraKEx).
* The experimental Kyber IND-CCA2-secure key encapsulation mechanism (KEM) [KYBER IND-CCA-2](https://pq-crystals.org/kyber/).
* The experimental NewHope1024-CCA-KEM key encapsulation mechanism (KEM) and its variant 'NEWHOPE-SIMPLE' [NewHope](https://www.newhopecrypto.org)
The `hkexsh` client follows a standard Golang client connection style, but replaces calls to raw `net.Dial()` with `hkexnet.Dial()`, and likewise the `hkexshd` server uses `hkexnet.Listen()` to obtain connections conforming to the basic `net.Conn` interface.
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 `hkexnet.Conn` layer the server and client (`hkexshd` and `hkexsh`) negotiate session settings (cipher/hmac algorithm, interactive/non-interactive, etc.) to be used for further communication.
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.
@ -65,9 +65,9 @@ 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 `hkexpasswd/` directory is a password-setting utility
Finally, within the `xspasswd/` directory is a password-setting utility
using its own user/password file distinct from the system `/etc/passwd`, which
is used by the `hkexshd` server to authenticate clients.
is used by the `xsd` server to authenticate clients.
-----
@ -78,15 +78,15 @@ See [README.md](src/master/README.md) in the repo top directory.
Architecture
--
* [Client Block Diagram](wiki/Client+Block+Diagram)
* ![client graphvis](https://gogs.blitter.com/RLabs/hkexsh/raw/master/hkexsh/hkexsh-vis-fixedup.png)
* ![client graphvis](https://gogs.blitter.com/RLabs/xs/raw/master/xs/xs-vis-fixedup.png)
* [Server Block Diagram](wiki/Server+Block+Diagram)
* ![server graphvis](https://gogs.blitter.com/RLabs/hkexsh/raw/master/hkexshd/hkexshd-vis-fixedup.png)
* ![server graphvis](https://gogs.blitter.com/RLabs/xs/raw/master/xsd/xsd-vis-fixedup.png)
* [Passwd Util](wiki/Passwd+Util)
* ![hkexpasswd graphvis](https://gogs.blitter.com/RLabs/hkexsh/raw/master/hkexpasswd/hkexpasswd-vis.png)
* ![hkexpasswd graphvis](https://gogs.blitter.com/RLabs/xs/raw/master/xspasswd/xspasswd-vis.png)
* [Connection Protocol](wiki/Connection+Protocol)
* [Session Protocol](wiki/Session+Protocol)
* [Graphviz Overall Diagram](https://gogs.blitter.com/RLabs/hkexsh/src/master/viz_hkexsh_dot.png)
* [Graphviz Overall Diagram](https://gogs.blitter.com/RLabs/xs/src/master/viz_xs_dot.png)
Planned Work
--