Update page 'Home'

Russtopia 2019-08-08 22:54:26 -07:00
parent 34f20fa591
commit 45bd46c534

11
Home.md

@ -1,5 +1,5 @@
## The HKExSh
### **H**erradura**K**yber **Ex**change **Sh**ell (Originally HerraduraKEx Shell)
### **H**erradura**K**yber **Ex**change **Sh**ell
Introduction
@ -18,13 +18,13 @@ 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, similar in role to ssh, offering
HKExSh is a Golang implementation of a simple remote shell client and server offering:
* encrypted interactive sessions (remote shell)
* non-interactive scripted remote command execution with pre-arranged client/server auth tokens
* 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 does.
.. 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
@ -38,8 +38,7 @@ Upon `Dial()`, the key exchange is initiated (whereby client and server independ
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.
Packets are subject to random padding, and (optionally) the client and server channels both send _chaff_ packets at random defineable intervals, of a configurable random size range, to help thwart analysis of the encrypted session (both its contents and its timing, eg., interactive shell and keyboard activity). Padding is applied as either (again randomly) a prefix or suffix to the ciphertext to further complicate analysis.
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.
-----