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

Update page 'Home'

Russtopia 2018-11-14 01:03:41 -08:00
parent 04427917bb
commit 8af4af9979
1 changed files with 20 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
Home.md

@ -6,46 +6,38 @@ 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 an experimental key exchange algorithm to Go (see below)
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, similar in role to ssh, offering
* encrypted interactive sessions (remote shell)
* non-interactive scripted remote command execution with pre-arranged client/server auth tokens
* local-to-remote and remote-to-local file copying
* secure tunnels
.. in other words, most of what ssh does except (for now) tunneling.
.. in other words, most of what ssh does.
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 and session configuration (ie.,
one-shot command vs. interactive shell session and other session parameters) for
'secure' sockets using the experimental HerraduraKEx key exchange algorithm,
first published at
[Omar Elejandro Herrera Reyna's HerraduraKEx project](http://github.com/Caume/HerraduraKEx).
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 and session configuration (ie., one-shot command vs. interactive shell session and other session parameters) for secure sockets using experimental public-key exchange and key encapsulation mechanisms such as
UPDATE: Now also can use the experimental Kyber IND-CCA2-secure key encapsulation mechanism (KEM)
* The 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) [https://pq-crystals.org/kyber/](KYBER IND-CCA-2).
The `hkexsh` client follows a standard Golang client connection style, but replaces
calls to raw `net.Dial()` with `hkex.Dial()`, and likewise the `hkexshd` server uses
`hkex.Listen()` to obtain connections conforming to the basic `net.Conn` interface.
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.
Upon `Dial()`, the key exchange is initiated (whereby client and server
independently derive the same keying material) and an agreed-upo session key
and crypto algorithm are used to secure the individual session.
Upon `Dial()`, the key exchange is initiated (whereby client and server independently derive the same keying material) and an agreed-upo session key and crypto algorithm are used to secure the individual session.
Above the `hkex.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 `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).
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 a prefix or suffix to the ciphertext to further complicate analysis.
-----
*NOTE: THIS PROJECT IS EXPERIMENTAL. Due to the experimental nature of the HerraduraKEx and Kyber IND-CCA-2 algorithms, this package SHOULD BE USED WITH CAUTION and should DEFINITELY NOT be used for any sensitive applications. USE AT YOUR OWN RISK. NO WARRANTY OR CLAIM OF FITNESS FOR PURPOSE IS IMPLIED.*
**
***NOTE: THIS PROJECT IS EXPERIMENTAL. This package SHOULD BE USED WITH CAUTION and absolutely SHOULD NOT be used for any sensitive applications. USE AT YOUR OWN RISK. NO WARRANTY OR CLAIM OF FITNESS FOR PURPOSE IS EXPRESSED OR IMPLIED.***
**
HERRADURA KEX
@ -53,11 +45,11 @@ As of this time (Oct 2018) no verdict by acknowledged 'crypto experts' as to the
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, for purposes of simplicity of code and to evaluate the algorithm in operation by itself (again, THIS PROJECT IS EXPERIMENTAL.)
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.)
-----
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 KYBER768 as a second key exchange mechanism in a single evening.)
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
using its own user/password file distinct from the system `/etc/passwd`, which
@ -80,6 +72,7 @@ Planned Work
--
While the author's experimentation with the HerraduraKEx algorithm and its implementation in Go served to inspire this project, it is a further goal to support other key exchange/encapsulation algorithms, at which time this project should probably be renamed as it will no longer strictly be the 'Herradura Key Exchange Shell'.
Candidates under consideration for alternate KEx algorithms:
* [NewHope](https://www.newhopecrypto.org) == [(golang implementation)](https://blitter.com/gogs/Mirrors/go-newhope)
* [Kyber](https://pq-crystals.org/kyber/index.shtml) == [(golang library)](https://blitter.com/gogs/Mirrors/go-kyber)
* [Kurosawa-Desmedt](?)