Consider Crystals Kyber and Crystals Dilithium, Upgrade to AES-256, upgrade to SHA3-512 #181
Replies: 6 comments 15 replies
-
|
Thanks for your comments and critiques. I am of course very well aware of all of the primitives that you mention. TL;DRI really don't mean this as a personal insult, but I will have to say it clearly from the start: Your recommendation makes no sense, and your understanding about cryptographic systems seem shallow at best. I hope you will follow your interest in the field, and work to deepen your understanding. I've written a more in-depth answer below that can maybe be a small help in that direction :) There are specific, and very well-considered reasons for the choice of cryptographic primitives in Reticulum, with the goal of bringing the highest degree of real-world security and functionality to the people using the stack. The composition of a cryptographic primitive suite has far wider consequences than just the Ultra-Security-Hype-Factor-Buzzword-Score™ that it can generate, but that seems to be what you are mostly interested in here. I am concerned with real security and reliability, for real-world applications. Understanding Post-Quantum-CryptographyIt seems like there is a tendency for people to read about the Crystals project and think that we now have "the solution to quantum-resistant cryptography", and that we should all move to this immediately to be safe. This is complete a misconception. The Cryptographic Suite for Algebraic Lattices, also known as "Crystals", is currently a research project, intended as a contender in a standardised suite of cryptographic primitives, that will let us continue to deploy secure cryptographic systems, in a hypothetical world, where highly efficient quantum computers have become a reality. It is not a well-audited, thouroughly proven set of cryptographic tools. The NIST PQC project has not even completed selecting candidates for standardization into a PQC suite of cryptographic primitives. If I had to place my bets, they would be that at least some of the primitives you mention will get selected as final candidates in the NIST PQC project. After that should then come years of scrutiny, review and testing by competent cryptographers and mathematicians other than the authors, before any serious use is considered. People are working seriously on these projects already, because there is a potential risk of them being necessary in the future, and because it will take a significant number of years to complete the task. Should this potential risk turn into reality, we want to be prepared, and therefore it is something we need to work on now. Does that mean that everyone should quickly jump boat to random subsets of contenders for PCQ standard primitives? No, absolutely not. Do Unicorns Haunt You?You have probably read a lot of alarmist "articles" from various "news" outlets about the impeding quantum-computer-cryptography-armageddon. Such "articles" are fantastic attention-grabbers. They are pretty far off from reality, though. As far as we currently know, it might be possible to build a quantum computer of the required complexity and speed needed to, amongst other things, efficiently break elliptic curve cryptography, and to significantly weaken symmetric ciphers like AES. There is a lot of ifs here though:
Said in another way, we think that we might, at some indeterminate point in the future, possibly possess a device that, in theory, has a hypothetical way of breaking some parts of our current cryptography systems. That is enough to get cryptographers working on potential solutions, and is the most reasonable course of action. But anything much more than that is much closer to magical thinking, than rational risk asessment. For most people, actually worrying about this is akin to being afraid that a unicorn might suddenly, and in broad daylight, materialise out of thin air, and proceed to violently mow you down with it's glittering horn, in a shower of rainbow-coloured sparkles. Literally every person working in the field of cryptographic systems are perfectly well aware of developments in both quantum computing and quantum-resistant cryptography. I can assure you that nobody will be taken by surprise here, and that if the time comes, we will all be ready, collectively. This is of course also true for Reticulum, which is designed to be completely modular in terms of primitive suites, and can have all parts changed with just a few lines of code. But implementing any of your suggestions right now would literally and directly harm the reliability, functionality, usability over low-bandwidth mediums, universality, ease of use, and not least the actual security of Reticulum. If you think you know otherwise, please outline the physical bounds for a quantum-compute capable system that can efficiently break X.25519, Ed25519, AES-128 and SHA-256 as used in Reticulum, in a time frame that is just marginally useful, let's say 100 years. |
Beta Was this translation helpful? Give feedback.
-
|
This is exactly so. Everyone should really do the math for themselves to understand it. One of the greatest problems of human civilization is its inability to intuitively understand the exponential function. |
Beta Was this translation helpful? Give feedback.
-
|
So I guess it's more about the resources used to do the brute force attack now rather than the usage coverage and standards. I agree that the encryption would go exponentially more difficult to brute force with the length. Symmetrical encryption, like AES, is a good example of that. And that's the reason why AES wth higher bit-length is still recommended by NIST for PQC today. RSA4096 is also said to be a solid standard and still able to hold with quantum computers with less than thousands of effective qubits. So there will be a very long day before an individual is capable of decrypting the network. Therefore, my opinion on this: The current encryption could still hold without any problem, especially for the individuals or the other groups without enough computing power. However, it is different when we are talking in the context of the big power in the world. This would become a gambling of the future technology advance unless the adversary scope is only limited to individuals. |
Beta Was this translation helpful? Give feedback.
-
|
Could there be an API to extend or switch the network encryption scheme? People can choose what they'd like according to their risk model. |
Beta Was this translation helpful? Give feedback.
-
The ideas that you propose here is not just "a gamble" though, they are directly hazardous to actual security and privacy of all users. Please see my comments below
I know you're proposing this with good intentions, but that would be incredibly stupid and dangerous. Please think it through for yourself, so you understand why. |
Beta Was this translation helpful? Give feedback.
-
Yeah just a thought occurred to me. Never mind. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
And just another note to @Destroyinator69420 specifically; since you seem fond enough of Kyber to recommend it for actual use in projects, you'd probably be interested in noting this: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/m/0dBVXOcSCAAJ Parts such as this one might be of specific interest to you:
|
Beta Was this translation helpful? Give feedback.
-
|
Now it's 2025 and there are 3 PQC (Post-Quantum Cryptography) NIST standards (FIPS 203, 204 and 205) along with a newly accpected algorithm (HQC) which has not got a finalised standard yet. There are some famous projects implementing PQC. OpenSSH has got the PQC implemented. (See the first point of "New features"). GnuPG is currently in a testing phase with Kyber.. NIST even has a recommended deadline for the encryption (i.e. by 2035). Even if it's still in draft stage, the public comments seem not concerned about the timeline. However, we also need to consider the constraints in this project. According to the section 2.2.2 in this document, the key pair and cipher text size is way too large compared to the classical encryption schemes. It appears unrealistic for bandwidth-constraint protocols to do anything meaningful or the performance is just unacceptable (consider spend a few hours or even days to receive and send a message or raw data like voice and image). Someone did the performance comparison for TLS connection with different cryptography algorithms and PQC is not as great as the classical ones. Additionally, those PQC schemes are just secure in terms of mathematics but need to be tested with a real hardware like a quantum computer with enough effective qubits. We still do not know how long it would come. Maybe 5 years, 10 years or 50 years. But it's really hard to tell given how long the modern binary-based computer system took from the bulky machine occupying the entire room with poorer performance than a Raspberry Pi. I personally do not know whether those selected PQC schemes are secure enough as claim by the Security Level. I can see a general trend here. Even if the hype does not necessarily imply the fact, it worth considering for the future roadmap at least. What's your thought on this @markqvist today? |
Beta Was this translation helpful? Give feedback.
-
|
First of all, please understand this: There's a very significant probability that current "post-quantum cryptography" will be broken way before an actually usable quantum computer arrives. By classical computers. By @LinuxinaBit in this discussion
My comments Exactly. For example, one of NIST PQ challenge algorithms - SIKE - have already been broken. By classical computers. And this was even one of the finalists in the challenge. Goes to show how bad an idea it is to rush in and implement any of this stuff yet. It hasn't even been a year since the first NIST spec was finalized. I definitely wouldn't be surprised to see more "surprises" as things are scrutinized properly. These things are a slow process, and in my opinion, it's not even worth looking at seriously for implementation into actual systems until at least a few years down the line. And yes, PQC keysizes are obnoxious. 10KB+ in most cases. There are ways forward in this regard for Reticulum, but it's really not worth spending time and resources on right now. As I've said before, they "quantum crypto doom" hype is, well... Very much just hype at this point.
They are not even that. We just haven't found any mathematical flaws, yet, and we've had very little time to look. In no small part due to the rushed timeline, being fuelled largely by a lot of hype and uninformed media attention.
And as I've said many times before, it has been. It's basically ready to be dropped in whenever it's actually necessary. To expand further Reticulum uses no esoteric cryptography, like certain other projects that makes lofty (and unrealistic) claims about "post-quantum security", "military grade encryption", "complete anonymity" etc., etc. I am not going there. It is disgraceful and untrustworthy, and especially so in regards to "post-quantum security". That does not curretly exist. We are at no point where anyone can claim that, without it being marketing BS. Reticulum uses solid, sensible and well-proven cryptographic principles and primitives. There is very little doubt that these, at least to our current understanding, are solid; now and in the foreseeable future. The way Reticulum uses these primitives, are also in line with standard practices. But since the complete system design of Reticulum as a whole is a very novel application of well-tried cryptography, there are risks that unforeseen implementation-specific issues could have occurred. I have spent years trawling through the implementation and design, again and again in search of these. Have I found issues? Yes. And they have been fixed. Are there any left? My confidence at this point is very high, that Reticulum is solid. Would that confidence remain if I implemented any sort of "post-quantum cryptography" at this point in time. Absolutely not. To expand even further The artificial hype around quantum computers is insane. Companies operating in the field are quick to shout about advances in how many qubits they can now achieve on their (highly experimental) substrates. They forget to mention that those are physical qubits, that de-cohere as soon as someone farts ten miles away. They are completely useless for doing real quantum computations. Then a bunch of researchers comes along and demonstrates, that in a perfect world, that omits a lot of necessary considerations and in theory, a functional topological qubit can be constructed. Massive hype ensues, leaving out all of the essential nuances and details. Yes, warp-drives are also possible, in theory. Most people don't even know there's a huge difference between the physical qubits companies are actually making, and what is being presented as a qubit (with the capabilities that entails).
There's so many factors we don't have the foggiest ideas on yet. We don't even know the real bounds of the problem. The space is massively contaminated by media hype and misunderstandings. If you don't actually try to get into the real matter of the subject, it's a bit like worrying that your neighbors are going to end civilization in 5 years, by building a warp-drive in their garage, and using it to divert an asteroid into earth. Sure, it's a viable theoretical scenario. But the real-world, actual requirements for doing so are nothing short of exotic. Bonus question: Why doesn't Reticulum use the AES GCM? Might as well get this one out of the way at the same time. Four year old question, but while there are some good answers already, I'll throw another few points into the discussion: GCM has an effective length limit for any given key + nonce pair, after which its security degrades drastically. From Wikipedia:
Thus, if you're going to use GCM for large data blobs or long-running or high-traffic connections, you need to have provisions to re-initialize before this limit is hit, on both encryption and decryption. That complicates your message format or introduces an artificial length limit. In fact, even if you don't expect to run into this issue, you need to have a check in place; code that today never handles more than 4GB at a time might in future handle 100GB messages and break your security assumptions. GCM is more fragile against bit-flipping attacks. If for some reason you don't verify the message integrity (e.g. because you tried to decrypt only part of the message, or because you are using OpenSSL and forgot to supply the authentication tag so the API just acted like normal CTR mode), an attacker can have flipped arbitrary bits in the ciphertext with the effect of precisely flipping those bits - and only those bits - in the plaintext. With CBC, flipping one or more bits in ciphertext block N will flip exactly those bits in plaintext block N+1 (and nothing else in N+1 or any subsequent block), but it will also completely scramble the plaintext of block N. Thus, bit-flipping attacks in CBC require tolerating corrupting the block proceeding the target block, or that the target block is the first block (in which case you flip the bit(s) in the IV, which works fine). This isn't a huge difference - in either case, you really need to check the message integrity, and of course GCM does that for you (if used correctly) while CBC requires having some other method (such as an HMAC) - but I have actually seen code that was "using GCM" (with OpenSSL and under the mistaken assumption that the OpenSSL API isn't an entire battleship worth of foot-cannons) but vulnerable to catastrophic bit-flipping attacks where CBC wouldn't have been at such risk (the data being tampered was JSON and the corrupted blocks would likely have been invalid to the JSON parser, preventing use of the tampered data). GCM reveals exactly the length of the plaintext, unless you add padding prior to encryption. This is because block ciphers in counter-based modes act like stream ciphers, where the ciphertext (not counting IVs, MACs, or similar) is exactly the same length as the plaintext. CBC only adds a small amount of length masking - any message will be padded out to a multiple of the block size, which is 16 bytes for AES - but sometimes that little bit matters (though if you think that's a likely risk for you, you should pad your data to a constant length no matter what cipher you use). Of course, that padding is a risk factor too. Used in certain scenarios, CBC runs the risk of padding oracle attacks, such as the catastrophic POODLE attack that was the death knell for SSLv3. Unlike CBC padding validation, there's no way to use GCM authentication tag validation to determine the message contents without knowledge of the key. To be fair, there are many ways to protect against padding oracle attacks and they are only a risk at all if there is something that can act as an oracle for arbitrary modified copies of a message, but the high risk of them in CBC is one reason not to use it. Of course, that's not so much a reason to use GCM in particular; there are many cipher+mode combinations that don't have this problem. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your very detailed answer. This really gives the good explanations about the PQC and valid concerns. Anyway, it's quite hard to see what could be going on in future. I guess Reticulum now might not raise as much attention as I2P, there is still time to observe and test a final good one that meets the real world scenario and the balance between security and bandwidth. And the development of Quantum computer is still a big unknown nowadays. And yes, nobody actually knows whether the statements about the classical and PQ cryptography hold as the computer is not at that stage yet and the quantum algorithms are way to immature compared to the classical ones. Let's hope all the best. The post you write here can be a blog post or in a big Q&A section. Appreciate the effort and thanks for the project! |
Beta Was this translation helpful? Give feedback.
-
|
I was looking for information about post-quantum encryption support in Reticulum or plans for its implementation and found this thread. Very interesting discussion! Personally, I think that implementing quantum-resistant encryption and hashing according to the new accepted standards could increase resistance to “harvest now, decrypt later” attacks (since they cannot be ruled out at the moment) and would also attract people who are interested in long-term and secure storage of their messages. This would be an impressive and significant advantage for the Reticulum network. |
Beta Was this translation helpful? Give feedback.
-
|
Odds seem relatively high that a given PQC algorithm will be broken before 'harvest now, decrypt later' becomes a problem for what Reticulum uses... |
Beta Was this translation helpful? Give feedback.
-
|
Layers of encryption are your bestest friendo.
…On Mon, Oct 20, 2025, 4:17 PM Linux in a Bit ***@***.***> wrote:
Odds seem pretty high your chosen PQC algorithm will be broken before
'harvest now, decrypt later' becomes a problem for what Reticulum uses ;)
—
Reply to this email directly, view it on GitHub
<#181 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALE3POBFI6ATKUKUSVGBKM33YU7PPAVCNFSM6AAAAAB45S3OQCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINZTGM2DKOI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
True, but only as long as bandwidth isn't a concern ;) |
Beta Was this translation helpful? Give feedback.
-
|
Yes, if it weren't for the scary size of PQC signatures, it would be possible to use mixed solutions such as X25519 + ML-KEM-768 (already implemented in OpenSSL starting with 3.5.0). However, it is not necessary to use this on all interfaces and users simultaneously and forcibly. Specific peers and nodes could be given the choice of whether they want to use PQC, and if both parties agree, then it could be used. And, for example, restrict PQC to be used only in TCP connections, but not over LoRa. A similar implementation exists in I2P. In I2Pd, starting with version 2.58.0, you can choose KEM X25519 or X25519+ML-KEM; for signatures, you can choose ML-DSA. Original I2P Java router has implemented "Hybrid PQ MLKEM Ratchet Beta" in 2.10.0 version and will continue to implement in 2.11.0+ |
Beta Was this translation helpful? Give feedback.
-
|
You could certainly put PQC stuff inside of Reticulum packets, but at the Reticulum level the entire network has to use the same cryptographic primitives for Reticulum to work properly. Also, this should go without saying but you can't control or even know what kinds of connections your packets are traveling over past the first hop. |
Beta Was this translation helpful? Give feedback.
-
|
If we encrypt the transmission, then yes, it is important that the entire network supports the same standard. But if we encrypt the data packet using E2EE (PQC or not), then it doesn't matter how it is transmitted. The main thing is that we and the end user support the same standards and have agreed to use them. And then P2P transmission between two peers or through a bunch of hops is essentially the same. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
You are not using the strongest version of the encryption algorithms available. For instance, you are using AES-128, which can be weakened using a quantum computer. The simplest method to combat this would be to use AES-256. You are using SHA-256, although I do not know whether you are using SHA2 or SHA3. If you are using SHA2, then you should be using SHA3, which is more recent and widely regarded as more secure. SHA3 supports an option for a 512 bit hash, this is widely regarded as more secure than SHA256 in regards to collision attacks. I would also recommend integrating Crystals Kyber into the asymmetrical cryptography, as doing so will make your network quantum resistant, but the Crystals developers recommend using Crystals Kyber with an already established algorithm. Irregardless of whether you encrypt with Elliptic Curve Diffie Helman or Crystals Kyber first is of no consequence so long as the keys used to encrypt them are generated separately. You should also consider using Crystals Dilithium as a hashing algorithm in addition to SHA3-512. This will provide two layers of security in terms of message authentication. I would recommend Dilithium5, although there is a faster version that uses AES in counter mode instead of shake to expand the polynomials, it is called dilithium5-AES. It uses AES to take advantage of hardware accelerated AES when possible, although I would stick with Dilithium5 becuase SHAKE is an irreversible function, unlike AES. There is an open source library called liboqs created by the Open Quantum Safe project. It has a python wrapper and is written in C. All of the algorithms I have mentioned in this issue ticket are available in OpenSSL if not in liboqs.
Other than my crituqe of your cryptography choices I would like to congratulate you for fighting the good fight and proving that a more decentralized and secure internet is possible. I would also like to congratulate you on not selling out to the Web3 craze. Hopefully reticulum gets the attention it deserves.
Beta Was this translation helpful? Give feedback.
All reactions