README
¶
Theoretically Provable Anonymous Network
The Hidden Lake is an anonymous network built on a micro-service architecture. At the heart of HL is the core - HLS (service), which generates anonymizing traffic and combines many other services (for example, HLT and HLM). Thus, Hidden Lake is not a whole and monolithic solution, but a composition of several combined services.
By default, the anonymous Hidden Lake network is a friend-to-friend (F2F) network, which means building trusted communications. Due to this approach, members of the HL network can avoid spam in their direction, as well as possible attacks if vulnerabilities are found in the code.
[!IMPORTANT] The project is being actively developed, the implementation of some details may change over time. More information about the changes can be obtained from the CHANGELOG.md file.
Currently, the anonymous Hidden Lake network consists of six services: HLS, HLT, HLM, HLF, HLR, HLL, HLE. The main services include only HLS. The application services are HLM, HLF and HLR. The helper services are HLT, HLL and HLE.
More information about HL in the hidden_lake_anonymous_network.pdf and here hidden_lake_anonymous_network_view.pdf
Coverage map
How it works
The anonymous Hidden Lake network is an abstract network. This means that regardless of the system in which it is located and regardless of the number of nodes, as well as their location, the HL network remains anonymous. This property is achieved due to a theoretically provable queue-based task. Its algorithm can be described as follows.
- Each message is
encryptedwith the recipient's key, - The message is sent during the period
= Tto all network participants, - Period T of one participant regardless of periods
T1, T2, ..., Tnof other participants, - If there is no message for the period T, then an
empty messagewithout a recipient is sent to the network, - Each participant
tries to decryptthe message they received from the network.
Figure 1. Queue and message generation in HLS.
According to the interaction of nodes with each other, the Hidden Lake network scheme can be represented in the form of three layers: network (N), friendly (F), and application (A).
- The network layer ensures the
transfer of raw bytesfrom one node to another. HLS and HLT services interact at this level. HLT is an auxiliary service that is used to relay messages from HLS. The HLT can be replaced by an HLS node. - The friendly layer (also known as anonymizing) performs the function of
anonymizing trafficby setting up a list of friends and queue control on the side of the HLS service. Cryptographic routing based on public keys works at this level. - The application layer boils down to using the final
logic of the applicationitself to transmit and receive messages. One of the main tasks of this level is to control data security, provided that intermediate (group) HLS nodes exist/are used.
Figure 2. The scheme of the anonymous Hidden Lake network.
The above-described paradigm of dividing the interactions of network participants into levels can also be displayed through the prism of message layers. Unlike the method of separation according to the interaction of nodes with each other, in which there were three levels, there are four levels at the level of consideration of the message structure. This is due to the fact that the second and third levels are interconnected through an HLS service that performs the role of anonymization and message transportation.
Figure 3. The layers of the Hidden Lake message.
Since the anonymous Hidden Lake network is formed due to the microservice architecture, some individual services can be used outside the HL architecture due to the common go-peer protocol. For example, it becomes possible to create messengers with end-to-end encryption based on HLT and HLE services, bypassing the anonymizing HLS service (as example secpy-chat).
You can find out more about the message levels using the following schemes: layer-1, layer-2, layer-3, All schemes can be found in the hidden_lake_message_layers.svg file.
Possible ways of application
The anonymous Hidden Lake network is similar in the way it is used to client-secure applications such as RetroShare or Bitmessage. The main difference from the last two applications is the existence of an anonymizing property, which makes HL also related to existing closed anonymous p2p networks of the I2P type. However, the Hidden Lake network is not an ordinary composition of two ideas in the face of combining traffic anonymization and client-secure application architecture, because among other things, it is also an abstract anonymous network. As a result, HL network, for successful anonymization of traffic, criteria such as the level of centralization, the number of nodes in the network, the location and connection of nodes among themselves become irrelevant.
On the basis of this characteristic, methods of possible application also begin to be built:
- Due to the property of abstracting from network communications, the anonymous Hidden Lake network can be
integratedinto any other network (including a centralized one) where group communication is possible. In such a case, the HL software implementation provides for the essence of adapters that must be able to adapt to a specific execution environment, hiding and obscuring the generated parasitic traffic, - Due to the
theoretically provable anonymityand independence of nodes among themselves in choosing the period of packet generation, the network can be used in military affairs, ensuring not only the confidentiality of transmitted data, but also the confidentiality of metadata in the face of the activity of actions, - The Hidden Lake network can be used as a
communication platformfor applications that are heterogeneous in nature. This is made possible by the go-peer protocol, which does not define any application use. As a result, you can create your own applications at several levels: either at the go-peer library level or at the HL services level (example), - Due to problems with scaling at the level of the
QB-taskitself, the network is difficult to deploy in a global space, which nevertheless does not indicate a local field of action. Hidden Lake can protectlocal networksin a more efficient way due to the existence of small groups of participants that do not vary greatly in number. This may be a relevant solution in the context of the existence of critical areas of a local organization.
Possible launch modes
The anonymous Hidden Lake network has different launch modes depending on the environment in which it is located.
- Classic direct communication. In this communication mode, the nodes are connected to each other directly. This method is convenient only if at least one of the nodes has a public IP address that goes beyond NAT. Example.
Figure 4. The direct communication launch mode.
- Communication via a relayer. In this startup mode, nodes are connected to each other using separate relay nodes. In this concept, relayers become TURN servers that redirect traffic to all connected nodes, including other relayers. Example.
Figure 5. The relayer communication launch mode.
- Communication through a secret communication channel. In this mode, communication begins to adapt to a communication platform other than the primary Hidden Lake network. Example.
Figure 6. The secret channel communication launch mode.
Build and run
Launching an anonymous network is primarily the launch of an anonymizing HLS service. There are two ways to run HLS: through source code, and through the release version. It is recommended to run applications with the available release version, tag.
1. Running from source code
$ go install github.com/number571/go-peer/cmd/hidden_lake/service/cmd/hls@<tag-name>
$ hls
2. Running from release version
When starting from the release version, you must specify the processor architecture and platform used. Available architectures: amd64, arm64. Available platforms: windows, darwin, linux.
$ wget https://github.com/number571/go-peer/releases/download/<tag-name>/hls_<arch-name>_<platform-name>
$ chmod +x hls_<arch-name>_<platform-name>
$ ./hls_<arch-name>_<platform-name>
Production
Running
The HLS node is easy to connect to a production environment. To do this, it is sufficient to specify two parameters: network_key and connections. The network_key parameter is used to separate networks from each other, preventing them from merging. The connections parameter is used for direct network connection to HLS and HLT nodes.
$ wget https://raw.githubusercontent.com/number571/go-peer/<tag-name>/cmd/hidden_lake/_configs/prod/1/hls.yml
$ hls
There are also examples of running HL applications in a production environment. For more information, follow the links: echo_service, anon_messenger, anon_filesharer.
Settings
The Hidden Lake network must have common configuration file settings for successful data exchange between network nodes. If some settings are different, other nodes will consider it a protocol violation and reject the connection attempt. You can find ready-made configuration files for HLS and HLT services in the prod/1, prod/2, prod/3, prod/4 directories.
# default settings
message_size_bytes: 8192
work_size_bits: 22
key_size_bits: 4096
fetch_timeout_ms: 60000
queue_period_ms: 5000
| Available network | Types of services | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
Directories
