transition to post-quantum cryptography

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 – we do not know who exactly is leading in the race to create quantum computers, who could potentially already create 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 ciphertexts previously stored by it and based on them blackmail politicians of other countries, participate in wars with a predominant amount of open information about the enemy, lobby interests your business, increase capital on schemes for hacking cryptocurrencies, bank security, declassifying 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, the list of which included such algorithms as Kyber, Dilithium, Sphincs+, further renamed as ML-KEM, ML-DSA and SLH-DSA, respectively. Based on such a favorable event, I decided to transfer the anonymous Hidden Lake network to post-quantum cryptography algorithms and show what features I encountered during the transition.

Briefly about Hidden Lake

Anonymous network Hidden Lake (HL) is a decentralized F2F (friend-to-friend) anonymous network with theoretical provability based on queues (QB problem). Unlike well-known anonymous networks like Tor, I2P, Mixminion, Crowds, etc., the HL network is able to withstand attacks from a global observer. Hidden Lake networks do not need the following criteria to anonymize their traffic: 1) level of network centralization2) number of nodes3) location of nodes and 4) communication between nodes online.

A more detailed analysis of the Hidden Lake network can be found in:
-> 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. Every message m encrypted with the recipient's key k: c = Ek(m),

  2. Message c sent during = T to all network participants,

  3. Period T one participant independent of periods T1T2…, Tn other participants,

  4. If for a period T the message does not exist, a false message is sent to the network v without recipient (with random key r): c = Er(v),

  5. Each participant tries to decrypt the message he received from the network: m = Dk(c).

QB network with three nodes A, B, C

QB network with three nodes A, B, C

For any passive observers, including the global observer, the QB task is considered difficult to complete, because it hides not only the connection between nodes, but also the state of those nodes: 1) does the analyzed node send any messages?; 2) accepts them?; 3) or is completely inactive? – such questions arise from the task.

Encryption function

Encryption function E in the Hidden Lake network consists of two stages:
1. Message encryption with asymmetric key authentication E',
2. Message encryption with symmetric key authentication E''.

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

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

E'(privA,pubB)(m) = (EpubB(k') || Ek'(pubA || s || h || SprivA(h) || m'))Where
h = Hmac(s)(pubA || pubB || m') – hash sum
Hmac – message authentication code based on hash function
m' – expanded message to static size
pubA – Alice's public key
pubB – Bob's public key
SprivA – signature function
priva – Alice's private key
s – cryptographic salt
k' – random session encryption key for one message
Ek' – symmetric encryption function
EpubB – asymmetric encryption function (key encapsulation mechanism)

The second stage is basic in the concept of isolating a network from other networks. It plays the role of distinguishing 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. This stage also reduces the message to a dynamic size in order to neutralize attacks on determining anonymized traffic based on the static length of messages.

E”k(m) = Ek(p(h) || h || mv)Where
h = Hmac(k)(mv) – hash sum
mv = (m || v) – concatenation of message m and random bytes v
p – proof of work function
k – network key

Cryptographic primitives used

The symmetric encryption function used the AES-256 algorithm in CFB (ciphertext feedback) encryption mode. The SHA-256 algorithm was used as a hash function, as well as HMAC based on it. RSA-OAEP was used as the asymmetric encryption function, and RSA-PSS was used as the signature function. In this case, one 4096-bit key was used for both schemes, which was quite acceptable, because OAEP and PSS schemes made it possible to separate the switch logic.

Of the primitives used above, RSA turned out to be the weakest, because its safety 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 because there are suggestions that Grover's algorithm will be able to attack the birthday paradox more effectively: not for 2n/2and for 2n/3 operations. Thus, the security of SHA-256 against brute force attacks becomes equal not to 128-bits, but to 85.(3)-bits, which is no longer reliable. The AES-256 algorithm is the most secure primitive, because even using Grover’s algorithm, the security of the scheme will decrease with 2n to 2n/2but will remain at an acceptable 128-bit level.

Transition to post-quantum algorithms

It is quite easy to secure a 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 no less than 128-bits. With the RSA algorithm, the situation is more complicated, because its security cannot be improved in the long term by simply increasing the key length. It is assumed that a quantum computer will begin to successfully crack RSA only as soon as the number of its stable qubits becomes equal to 2n+3where n is the key length. Thus, the difficulty of cracking RSA will increase linearly O(n) key length, not exponential O(2n).

  • Although I always used RSA as an example, this attack (by 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 interpretation on elliptic curves (ECDH, ECDSA, ECIES, …).

Thoughts about converting the Hidden Lake network to post-quantum cryptography have begun – funny, but per day until the final standardization of quantum-resistant cryptographic algorithms. During this time 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 code with RSA has already been written and tested, secondly, even if quantum computers are created, they will first of all crack smaller RSA keys – 1024, 2048 and 3072, thirdly, the main practical problems facing developers of quantum computers, is in the plane of successful and long-term binding of qubits. If we take it as an axiom that the development of quantum computers is carried out primarily in the open, then with the first successful hacks of RSA, we will have time to switch to quantum-resistant circuits. 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 in a predominantly hidden way, but that for an attack you only need 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 will be 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 deal with 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 this concept, the overall system actually regresses into the old classical cryptography problem of securely transmitting the encryption key. It would be possible to use other programs to transmit 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 one way or another use quantum-resistant asymmetric algorithms, then maybe we can implement them ourselves, so as not to involve additional applications?

  3. Fully switch to new post-quantum algorithms. This is a classic and, in the future, the most correct way to migrate applications to new and more secure crypto 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, currently unknown vulnerabilities may be found in them, which will completely destroy the security of the entire system. This happened with the SIKE algorithm, which was cracked by a classical computer in early August 2022.
    2) Two of the three standardized algorithms are based on lattice theory, where breaking one can lead to breaking 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, there are currently no standardized alternatives to KEM (key encapsulation mechanism) other than ML-KEM (Kyber).
    3) The volume/size of asymmetric keys, as well as encryption/signing results, increases greatly. For example, an RSA-3072 key, which provides a 128-bit security level, in its encrypted 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 takes 1632 (private ML-KEM), 800 (public ML-KEM) and 2560 (private ML-DSA), 1312 (public ML- DSA) byte respectively. The problem continues in that it is necessary to apply two algorithms at once – both encryption and signing. Because of this, the key lengths add 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 equal to 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 store 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 generally scary to compare with elliptic cryptography algorithms.

