Hidden Lake Anonymous Network: Transition to Post-Quantum Cryptography

[Man]

Introduction​

All we know about the current state of quantum computers is their constant and systematic improvement, which we observe from open sources. At the same time, we still do not know the real balance of power - it is not known who exactly is leading in the race to create quantum computers, who could potentially have already created or is close to creating such a powerful quantum computer that could crack the asymmetric algorithms of modern cryptography.

Information of this kind will never be disclosed to the public, because the use of such powerful quantum computers will be beneficial to the leading state due to its further ability to successfully decrypt all previously saved ciphertexts and, on their basis, blackmail politicians of other states, participate in wars with a predominant amount of open information about the enemy, lobby the interests of its business, increase capital on cryptocurrency hacking schemes, bank security, declassification of stock exchange transactions, etc., etc. As a result of all this, the development of quantum-resistant algorithms, as well as their further implementation, is an extremely important link in the modern development of secure communications.

Relatively recently (August 13, 2024), NIST published the final versions of three post-quantum standards, which included such algorithms as Kyber, Dilithium, Sphincs+, renamed hereinafter as ML-KEM, ML-DSA and SLH-DSA respectively. Based on this favorable event, I decided to transfer the Hidden Lake anonymous network to post-quantum cryptography algorithms and show what features I encountered during the transition.

Hidden Lake in Brief​

Hidden Lake (HL) Anonymous Network is a decentralized F2F (friend-to-friend) anonymous network with theoretical provability based on queues (QB-problem). Unlike well-known anonymous networks, such as Tor, I2P, Mixminion, Crowds, etc., the HL network is able to withstand global observer attacks. Hidden Lake networks do not care about such criteria as: 1) the level of network centralization, 2) the number of nodes, 3) the location of nodes and 4) the connection between nodes in the network to anonymize their traffic.

A more detailed analysis of the Hidden Lake network can be found in the paper:
-> Anonymous network "Hidden Lake" .
Hidden Lake repository: https://github.com/number571/hidden-lake
go-peer project repository: https://github.com/number571/go-peer

QB task​

A queue-based task can be described by the following list of actions:

1. Each message m is encrypted with the recipient's key k : c = E k (m),
2. Message c is sent in period = T to all network participants,
3. The period T of one participant is independent of the periods T 1, T 2, ..., T n of other participants,
4. If there is no message for period T, then a false message v is sent to the network without a recipient (with a random key r): c = E r (v),
5. Each participant tries to decrypt the message received from the network: m = D k (c).

QB network with three nodes A, B, C

For any passive observers, including the global observer, the QB task is considered difficult to solve, because it hides not only the connection between nodes, but also the state of such nodes: 1) does the analyzed node send any messages?; 2) does it receive them?; 3) or is it completely inactive? - these are the questions that the task raises.

Encryption function​

The encryption function E in the Hidden Lake network consists of two stages:
1. Encryption of the message with authentication using asymmetric keys E',
2. Encryption of the message with authentication using symmetric keys E''.

