Today, after 5 years of development, I am open sourcing The Citadel Protocol

Given the recent news of China (potentially) breaking RSA encryption and thus posing a direct threat to our communications, I decided that this project was now needed by engineers.

GitHub

Company Website

Rustdocs

Whitepaper

The Citadel Protocol is a high-performance asynchronous signal-like protocol written in rust that extends upon the ratcheting algorithm by using multi-layered ratcheting, multi-layered encryption, post-quantum key exchange, configurable true perfect forward secrecy (each packet gets a unique encryption key via re-keying) or best-effort modes, file-transfer encryption, built-in NAT traversal (no libp2p), configurable credentialed authentication (via argon-2id), device-dependent authentication, or passwordless authentication, amongst other features.

The Citadel Protocol is built on top of an underlying transport protocol. Either TCP, TLS, or QUIC may be used for transport (Default TLS for hybrid cryptography). The Citadel Protocol is used to communicate between nodes in the network.

The network topology contains a central globally-reachable node that is, by default, used for peer discovery and NAT traversal (this node can have application logic endowed unto it, but is not required). Peers connect to this central server, and, upon registration and connection, are able to then message pass amongst each other and even the central server.

Since NAT traversal is easier to perform with UDP, the QUIC protocol is used for P2P connections as this is complimentary. For Client to server connections, the server can choose to use TCP, TLS, or QUIC as an underlying protocol.

Using the Citadel SDK, rust developers can easily create hyper-secure post-quantum applications that are suitable for client-to-server and p2p applications.

I have been the only developer for the past 5 years. I am now inviting others to come and help improve and guide this project to build an ecosystem of security-aware rust engineers living in the future, for the future.

15 Likes

Yeah, that's just FUD.

Post-quantum algorithms don't have a great track record of security. Does it support well-researched classical algorithms, like ed25519?

Hyper-secure protocols for hyper-developers of hyper-quantum applications? Please.

A lot of big words here, but did the algorithm and the implementation receive a proper security audit? Subtly and overtly broken implementations abound in the field of cryptography.

8 Likes

Not true. Public sector knowledge is always years behind the true state of the art (leaks show 10-15 years behind). We won't be disclosed when we enter a post-quantum world until it is too late. People in the industry know this.

Yes, supersingular isogeny key exchange got broken. Kyber did not, however. This is why the protocol only uses Kyber.

The protocol uses a Hybrid approach, as recommended by cryptographers, to ensure the implementation is at least as secure as TLS. Getting an audit is a goal, however, this will take time and money. Considering this was just released, I wouldn't expect an audit for some time. I recommend reading into the whitepaper, grok it, then take a look at the source code to gain an understanding.

2 Likes

That's textbook FUD. No specific information, no even potential vulnerabilities and new approaches, no data on use of vulnerabilities in the wild, just vague handwaving to "secret knowledge" which is supposed to make people drop everything, and switch. From the algorithms which were tested through and through, to a barely studied new approach which can have real critical vulnerabilities.

You said you worked on it for 5 years.

If in 5 years there was no audit, and you are the only person who looked at the code, this is an indictment, not something to be proud of. It also doesn't instill much confidence that it will change later. Again, 5 years is a lot of time to deal with such issues.

11 Likes

It is clear that you are not informed on the topic matter. Let me give you a scenario that nobody argues against because it implies we are already too late to switch to post-quantum crypto:

Suppose you learn about Shor's algorithm in the 1990s. You don't have a powerful enough quantum computer then. You decide to, instead, passively listen in on public networks and capture key exchange packets and session packets that are protected with elliptical curve cryptography (like ed25519, as you suggested earlier, which is not post-quantum). Anybody that knows Wireshark can do this. You then store these packets in a long-term database. China, or, any large adversarial nation-state could especially do this. Even you or I could have done this back then (hypothetically, because I wasn't even born when Shor's paper came out). These packets may have data like social security numbers, passwords, and other confidential information. We couldn't decrypt them back then, but, we decide to hold out for some time.

Then, you finally get your hands on a powerful enough quantum computer. You take all those packets you stored in the database between the 90s and when that quantum computer came to be, and, decrypt all the data. You now have social security numbers, potentially sensitive military data, and other data that can be used for significant harm especially if you're part of an adversarial nation-state like China.

This means that irreversible damage has already been done, and there's nothing we can do about that. The longer we wait to switch to post-quantum cryptography, the more damage done.

3 Likes

Audits cost tens of thousands to hundreds of thousands of dollars. How does an individual come to do that on their own? Most people use companies for this. I decided to open this to the open-source community that way we wouldn't have to depend on closed-source companies for products that may or may not be audited. Auditing is on our terms now.

4 Likes

This post was flagged by the community and is temporarily hidden.

7 Likes

As the title suggests, the project is open source. The link is right there in the OP. The whitepaper is there too to "back up" my claims. Source code is the only thing that can back up claims at the end of the day. Are you able to parse rust code to verify my claims, or, are you making claims based on a "fantasy story" you tell yourself without investigating?

"Talk is cheap, show me the code" - Linus Torvalds

"Condemnation without investigation is the height of ignorance" - Albert Einstein

2 Likes

I read (the first half) of the whitepaper, and seen the documentation and can conclude:

  • @nologik clearly has expended a lot of effort to understand this field, and do something about it.
  • The library is written with great attention to detail and quality -- something I would be happy to use and trust.
  • I will subconsciously remember this crate / the protocol, even if I don't use it.

meta: Please try and see this from @nologik's point of view -- one who has spent substantial effort to create something of value, and giving it away. To receive burden-of-proof challenges (that one's project, freely given, has value) is discouraging. (remember actix)

Perhaps the leading narrative isn't very strong (if you are well versed in this field -- I'm not), but see the person behind the story.

30 Likes

Moderator note: A few posts have been deleted for getting off-topic.

1 Like

Thanks for your hard work and fantastic contribution to the community @nologik :slight_smile:

6 Likes

Nice work, this definitely looks cool! Thank you for open sourcing it!

1 Like