As you can see, all three options are not that 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 assume 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 (threat “Collect Now, hack Then“), then in the long term it is better, of course, 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 more “clean” with such a transfer (in the sense that the system actually becomes immune to attacks from a quantum computer due to the lack of asymmetry), but at the same time the 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 accept the large length of the key / 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) over ML-KEM-512 and ML-DSA-65 (128-bit security level) was made from a conservative point of view, as is also recommended by authors of these algorithms (1, 2). In addition to the recommendation, the 192-bit layer is really necessary for the Hidden Lake network, because… 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 in payload from 6.5KiB to 1.7KiB with a constant 8KiB message. The encryption function was designed to be session-free, so that communication between subscribers can only be maintained by directly and permanently transmitting the encapsulated session key (generated by ML-KEM) and identifiers (ML-DSA public keys) in the message itself.

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

// При RSA
type IClient interface {
	...
	EncryptMessage(asymmetric.IPubKey, []byte) ([]byte, error)
	DecryptMessage([]byte) (asymmetric.IPubKey, []byte, error)
}
// При ML-KEM, ML-DSA
type IClient interface {
	...
	EncryptMessage(asymmetric.IKEMPubKey, []byte) ([]byte, error)
	DecryptMessage([]byte) (asymmetric.IDSAPubKey, []byte, error)
}

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