E (k, privA, pubB) (m) = E'' k (E' (privA, pubB) (m)), where
privA is Alice's private key
pubB is Bob's public key
m is the plaintext
E'' is the second stage of encryption
E' is the first stage of encryption

The first stage is the basic one in the concept of security and anonymization of network traffic. It performs the role of binding the message to a specific node by its public identifier (key), and also brings the message to a static size in order to neutralize attacks on the length of the transmitted data.

E' (privA,pubB) (m) = (E pubB (k') || E k' (pubA || s || h || S privA (h) || m')), where
h = H mac(s) (pubA || pubB || m') is the hash sum
H mac is the message authentication code based on the hash function
m' is the message expanded to a static size
pubA is Alice's public key
pubB is Bob's public key
S privA is the signature function
priva is Alice's private key
s is the cryptographic salt
k' is a random session encryption key for one message
E k' is the symmetric encryption function
E pubB is the asymmetric encryption function (key encapsulation mechanism)

The second stage is the basic one in the concept of network isolation from other networks. It plays the role of delimiting nodes by their binding to a group, using a network key for this. This becomes necessary because the QB task has a scalability problem, where the load on the system begins to depend linearly on the number of participants in it. Also, this stage brings the message to a dynamic size in order to neutralize attacks on determining anonymized traffic by the static length of messages.

E" k (m) = E k (p(h) || h || mv), where
h = H mac(k) (mv) is the hash sum
mv = (m || v) is the concatenation of the message m and random bytes v
p is the proof-of-work function
k is the network key

Cryptographic primitives used​

The AES-256 algorithm in the CFB (ciphertext feedback) encryption mode was used as a symmetric encryption function. The SHA-256 algorithm was used as a hash function, as well as HMAC based on it. RSA-OAEP was used as an asymmetric encryption function, and RSA-PSS was used as a signature function. At the same time, one 4096-bit key was used for both schemes, which was quite acceptable, since the OAEP and PSS schemes allowed the division of the key logic.

Of the primitives used above, RSA turned out to be the weakest, since its security directly depends on the success of the development of quantum computers. In addition to RSA, the SHA-256 hash function also becomes weaker in theory, since there are assumptions that Grover's algorithm will be able to perform an attack on the birthday paradox more efficiently: not in 2 n / 2, but in 2 n / 3 operations. Thus, the security of SHA-256 to brute force attacks becomes equal to 85.(3)-bits, not 128-bits, which is already unreliable. The AES-256 algorithm is the most secure primitive, because even using Grover's algorithm, the security of the scheme will decrease from 2 n to 2 n / 2, but will remain at an acceptable 128-bit level.

Transition to post-quantum algorithms​

It is quite easy to secure the hash function - you just need to replace SHA-256 with SHA-384 or SHA-512 from the same family, so that the minimum security level becomes at least 128-bit. The situation with the RSA algorithm is more complicated, since its security cannot be improved in the long term by simply increasing the key length. It is assumed that a quantum computer will start successfully cracking RSA only when the number of its stable qubits becomes equal to 2n+3 , where n is the key length. Thus, the complexity of cracking RSA will grow linearly O in the key length, and not exponentially O(2n).

• Although I have always used RSA as an example, this attack (using Shor's algorithm) can be extended to any other type of widely used asymmetric algorithms based either on the factorization problem (RSA, Rabin's scheme) or on the discrete logarithm problem (Diffie-Hellman protocol, ElGamal scheme), including the elliptic curve interpretation (ECDH, ECDSA, ECIES, ...).

The idea of moving the Hidden Lake network to post-quantum cryptography began - ironically, but the day before the final standardization of quantum-resistant cryptographic algorithms. During this period, there were several concepts on how to continue the development of the project:

1. Continue using good old RSA. At first glance, this seems very strange and short-sighted, but there is logic here. Firstly, the RSA code has already been written and tested, secondly, even if quantum computers are created, they will primarily crack smaller RSA keys - 1024, 2048 and 3072, thirdly, the main practical problem facing quantum computer developers is in the plane of successful and long-term qubit binding. If we accept as an axiom that the development of quantum computers is carried out mainly in the open, then with the first successful RSA hacks we will have time to switch to quantum-resistant schemes. This concept can be described simply - "don't panic ahead of time", or "when it stings, then..."
   The problem with this approach is not even that quantum computers can be developed mainly in a hidden way, as in the fact that for an attack it is only necessary to save ciphertexts "today" (when there are no powerful quantum computers yet), and use them "tomorrow" (when quantum computers with a large number of qubits and their good stabilization are created).
2. Switch completely to symmetric cryptography. Perhaps this is one of the most controversial and at the same time one of the most conservative ways to combat quantum computers - simply remove all asymmetry. Since the QB problem is not tied to specific encryption algorithms, it can relatively easily be guided only by symmetric ciphers. As a result of such a concept, the general system actually regresses, entering into the problem of old classical cryptography about the secure transmission of the encryption key. It would be possible to use other programs for transmitting symmetric keys like GPG, but they must also be quantum-resistant, otherwise there is no point in switching to symmetric cryptography. But in this case, since we must use quantum-resistant asymmetric algorithms one way or another, maybe we should implement them ourselves so as not to tie in additional applications?
3. Switch fully to new post-quantum algorithms. This is a classic and, in the long term, the most correct way for applications to switch to new and more secure cryptographic algorithms. At the same time, the two-stage encryption function of the Hidden Lake network will not be changed in any way in its abstract / formal representation. But this approach also has disadvantages:
   1) The algorithms presented by NIST are very new for such a conservative science as cryptography. Potentially, they can contain as yet unknown vulnerabilities that will completely destroy the security of the entire system. This happened with the SIKE algorithm, which was hacked by a classical computer in early August 2022.
   2) Two of the three standardized algorithms are based on lattice theory, where hacking one can lead to hacking the other. At the same time, the remaining third algorithm - SPHINCS+ (based on hash functions) is only capable of creating digital signatures, but not encrypting messages / encapsulating keys. Thus, currently there are no standardized alternatives to KEM (key encapsulation mechanism), except ML-KEM (Kyber).
   3) The volume/size of asymmetric keys, as well as encryption/signing results, increases significantly. For example, the RSA-3072 key, providing a 128-bit security level, in the encoded state (PKCS1) occupies 1767 (private) and 398 (public) bytes. The same 128-bit security level for the ML-KEM-512 and ML-DSA-44 algorithms occupies 1632 (private ML-KEM), 800 (public ML-KEM) and 2560 (private ML-DSA), 1312 (public ML-DSA) bytes, respectively. The problem continues in the fact that it is necessary to use two algorithms at once - both encryption and signing. Because of this, the key lengths are summed up, and now it is necessary to store 4192 (private ML-KEM+ML-DSA) and 2112 (public ML-KEM+ML-DSA) bytes. The size of encrypted (OAEP) and signed (PSS) bytes for RSA-3072 is static and equals 384 bytes. For ML-KEM-512, the encapsulated key size is 768 bytes. For ML-DSA-44, the signature size is 2420 bytes. In total, if you need to sign a message and then encrypt it, you need to stock up on 3188 bytes (ML-KEM+ML-DSA) instead of 768 (RSA-OAEP+RSA-PSS). And I compared all this with RSA - one of the most voluminous algorithms in terms of output and key length (only pure ElGamal schemes are more voluminous). It's scary to compare it with elliptic cryptography algorithms.

As you can see, all three options are not ideal. If we proceed from simplicity and hope for open information about the development of quantum computers, then the first concept is the most suitable. If we proceed from the fact that information about the development of quantum computers in the public domain is most likely old, and quantum computers can hack confidential information now, even if they have not yet been invented (the threat of "Build now, hack later"), then in the long term it is better to choose the third option. The second concept is very specific, since in fact it does not fight quantum computers in any way, but only transfers the area of responsibility to third-party applications. Although the system ultimately becomes "cleaner" with such a transfer (in the sense that the system really gains immunity to attacks of a quantum computer due to the lack of asymmetry), but at the same time, ease of use is greatly lost.

Despite all the existing shortcomings of the third concept, the HL network still switched to post-quantum algorithms ML-KEM-768 and ML-DSA-65 (using cloudflare/circl implementation for the Go language), replacing RSA-4096. I was guided by the fact that it is better to trust in the security of new cryptographic algorithms and put up with a large key length / encryption + signing results than with a 100% guarantee of disclosure of current and future messages by quantum computers.

The choice of ML-KEM-768 and ML-DSA-65 (192-bit security level) instead of ML-KEM-512 and ML-DSA-65 (128-bit security level) was made from a conservative point of view, which is also recommended by the authors of these algorithms (1, 2). In addition to the recommendation, the 192-bit level is really necessary for the Hidden Lake network, since each message sent must use both of these algorithms with unchanged keys, which cannot be said about the symmetric AES-256 algorithm, the key of which is generated for each new message at the first stage of encryption.

Consequences of the transition​

