Skip to content

6.1. Hidden Lake Service

#571 edited this page Jun 12, 2023 · 1 revision

github.com/number571/go-peer/tree/master/cmd/hidden_lake/service

hls_logo.png

The Hidden Lake Service is the core of an anonymous network with theoretically provable anonymity. HLS is based on the fifth^ stage of anonymity and is an implementation of an abstract anonymous network based on queues. It is a peer-to-peer network communication with trusted friend-to-friend participants. All transmitted and received messages are in the form of end-to-end encryption.

Features / Anonymity networks Queue-networks (5^stage) Entropy-networks (6stage) DC-networks (1^stage)
Theoretical provability + + +
Ease of software implementation + - -
Polymorphism of information - + +
Static communication delay + - +
Network scales easily - - -

A feature of HLS (compared to many other anonymous networks) is its easy adaptation to a hostile centralized environment. Anonymity can be restored literally from one node in the network, even if it is the only point of failure.

More information about HLS in the habr.com/ru/post/696504

How it works

Each network participant sets a message generation period for himself (the period can be a network constant for all system participants). When one cycle of the period ends and the next begins, each participant sends his encrypted message to all his connections (those in turn to all of their own, etc.). If there is no true message to send, then a pseudo message is generated (filled with random bytes) that looks like a normal encrypted one. The period property ensures the anonymity of the sender.

hls_queue.jpg

Figure 1. Queue and message generation in HLS.

Since the encrypted message does not disclose the recipient in any way, each network participant tries to decrypt the message with his private key. The true recipient is only the one who can decrypt the message. At the same time, the true recipient acts according to the protocol and further distributes the received packet, even knowing the meaninglessness of the subsequent dispatch. This property makes it impossible to determine the recipient.

Simple example of the client module (encrypt/decrypt functions) in the directory github.com/number571/go-peer/examples/_modules/client;

hls_view.jpg

Figure 2. Two participants are constantly generating messages for their periods on the network. It is impossible to determine their real activity.

Data exchange between network participants is carried out using application services. HLS has a dual role: 1) packages traffic from pure to anonymizing and vice versa; 2) converts external traffic to internal and vice versa. The second property is the redirection of traffic from the network to the local service and back.

hls_service.jpg

Figure 3. Interaction of third-party services with the traffic anonymization service.

As shown in the figure above, HLS acts as an anonymizer and handlers of incoming and outgoing traffic. The remaining parts in the form of applications and services depend on third-party components (as an example, HLM).

More details in the works

  1. Theory of the structure of hidden systems
  2. Monolithic cryptographic protocol
  3. Abstract anonymous networks

Build and run

Default build and run

$ cd ./cmd/hidden_lake/service
$ make build # create hls, hls_linux, hls_windows.exe and copy to ./bin
$ make run # run ./bin/hls

> [INFO] 2023/06/03 14:32:40 HLS is running...
> [INFO] 2023/06/03 14:32:42 service=HLS type=BRDCS hash=43A5E9C5...BA73DF43 addr=211494E4...EEA12BBC proof=0000000002256145 conn=127.0.0.1:
> [INFO] 2023/06/03 14:32:47 service=HLS type=BRDCS hash=EFDDC1D4...C47588AD addr=211494E4...EEA12BBC proof=0000000000090086 conn=127.0.0.1:
> [INFO] 2023/06/03 14:32:52 service=HLS type=BRDCS hash=8549E257...EDEB2748 addr=211494E4...EEA12BBC proof=0000000000634328 conn=127.0.0.1:
> ...

Service was running with random private key. Open ports 9571 (TCP, traffic) and 9572 (HTTP, interface). Creates ./hls.cfg or ./_mounted/hls.cfg (docker) and ./hls.db or ./_mounted/hls.db (docker) files. The file hls.db stores hashes of sent/received messages.

Default config hls.cfg

{
	"logging": [
		"info",
		"warn",
		"erro"
	],
	"address": {
		"tcp": ":9571",
		"http": ":9572"
	},
	"services": {
		"go-peer/hidden-lake-messenger": "messenger:9592"
	}
}

If service works not in docker's enviroment than need rewrite connection host in hls.cfg file from messengerto IP address (example: 127.0.0.1:9592 for local network).

Build and run with docker

$ cd ./cmd/hidden_lake/service
$ make docker-build 
$ make docker-run

> [INFO] 2023/06/03 07:36:49 HLS is running...
> [INFO] 2023/06/03 07:36:51 service=HLS type=BRDCS hash=AF90439F...9F29A036 addr=BB58A8A2...B64D62C2 proof=0000000000479155 conn=127.0.0.1:
> [INFO] 2023/06/03 07:36:56 service=HLS type=BRDCS hash=2C4CE60A...E55BF9C4 addr=BB58A8A2...B64D62C2 proof=0000000000521434 conn=127.0.0.1:
> [INFO] 2023/06/03 07:37:01 service=HLS type=BRDCS hash=A9285F98...F96DB93D addr=BB58A8A2...B64D62C2 proof=0000000001256786 conn=127.0.0.1:
> ...

Example

There are three nodes in the network send_hls, recv_hls and middle_hls. The send_his and recv_hls nodes connects to middle_hls. As a result, a link of the form send_his <-> middle_hls <-> recv_hls is created. Due to the specifics of HLS, the centralized middle_hls node does not violate the security and anonymity of the send_hls and recv_hls subjects in any way. All nodes, including the middle_hls node, set periods and adhere to the protocol of constant message generation.

The recv_hls node contains its echo_service, which performs the role of redirecting the request body back to the client as a response. Access to this service is carried out by its alias hidden-echo-service, put forward by the recv_hls node.

...
// handle: "/echo"
// return format: {"echo":string,"return":int}
func echoPage(w http.ResponseWriter, r *http.Request) {
	if r.Method != "POST" {
		response(w, 2, "failed: incorrect method")
		return
	}
	res, err := io.ReadAll(r.Body)
	if err != nil {
		response(w, 3, "failed: read body")
		return
	}
	response(w, 1, string(res))
}
...

Identification between recv_hls and send_hls nodes is performed using public keys. This is the main method of identification and routing in the HLS network. IP addresses are only needed to connect to such a network and no more. Requests and responses structure are HEX encoded.

Structure of request. The body hello, world! is encoded base64.

JSON_DATA='{
        "method":"POST",
        "host":"hidden-echo-service",
        "path":"/echo",
        "head":{
            "Accept": "application/json"
        },
        "body":"aGVsbG8sIHdvcmxkIQ=="
}';

Request format

PUSH_FORMAT='{
        "receiver":"PubKey(go-peer/rsa){3082020A0282020100B752D35E81F4AEEC1A9C42EDED16E8924DD4D359663611DE2DCCE1A9611704A697B26254DD2AFA974A61A2CF94FAD016450FEF22F218CA970BFE41E6340CE3ABCBEE123E35A9DCDA6D23738DAC46AF8AC57902DDE7F41A03EB00A4818137E1BF4DFAE1EEDF8BB9E4363C15FD1C2278D86F2535BC3F395BE9A6CD690A5C852E6C35D6184BE7B9062AEE2AFC1A5AC81E7D21B7252A56C62BB5AC0BBAD36C7A4907C868704985E1754BAA3E8315E775A51B7BDC7ACB0D0675D29513D78CB05AB6119D3CA0A810A41F78150E3C5D9ACAFBE1533FC3533DECEC14387BF7478F6E229EB4CC312DC22436F4DB0D4CC308FB6EEA612F2F9E00239DE7902DE15889EE71370147C9696A5E7B022947ABB8AFBBC64F7840BED4CE69592CAF4085A1074475E365ED015048C89AE717BC259C42510F15F31DA3F9302EAD8F263B43D14886B2335A245C00871C041CBB683F1F047573F789673F9B11B6E6714C2A3360244757BB220C7952C6D3D9D65AA47511A63E2A59706B7A70846C930DCFB3D8CAFB3BD6F687CACF5A708692C26B363C80C460F54E59912D41D9BB359698051ABC049A0D0CFD7F23DC97DA940B1EDEAC6B84B194C8F8A56A46CE69EE7A0AEAA11C99508A368E64D27756AD0BA7146A6ADA3D5FA237B3B4EDDC84B71C27DE3A9F26A42197791C7DC09E2D7C4A7D8FCDC8F9A5D4983BB278FCE9513B1486D18F8560C3F31CC70203010001}",
        "hex_data":"'$(str2hex "$JSON_DATA")'"
}';

Build and run nodes

$ cd examples/_cmd/echo_service/default
$ make

Logs from middle_hls node. When sending requests and receiving responses, middle_hls does not see the action. For him, all actions and moments of inaction are equivalent.

hls_logger.gif

Figure 4. Output of all actions and all received traffic from the middle_hls node.

Send request

$ cd examples/_cmd/echo_service
$ ./request.sh

Get response

HTTP/1.1 200 OK
Date: Mon, 22 May 2023 18:18:34 GMT
Content-Length: 113
Content-Type: text/plain; charset=utf-8

{"code":200,"head":{"Content-Type":"application/json"},"body":"eyJlY2hvIjoiaGVsbG8sIHdvcmxkISIsInJldHVybiI6MX0K"}
Request took 8 seconds

Return code 200 is HTTP code = StatusOK. Decode base64 response body

echo "eyJlY2hvIjoiaGVsbG8sIHdvcmxkISIsInJldHVybiI6MX0K" | base64 -d
> {"echo":"hello, world!","return":1}

hls_request.gif

Figure 5. Example of running HLS with internal service.

Also you can run example with docker-compose. In this example, all nodes have logging enabled

$ cd examples/_cmd/echo_service/_docker/default
$ make

Simple examples of the anonymity module in the directory github.com/number571/go-peer/examples/_modules/network/anonymity;