# При RSA
Alice: PubKey{3082020A0282020100A5441C70EF416118C69B0E4465DEAA56050B150AFFCB780A92C70948C47236DEF0EED9B29DAB5FAD714F5D4F3A4317A11B6AEC55790C549E755A2E8BF1E56CBF8CFB4E799E04D75FE9C8CB5132F0060672A50879CEE5A007A96B1E6D8BAAA11D6BC473D1644C47208920299D7C5E9759BBA436209F1807123B2416A1A242E682AACDDD3E6E94C19298EA5DD1F5F29D0F24CFAC894101E8CEA123D9C2E1913D4B2EAFE8BC6EE569CB5CF65481B732818778F0ACCECDC74EDD8B6AA54CB6FFD50F67CFC65090A7D8DB88F3AE37DBB6A7E7ED37C7FE3BE786A33C361ACFE85C730A63C7C67D74E1A060BE6E33A504D3F978DCD0FDB162BFACD8458FB3F6144465D95F9C96F2B44A578ED397668112EE5EAF8544F047CD30B6EBD3CFEA8493698996BF22C720989B9CBB706B6A2DBC9002DAE3300A8EAC92FE9327C1B5E9613322C03F9DBA58E8BC6998810E2F15A24C2ABFA4A58F45F1913685A75C658A3A5570523642CDBB721A79D55812D9F209A33F14BB3145D30F41B8C400DAD856C592A8E8FF8133948C75B8F4081558494CEB20F90405750603D95E2117331DBCD7CDED6F58DA65FE77764D881E0C41155AA37C4E304D8B2946ADC3A896937D799ED1F49BDD655E15292C35CCCCAEB61C8A8D69AA97FC3B0FCCC131B39E184007C84CF7C1F06FF0F26216E9F353F06272C86E6F983E8A061EA7132704091546325D3324D10203010001}
# При ML-KEM, ML-DSA
Alice: [
    2f964ce591c3bb9421bc68886f28063df201f9b361378987435731c18274a889af199098c4d43e3417bea6c20f18d46f9f9c03705a394fa05f59b162fd649538a1c293ab04f610c3e3f355ec09c350838d6e473872727b1197725d4a2bea50888918586d9a140ccc526ba6379c36cb1bb26f32c87843442dce8911f33284839a0c7af1b7fa090c3ae1c061582ba9557645a33df1b6ccd2a212348b8ee3964436c866cea58b58e0196b8583d46202677a303ddc869d687576c8b26364adec19b49a476216e12319a68e7dda8bae5257ddd48b036920d7e44af99b5bc468c2432b1100a672323818e5f0b4a84a5a20111bd6b870ee81b949537efc29859aa4642e6a5b947103fa1033ace95476aa9b888113f6c059249496d4b4113ed4a64c120e3b24ca662549559b592be33106fa7fac915b1072180a259a2a49098b256af99b2f9b8a4bcf1912d0343c91b5295be2723533a139824a8af5c51d787c38690a5f0bc230a047a99911e2fa7d9e9c465ffbc6f151812c08a308837b6df1b71590b6c5b33a1066390f658d02f214afa73b67031279646443528500e2765ec05a6a9184fdc39bee649acca1029f18b18445786110c47c1264c6a1a056e315d4359f0ef89d1d3a5f839c17eb9c9f60f7234439760ab72bd6d661670866451130a7c84893d429c4950105461683f5b891a37ecd318624a178010aa6c54c5cb6f5107a6c495a25b31be16c55e2cb642a6ddac77534c3411f7c4f89f8c619d87d326628c85a5ca1567c336098f9611b8df49906524e36509aa71a8a69fc2e61503d0f786cb37162a06ac97f042ccdd0ca2c45601f220684f5114f767927806d66378d33b26f0b807131891305d53c1b5a6d9b144777db270053bbc6a94b82707d831b58489376b1c8362466121bc77fad5956198bc049c588e7a03644f8ad75f66cb7c3a449aacdf55421c61703ce286a0e980c6ff24d8f958d3fa0a88f5177e90ac938f190ead1c00307cf0578223a97b0fe64794eb55a3512a3d39b80755b4a15b7c67a3c5eb3ca171ecbbd8ef46a9eec0c593349c88655fd9844797b6c7b041188e7832d2981264b5f0bc0a073b3a2b3a48d29d0b8a850c4d1816b894b7fec1a58ccb0a86e971263651821e72ca1bc78d58a1cffc770e51cb1fe76583523255d657d3c6b9352c94b8e044eb94ca165a070ec606cc6883cefb9556662791d213b580a0dbad5ae9032048dacc4b190bf11020d0e065bc5356537405fcd39c1eb8a3867a1b71bf83aa89489f8e98122b20953743649d27c56908ed1e32038b88d0b8237ffe792cf0595f3533905fa9250ea228449023a7845c118860d9a8155136b2b8063cee015a1b23302a83e902068f60030aef8a9e457093f7901dd0547d4b69e9d07467ea1ce06e218598b20cc917b118201d993ab833757f1e8a8367b61ae18551b82708df58fb9e25e1e9a3dfc26a5e59b8a1956a21d524c5ff39ec2c10142d0441a394432c729cd12066ce87636325003c515cb89ce0383aaac42c39c335ab760661ccba871b5717d951143ccc7e9647dfc2120a69762ac1b74f4ac554d96acd47258bc64a190e48aaf816323209b793308310c6dd7fb8b2f0a28598b61303810be5e2b0c7c7ec542145fb9c30a2763ba21173b083cdca43dad20d39a501c01b6,
    912cfef38cc18d3c5b59817dcbe5da1ca954bb8f7ca5f34a099f1811e9013eb3ad1330418f456fd15208deb301c138cb854a43b05cc897d63c86234d972d81327b8fe90407026c40ffdec1e5b1ce455ec1824acb14447345e92a1fd882715ac69b580c292fa4fd1099b8425fd3c6d872876ba5cb6b58595dbbeb3ddea7b6ee23f07ec88e9014f87d3bd860e9dd723c672c2aede20b9ddf4365a63f4a16a093d3bb8830daa3162c37572ffa71e79cc02b79e4a9441cdf3625f837fefc57b2674d0f4db7031b347fa6a223d39de8900cd5e86f80c9a60930c26b7f573ac479a28b1be2278644599c93fb1469becff36bcf7f8595e3f793e22a6caaa56a59187a9602be8ab3b2bfec06114eb417d6cf2dfadc0614a0807c78ee6c52ef492a78869d51a907db2374a86e621a27ee5cbb0e6d71a86897a1b08481ee51bd38811357c9fb3dc7bc1aa8a42a283be27b3c086cd05a2694038997095f276ccbb5aea18e677e3ba17397fd9f2041dc3053e2576315273ef570191ed894609444fd5d28ebc460ec5243dd19ebe3a152281ee35291a4b9fdd40b20705d78782ee2e02a77a3840892ab1b5ca58c030a37cbc99fbe09147b108f27eb2633d1787d69611d86873217b3a18695039825b713d84f0212761ae6034b7142a3f78e89b6341a505f4adf72a894d6d7f8e2096d25c366c3e264acf0691507d8b7cc2e54c3fa615868bd4674e6e8e2508c0c4b979a1f03548cf125db2272e1a51e9a7a5a91de9a978ce4e4ba524e931021344d7808c1144d390b048a7ac573629d2c63b3a99e79afd0e6b3da617e3b455b17264fdd74deacac05307dda5968da2a033229c1459d4cf75a41b5ac57cb8df6fce26ceaef8c56461fe0aca7159390f8fd5ee950b3d947860b0e33fdf03be9e69fe9db562cb6874e1778fda9c12a963b22f70af2520f0636554d9349eb562ef1388b8e24d795434cab7fc86e9ce1994bea8e31e75c7c1fad392333b888f16bc457464cc0080d9d35244c1931abd3e50d88a63502aa8ed5098757be4c55825e5c99d9c7092126b828491a5c0096cf12e18c1725c6b4760ab9bc33e94248089531b4513ce703b44b2790628cf0d8b73b8a38ee5cb7e2bebd4760691ea9d32ed07acb5a37712eccb52e4408b0e6175e2faf42725e348d0c2ff98383a5d8a8eadcf6b88f5331a5c9776d3e7c1370b91d19df6d37076339ca6a4936bf4e507045ecae4cac0ec08fcfe9d3322d908fdfbe107976eefcda2b07151156fa3d630566905614c430c9ac71dbf0827047863b339e6529742b7033828718be748213041abfd61cd9fa1b2075493feab6289f41dc1eefb82f01987e66186566c760708eb8d3a93dc522caee0d1f22b6a0348b088b992febcb2f184fa65164fce2392a6cdfad7794e4f3ba488336c7c06a507675de859603aa998713b367f038b92a11bdde9e524b1aff289c0b3130edb9662e7a74b9f9662de065ddd51123446fe1bfdc39ed82ad76f2967015811916ce45289ac19a176d6fcc96dbb1298a5aff9012db1a7ebeccc2231431f52603f4337bf2cdbf6449bc1a3c7ba620869486b16137bb4065ba398298deffd2c59e0d4631df9ca0c34ac24a7d1af7a8d68eb19337c683e155c2515841d214de944b4acb4ec3dfef399cfb681c4ef0a47e9ffe620a89d12ef87df6e83e7d0f1459eb4046102c5f1da723b4faec9f18e90a06b00d22f67f39cc7935920e27e3c19538b16ae122da420ed60cc095bd2bde8fde39c633aebcab8762865bf12c48e655d7ae961e71ecea6ee6e01a25d5af0dfb105d7d4f21968550227abb2c3905ccf2d708e53a235e8345609e7b9ce64edd20eede936a9d735653d96ad8cdaa480bbc7699ddc2a6e14cc768b910a3b6cade369d8084a835ee75dc238c147e94a6f7076e00b7b6f1c46740883b134268199ba0397b21e7d19c36a7a01450fb0b96539be19649d60479419df46e88ae2d9f7303ad5a3eb4b4b60c6aefd71303f51f37e9d202d6bacefb38be1009d8ac55f7808e419627cc1a3815f85780b065f7181008d0c90c0f9bf544804d9534f5986ba2bc5417f7c8d30e8f59107037e013cbbb4802146daa63d17dc9bef6c108a00701f7467f59b70917ddb3e8fd52ea75eb699e79c063c3efc1158ac678201ef1d6af571cb5ed70e4783d943420609d9db32b2fb6d888d18bfccdaf994cfcfaf13e0af23beed1192ab96156b4ca275adcaeb9f0f9453aa237c98fcc676450d88857eb1918883ea0f3d3b45fbf00ead8464e5ab2281c3aaed499ea6c41713dab00b3bd6ca42a52eb06edfcf7f48a548ed7a6756e8be4b48996e1e383317366716ada742ed880f9fd88384ff51174538d945fa9e5fab65a601a599b3ed2f2631dccc2cb6341e825d3bae35d5b29e1f5debf69ddf321c978322185d191fbbb3bc4f3b2d8cc1effaa3606902cd28de7a0051e0309e539a673c66ccf709a4863c48bf65a3e2d49df9bd9f5b44eb16357e94ef24c46a7e01be36e34162dd29ceeaf5f88b8c17034fac29519565f73b4db6e6c0c97c34d659a387eed796e5096c871d35fdf71d08bd224e5f00d2697b2b342f520be1be68d4a6185f11212a72e579ac148c0b2fc6f253c531cdc7766647326b256356f2a54d62343abc7670d64d9cbcfb29c0074b3ba5d261dafd026a9101f4357ae96a8c29d4e2bce8766906bb11beb45ccec5b6d956ec29b864b6b39e155482c09506f39c3415341ff226c40a02aa7fcb6721364a28c
  ]

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