The most negative consequence of the transition to post-quantum cryptography was the reduction of the payload from 6.5KiB to 1.7KiB with an unchanged 8KiB message. The encryption function was designed in such a way as not to form communication sessions, so it is possible to maintain communication between subscribers only through direct and constant transmission of the encapsulated session key (generated by ML-KEM) and identifier (public key ML-DSA) in the message itself.

Another negative quality was the division of personal identification into two asymmetric keys ML-KEM and ML-DSA, while previously one RSA key was used, but with different encoding schemes OAEP and PSS. The latter case allowed specifying only one key to the interlocutor, but now it is necessary to specify two. The situation leads to the fact that the interfaces for encryption and decryption of messages are changing:

// For RSA
type IClient interface {
    ...
    EncryptMessage(asymmetric.IPubKey, []byte) ([]byte, error)
    DecryptMessage([]byte) (asymmetric.IPubKey, []byte, error)
}

// For ML-KEM, ML-DSA
type IClient interface {
    ...
    EncryptMessage(asymmetric.IKEMPubKey, []byte) ([]byte, error)
    DecryptMessage([]byte) (asymmetric.IDSAPubKey, []byte, error)
}

Because of this change, applications performing routing must be able to relate one public key to another by associating them with one identity. Of course, you can return the old interface, but in this case: 1) the IPubKey argument in EncryptMessage will become redundant, since IDSAPubKey will not be used, 2) the IPubKey result in DecryptMessage will lead to an increase in the message size, since it will require storing two keys in the ciphertext, instead of one. For this reason, in the console messenger secpy-chat (based on HLT services, HLE network Hidden Lake) it was necessary to change the execution logic due to the changed yml file:

# For RSA
Alice: PubKey{3082020A0282020100A5441C70EF416118C69B0E4465DEAA56050B150AFFCB780A92C70948C47236DEF0EED9B29DAB5FAD714F5D4F3A4317A11B6AEC55790C549E755A2E8BF1E56CBF8CFB4E799E04D75FE9C8CB5132F0060672A50879CEE5A007A96B1E6D8BAAA11D6BC473D1644C47208920299D7C5E9759BBA436209F1807123B2416A1A242E682AACDDD3E6E94C19298EA5DD1F5F29D0F24CFAC894101E8CEA123D9C2E1913D4B2EAFE8BC6EE569CB5CF65481B732818778F0ACCECDC74EDD8B6AA54CB6FFD50F67CFC65090A7D8DB88F3AE37DBB6A7E7ED37C7FE3BE786A33C361ACFE85C730A63C7C67D74E1A060BE6E33A504D3F978DCD0FDB162BFACD8458FB3F6144465D95F9C96F2B44A578ED397668112EE5EAF8544F047CD30B6EBD3CFEA8493698996BF22C720989B9CBB706B6A2DBC9002DAE3300A8EAC92FE9327C1B5E9613322C03F9DBA58E8BC6998810E2F15A24C2ABFA4A58F45F1913685A75C658A3A5570523642CDBB721A79D55812D9F209A33F14BB3145D30F41B8C400DAD856C592A8E8FF8133948C75B8F4081558494CEB20F90405750603D95E2117331DBCD7CDED6F58DA65FE77764D881E0C41155AA37C4E304D8B2946ADC3A896937D799ED1F49BDD655E15292C35CCCCAEB61C8A8D69AA97FC3B0FCCC131B39E184007C84CF7C1F06FF0F26216E9F353F06272C86E6F983E8A061EA7132704091546325D3324D10203010001}

# For ML-KEM, ML-DSA
Alice: [
2f964ce591c3bb9421bc68886f28063df201f9b361378987435731c18274a889af199098c4d43e3417bea6c20f18d46f9f9c03705a394fa05f59b162fd649538a1c293ab04f610c3e3f355ec09c350838d6e473872727b1197725d4a2bea50888918586d9a140ccc526ba6379c36cb1bb26f32c87843442dce8911f33284839a0c7af1b7fa090c3ae1c061582ba9557645a33df1b6ccd2a212348b8ee3964436c866cea58b58e0196b8583d46202677a303ddc869d687576c8b26364adec19b49a476216e12319a68e7dda8bae5257ddd48b036920d7e44af99b5bc468c2432b1100a672323818e5f0b4a84a5a20111bd6b870ee81b949537efc29859aa4642e6a5b947103fa1033ace95476aa9b888113f6c059249496d4b4113ed4a64c120e3b24ca662549559b592be33106fa7fac915b1072180a259a2a49098b256af99b2f9b8a4bcf1912d0343c91b5295be2723533a139824a8af5c51d787c38690a5f0bc230a047a99911e2fa7d9e9c465ffbc6f151812c08a308837b6df1b71590b6c5b33a1066390f658d02f214afa73b67031279646443528500e2765ec05a6a9184fdc39bee649acca1029f18b18445786110c47c1264c6a1a056e315d4359f0ef89d1d3a5f839c17eb9c9f60f7234439760ab72bd6d661670866451130a7c84893d429c4950105461683f5b891a37ecd318624a178010aa6c54c5cb6f5107a6c495a25b31be16c55e2cb642a6ddac77534c3411f7c4f89f8c619d87d326628c85a5ca1567c336098f9611b8df49906524e36509aa71a8a69fc2e61503d0f786cb37162a06ac97f042ccdd0ca2c45601f220684f5114f767927806d66378d33b26f0b807131891305d53c1b5a6d9b144777db270053bbc6a94b82707d831b58489376b1c8362466121bc77fad5956198bc049c588e7a03644f8ad75f66cb7c3a449aacdf55421c61703ce286a0e980c6ff24d8f958d3fa0a88f5177e90ac938f190ead1c00307cf0578223a97b0fe64794eb55a3512a3d39b80755b4a15b7c67a3c5eb3ca171ecbbd8ef46a9eec0c593349c88655fd9844797b6c7b041188e7832d2981264b5f0bc0a073b3a2b3a48d29d0b8a850c4d1816b894b7fec1a58ccb0a86e971263651821e72ca1bc78d58a1cffc770e51cb1fe76583523255d657d3c6b9352c94b8e044eb94ca165a070ec606cc6883cefb9556662791d213b580a0dbad5ae9032048dacc4b190bf11020d0e065bc5356537405fcd39c1eb8a3867a1b71bf83aa89489f8e98122b20953743649d27c56908ed1e32038b88d0b8237ffe792cf0595f3533905fa9250ea228449023a7845c118860d9a8155136b2b8063cee015a1b23302a83e902068f60030aef8a9e457093f7901dd0547d4b69e9d07467ea1ce06e218598b20cc917b118201d993ab833757f1e8a8367b61ae18551b82708df58fb9e25e1e9a3dfc26a5e59b8a1956a21d524c5ff39ec2c10142d0441a394432c729cd12066ce87636325003c515cb89ce0383aaac42c39c335ab760661ccba871b5717d951143ccc7e9647dfc2120a69762ac1b74f4ac554d96acd47258bc64a190e48aaf816323209b793308310c6dd7fb8b2f0a28598b61303810be5e2b0c7c7ec542145fb9c30a2763ba21173b083cdca43dad20d39a501c01b6,
    912cfef38cc18d3c5b59817dcbe5da1ca954bb8f7ca5f34a099f1811e9013eb3ad1330418f456fd15208deb301c138cb854a43b05cc897d63c86234d972d81327b8fe90407026c40ffdec1e5b1ce455ec1824acb14447345e92a1fd882715ac69b580c292fa4fd1099b8425fd3c6d872876ba5cb6b58595dbbeb3ddea7b6ee23f07ec88e9014f87d3bd860e9dd723c672c2aede20b9ddf4365a63f4a16a093d3bb8830daa3162c37572ffa71e79cc02b79e4a9441cdf3625f837fefc57b2674d0f4db7031b347fa6a223d39de8900cd5e86f80c9a60930c26b7f573ac479a28b1be2278644599c93fb1469becff36bcf7f8595e3f793e22a6caaa56a59187a9602be8ab3b2bfec06114eb417d6cf2dfadc0614a0807c78ee6c52ef492a78869d51a907db2374a86e621a27ee5cbb0e6d71a86897a1b08481ee51bd38811357c9fb3dc7bc1aa8a42a283be27b3c086cd05a2694038997095f276ccbb5aea18e677e3ba17397fd9f2041dc3053e2576315273ef570191ed894609444fd5d28ebc460ec5243dd19ebe3a152281ee35291a4b9fdd40b20705d78782ee2e02a77a3840892ab1b5ca58c030a37cbc99fbe09147b108f27eb2633d1787d69611d86873217b3a18695039825b713d84f0212761ae6034b7142a3f78e89b6341a505f4adf72a894d6d7f8e2096d25c366c3e264acf0691507d8b7cc2e54c3fa615868bd4674e6e8e2508c0c4b979a1f03548cf125db2272e1a51e9a7a5a91de9a978ce4e4ba524e931021344d7808c1144d390b048a7ac573629d2c63b3a99e79afd0e6b3da617e3b455b17264fdd74deacac05307dda5968da2a033229c1459d4cf75a41b5ac57cb8df6fce26ceaef8c56461fe0aca7159390f8fd5ee950b3d947860b0e33fdf03be9e69fe9db562cb6874e1778fda9c12a963b22f70af2520f0636554d9349eb562ef1388b8e24d795434cab7fc86e9ce1994bea8e31e75c7c1fad392333b888f16bc457464cc0080d9d35244c1931abd3e50d88a63502aa8ed5098757be4c55825e5c99d9c7092126b828491a5c0096cf12e18c1725c6b4760ab9bc33e94248089531b4513ce703b44b2790628cf0d8b73b8a38ee5cb7e2bebd4760691ea9d32ed07acb5a37712eccb52e4408b0e6175e2faf42725e348d0c2ff98383a5d8a8eadcf6b88f5331a5c9776d3e7c1370b91d19df6d37076339ca6a4936bf4e507045ecae4cac0ec08fcfe9d3322d908fdfbe107976eefcda2b07151156fa3d630566905614c430c9ac71dbf0827047863b339e6529742b7033828718be748213041abfd61cd9fa1b2075493feab6289f41dc1eefb82f01987e66186566c760708eb8d3a93dc522caee0d1f22b6a0348b088b992febcb2f184fa65164fce2392a6cdfad7794e4f3ba488336c7c06a507675de859603aa998713b367f038b92a11bdde9e524b1aff289c0b3130edb9662e7a74b9f9662de065ddd51123446fe1bfdc39ed82ad76f2967015811916ce45289ac19a176d6fcc96dbb1298a5aff9012db1a7ebeccc2231431f52603f4337bf2cdbf6449bc1a3c7ba620869486b16137bb4065ba398298deffd2c59e0d4631df9ca0c34ac24a7d1af7a8d68eb19337c683e155c2515841d214de944b4acb4ec3dfef399cfb681c4ef0a47e9ffe620a89d12ef87df6e83e7d0f1459eb4046102c5f1da723b4faec9f18e90a06b00d22f67f39cc7935920e27e3c19538b16ae122da420ed60cc095bd2bde8fde39c633aebcab8762865bf12c48e655d7ae961e71ecea6ee6e01a25d5af0dfb105d7d4f21968550227abb2c3905ccf2d708e53a235e8345609e7b9ce64edd20eede936a9d735653d96ad8cdaa480bbc7699ddc2a6e14cc768b910a3b6cade369d8084a835ee75dc238c147e94a6f7076e00b7b6f1c46740883b134268199ba0397b21e7d19c36a7a01450fb0b96539be19649d60479419df46e88ae2d9f7303ad5a3eb4b4b60c6aefd71303f51f37e9d202d6bacefb38be1009d8ac55f7808e419627cc1a3815f85780b065f7181008d0c90c0f9bf544804d9534f5986ba2bc5417f7c8d30e8f59107037e013cbbb4802146daa63d17dc9bef6c108a00701f7467f59b70917ddb3e8fd52ea75eb699e79c063c3efc1158ac678201ef1d6af571cb5ed70e4783d943420609d9db32b2fb6d888d18bfccdaf994cfcfaf13e0af23beed1192ab96156b4ca275adcaeb9f0f9453aa237c98fcc676450d88857eb1918883ea0f3d3b45fbf00ead8464e5ab2281c3aaed499ea6c41713dab00b3bd6ca42a52eb06edfcf7f48a548ed7a6756e8be4b48996e1e383317366716ada742ed880f9fd88384ff51174538d945fa9e5fab65a601a599b3ed2f2631dccc2cb6341e825d3bae35d5b29e1f5debf69ddf321c978322185d191fbbb3bc4f3b2d8cc1effaa3606902cd28de7a0051e0309e539a673c66ccf709a4863c48bf65a3e2d49df9bd9f5b44eb16357e94ef24c46a7e01be36e34162dd29ceeaf5f88b8c17034fac29519565f73b4db6e6c0c97c34d659a387eed796e5096c871d35fdf71d08bd224e5f00d2697b2b342f520be1be68d4a6185f11212a72e579ac148c0b2fc6f253c531cdc7766647326b256356f2a54d62343abc7670d64d9cbcfb29c0074b3ba5d261dafd026a9101f4357ae96a8c29d4e2bce8766906bb11beb45ccec5b6d956ec29b864b6b39e155482c09506f39c3415341ff226c40a02aa7fcb6721364a28c
  ]

I have already talked a lot about the disadvantages, but are there any advantages besides the cryptographic resistance against quantum computer attacks? And surprisingly, there are, in comparison with RSA-4096, the ML-KEM-768/ML-DSA-65 algorithms are capable of performing calculations very quickly. For example, according to benchmarks, 100 RSA-4096 encryption/signing operations were performed in 805.5634ms and decryption/verification in 706.869091ms. At the same time, according to similar benchmarks, 1000 ML-KEM-768/ML-DSA-65 encryption/signing operations are performed in 254.339142ms and decryption/verification in 132.305197ms. The difference is 8055/254~=31.7 and 7069/132~=53.6.

One may ask a quite logical question - is such a speed necessary in a network where nodes must generate some message only once every five seconds? Surprisingly, it is necessary. The positive quality of the increased speed (especially decryption and signature verification) has a positive effect on the ability to decrypt received ciphertexts from the network in a timely manner, thereby allowing the system to contain more users when committing DoS and DDoS attacks. With the current RSA, an attacker previously needed to generate 5000 (ms) / 7.5 (ms) / 5 (per second) ~= 133.4 ciphertexts per second so that the speed of node decryption could not keep up with their acceptance. Now it is necessary to generate 5000 (ms) / 0.254 (ms) / 5 (per second) ~= 3937 ciphertexts per second, which is an impossible value with a bandwidth of 100 Mbit/s, because exceeds the limit of 1600 ciphertexts (8KiB each) per second. Thus, the bottleneck changes its position from slow decryption to the limit of the communication channel. To prevent the channel from becoming clogged, the Hidden Lake network has a proof-of-work mechanism that increases the encryption time of each message from 0.254ms to ~1.98s.

Conclusion​

The transition of the Hidden Lake network to post-quantum cryptography, although it added a lot of problems to me, such as: increasing the key size, increasing the size of the outputs of the encryption / signing functions, changing the encryption / decryption interfaces, but I think that this is the most correct decision. The current state of affairs is such that: either we take a risk and use post-quantum cryptographic algorithms in our systems that have passed NIST standardization, already now having a certain chance of being unhackable in the future, or accept the fate of comfort and increase the probability of hacking our current messages in the future to one hundred percent. This may seem paranoid, but given the existing Yarovaya package and SORM-3, preserving all incoming traffic, the PRISM project, concluding an alliance between the NSA and Microsoft, Apple, Google, given the existence of obvious interests of various states in the advanced development of quantum computers - the threat of "Build now, hack later" is becoming more than real.

Source