Считаю необходимым добавление функции автоудаления Онтона из группового чата, т.к. как говорил Владимир Ленин

Цепь прочна настолько, насколько прочно её самое слабое звено

5. The network/anonymity module to ensure anonymity based on the fifth^ stage. Presents the main functions for working with the network on top of the network and queue modules.

expected

based on the fourth^ stage

?

WritePayload issues 4 separate Write calls to the underlying connection.

It may be the case, that OS sends each part of the request in a separate IP packet.

In such case, an observer can deduce size of the message and the void part.

I am going to outline an attack to decrypt some blocks of data using network key. The attack is at network package and network/conn part in particular.

Decrypt message len

The idea is to connect to a node and send some ciphertext to it. The node expects the following:

len(P)||len(V)||P||V

It first read both len(P) and len(V), and then it expects L=len(P)+len(V) bytes.

If we send <L bytes the node is going to timeout and subsequently reset the connection. If send at least L bytes that are not valid ciphertext, we would immediately get a connection reset.

So the approach is simple:

1. Select 4 blocks of data and save it to X. This will be our len(P)||len(V).
2. Choose n as a guess for L.
3. Send X and then n random bytes.
4. If we get immediate conn reset, then n >= L.
5. Otherwise n < L.
6. Repeat, until found.

This setup only gets us L. But we still don't know neither of len(P), nor len(V). The following is going to overcome this problem.

Decrypting Len(V)

Suppose we somehow capture a single encrypted message. That is: len(P)||len(V)||P||V.

The idea is that if we perturb V, decryption will still pass, but if we change P, it will fail.

So we can randomly perturb blocks and check wether we get a connection reset.

This will give us both ciphertext and plaintext of a particular len(V).

Then we can attach this len(V) block to a given len(P) block and decrypt len(P) via algo from previous section.

TL;DR; use TLS, AEAD, AES-GCM and ephemeral keys for transport layer security

From the source:

// Increase entropy by multiple hashing.
func (p *sEntropyBooster) BoostEntropy(pData []byte) []byte {

The comment is misleading. This function does not and cannot increase entropy.

IIUC, this function is a password-based key derivation. That is it derives key-material from a password and the salt.

It is important to only feed passwords as a key. Feeding a proper key material to this function might reduce security. So it might be beneficial to rename the parameter to password.

And last but not least, instead of using a variation PBKDF1, it might be better to use a modern algorithm, like argon, scrypt, or at least bcrypt. What is your position on this?