One can ask a completely logical question: is such speed needed in a network where nodes only have to generate a message every five seconds? Surprisingly, it is necessary. The positive quality of increased speed (especially decryption and signature verification) has a positive effect on the ability to timely decrypt received ciphertexts from the network, thereby allowing you to keep more users in the system when performing DoS and DDoS attacks. With RSA in place, an attacker previously needed to generate 5000(ms) / 7.5(ms) / 5(per second) ~= 133.4 ciphertexts per second so that nodes' decryption speed could not keep up with their acceptance. Now you need to generate 5000(ms) / 0.254(ms) / 5(per second) ~= 3937 ciphertexts per secondwhich, if there is a bandwidth of 100 Mbit/s, is an impossible value, because exceeds the limit of 1600 ciphertexts (8KiB each) per second. Thus, the bottleneck changes position from slow decryption to the communication bandwidth limit. To prevent the bandwidth from becoming clogged, the Hidden Lake network has a proof-of-work mechanism that increases the encryption time for 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 for me, such as: increasing the size of the keys, increasing the size of the outputs of the encryption / signing functions, changing the encryption / decryption interfaces, but I believe that this is the most correct solution. The current situation is that: either we take risks and use post-quantum cryptographic algorithms in our systems that have passed NIST standardization, already having a certain chance of being unhacked in the future, or we accept the fate of comfort and increase the likelihood of our current messages being hacked in the future to one hundred percent. This may seem paranoid, but taking into account the existing Yarovaya package and SORM-3, which stores all incoming traffic, the PRISM project, concluding an alliance between the NSA and Microsoft, Apple, Google, taking into account the obvious interests of various states in the advanced development of quantum computers – a threat ” Assemble now, hack later” becomes more than real.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *