System Design Premises

Don’t let its blandly designed client app interface mislead you into thinking that Citium is an underdeveloped software. In fact, it is so powerful that it guarantees the communications with your intended contacts are quantum-resistant and plausibly deniable. It is well-known that innovative system design often introduces new forms of failure. And yet, despite that, most system designers embrace innovation because it is human nature to resolve recurring annoyances. Sadly, more often than not, the well-meaning changes in secure communication systems create unexpected failures, such as security vulnerabilities. The higher the complexity, the more error-prone they are. Therefore, the design philosophy of Citium is, foremost, to reduce system complexity. When the use of some complex encryption algorithms is irreducible, we compartmentalize them into modular components. Given that modular designs become susceptible to failure when issues arise that bridge the divisions, Citium makes sure those failures are nothing but acceptable cost at the expense of speed. It might all sound too abstract so let us put these in more concrete terms and examples.

Easy way to understand Citium 

Encryptions and transmission mechanisms of BitTorrent and Bitcoin protocols are time-tested decentralized P2P technology. The BitTorrent protocol has been around for two decades with billions of users worldwide. The Bitcoin protocol has demonstrated its reliability in the high-stakes financial environment. Citium rides on the back of them to realize quantum-resistant confidentiality, user anonymity and deniability. Imagine “messages in bottles” scenario. Instead of putting pieces of papers into bottles, we put individual jigsaw puzzles in them. The message that you want to send to your intended recipient is analogous to the custom photo of a jigsaw puzzle. First, the message is encrypted by your own device and is cryptographically split into small slices. It is like die-cutting the photo into jigsaw puzzles then bottling them individually. Then, they are randomly casted to the nodes in the Citium network, the BitTorrent network and the Bitcoin network. They are located all over the world in different countries. It is like casting the bottles into the seven seas.

Dynamic Data

Note that the dynamic transmission of data to the Citium network along with those that piggyback on BitTorrent and Bitcoin networks resembles the tens of millions of fake seeding and dusting attacks that happen every moment on the Internet. In other words, the data transmission is harmless and is hiding perfectly in the plainsight of mundane Internet traffic. Most of the BitTorrent and Bitcoin nodes neither examine nor block data casting from individual Citium nodes because they are too small in size and low in frequency to be obtrusive. Usually, they just stack the newly arrived data into their own buffers and/or pass them onto someone else. That’s why Citium can circumvent all kinds of Internet censorship and users can communicate freely on Citium.

Static Data

Moreover, the static data–all the ciphertext slices–that are sitting on the decentralized network of Citium, BitTorrent client and Bitcoin network nodes look similar, just like you can hardly tell apart one floating bottle from another in the seas. Everyone can bottle a jigsaw puzzle and cast it into the seas and everyone is allowed to pick it up. Yours, too, can be picked up by anyone! However, no one, except your intended recipient, has any clue of which bottles contain the essential puzzles, not to mention how to piece them back to the original message even if they somehow manage to recover every essential slice. Yet all the while, you and the intended recipient can communicate smoothly in Citium because only your intended recipient knows which are the essential slices (bottles) to retain, has the required keys to decrypt (unlock) them and to piece the ciphertexts (jigsaw puzzles) back together into the original message (photo). In addition, you ripe the full benefit of plausible deniability no matter how things turn out, even your intended recipient decides to turn on you. Thanks to the inherent design of Citium, your intended recipients cannot hold you accountable to whatever you have said to him/her because it is technically impossible to prove irrefutably that the messages were ever casted by you.

InfoSec Design Premises

All popular and even seemingly innovative encryption algorithms and features (e.g. AES, forward secrecy) in the hope of preventing man-in-the-middle (MITM) and cryptanalysis is elusive if not futile because any belief in anti-MITM technology is unfalsifiable, not to mention that none of them can withstand attacks by quantum computers and/or coercions. We can only wish those who have faith in anti-MITM technologies good luck while we take the design premises of Citium to extremes because traditional data security assumptions have not served well especially to those who communicate sensitive information online and are overpowered by adversaries (i.e. threat actors) in terms of resources and determinations. One cannot fathom the extent of MITM that some resourceful and patient threat actors will go until it is too late. One can never know when state level intelligence agencies start using quantum computers to decrypt archived transmission data, so whatever you feel secure today is no guarantee of not getting back at you by more powerful cryptanalysis technology tomorrow. Last but not the least, unless your body is as nimble as Ethan Hunt in Mission: Impossible, unless your mind is as ingenious as Keyser Söze in The Usual Suspects, or unless you are always ready to bite and ingest Hydrogen Cyanide (HCN), at the point of being coerced to divulge your secrets, you are doomed. On the other hand, if you have used Citium to communicate private and confidential information, technically feasible/plausible deniability will defend you from being a sitting duck.

Inevitable Eavesdropping, Surveillance & Coercion

Can Citium free users from eavesdropping and surveillance? No, because eavesdropping and surveillance are everywhere. For instance, in 2013, whistleblower Edward Snowden revealed the US NSA PRISM surveillance program to the world. We cannot face the reality without learning a lesson from it that everyone is subject to eavesdropping, surveillance and even coercion. What Citium does, paradoxically, is to offer deniability so that eavesdropping and surveillance is rendered meaningless because no one knows for sure who sent what from which devices in the vast ocean of “bottles of messages’’ hidden in the plain sights of the Citium network of nodes. In other words, Citium utilizes a blend of deniable encryption schemes so that eavesdropping and surveillance become innocuous if not entirely inconsequential. In most circumstances, coercion is tantamount to total defeat. Your attempts to protect the confidentiality of your communications have been in vain. The purpose of deniability is not at all to “convince” the coercer that any surrendered transcript is real; indeed, it is common knowledge that transcript can easily be faked. Instead, the goal is to preempt coercion in the first place by making surrendered transcripts useless. Citium users simply have to “stick to their stories”. No data analyst or forensic expert can irrefutably prove who is involved in which message in Citium. The use of Citium has enabled a major paradigm shift to deniable encryption schemes as the last defense of confidentiality. Simply put, as long as you communicate through Citium, you are free to deny every evidence against you. It is not your duty to prove that you are innocent. It is someone else’s duty to prove that you have done something wrong that leads to your charges. But rest assured that no one is capable of doing so.

Unrealiable Centralized Regime

As we all know, it is fallacious thinking to appeal to centralized authority and novelty. But unfortunately, this knowledge cannot prevent seemingly trustworthy centralized governing bodies and self-proclaimed experts from peddling ever fancier InfoSec technologies to their users. A laundry list of disappointments has been blindsiding these users, such as

In view of these repeated incidents, Citium proposes three (3) pessimistic yet stringent InfoSec design premises.

  • Trust No One - Participant is fallible.
  • Power Corrupts - Rights are exploitable.
  • No Secrecy - Cipher is vulnerable.

In face of an intruder successfully uncovering private data in Citium through

1. inciting defection2. power abuse; or 3. ciphertext hack, Citium users can still justifiably deny that they have ever been involved because all security forensics are futile, no matter how extensive and meticulous they are. Citium inevitably makes the data source obscured and inadmissible. Besides, Deniability, as an InfoSec feature, greatly reduces the desire of any competitor or judicial authority to investigate or obtain evidence against users of Citium.

Availability

Can someone use an unimaginably large amount of resources to attack Citium so that it fails? No, because Citium client app messaging is always available even if all the other Citium nodes have been taken down because dynamic transmission of Citium data piggybacks on BitTorrent and Bitcoin networks. Yes, you heard correctly. Not only that Citium has no central servers, which essentially renders raiding, shut down, or forces to turn over data impossible, but also that its data transmission relies on someone else’s P2P network infrastructures. Thus, say goodbye to the server and node outages! A threat actor needs to physically seize ALL devices, such as phones, routers and content servers in ALL countries, where the Citium nodes are situated, to hamper the performance of the Citium network in transferring large files, such as image, voice and video. Not to mention that the takedown is not only highly improbable but a glaring act bound to draw attention. It is just too Pyrrhic for most of the threat actors to contemplate. In contrast, law enforcement who is targeting popularized secure chat service, such as EncroChat, would only require a one-time, yet discreet, takedown of their centralized messaging relay or contact directory servers. Most users may unknowingly continue to use the service while their IDs and data have already been covertly compromised. Luckily, Citium users never have to worry about this kind of mishaps. The number of connected device nodes in the Citium network are only growing day by day because every online Citium client app is an active node that serves itself as well as everyone else in the decentralized network. Therefore, crippling or compromising the Citium decentralized network is only getting geometrically harder and harder as time passes while centralized service providers, such as SkyECC, inevitably heighten their data breaching risk as they gain in popularity. Technically, in the infoSec sense, the decentralized network of Citium nodes is a layered defense on top of the PGP-encryption scheme, making Citium communications deniable and quantum-safe. This is a unique service unavailable by any other provider.

InfoSec Highlights

Conventionally, compromising with usability, centralized stakeholders of a cryptosystem hold users’ account ID, password, and personal information to authorize access and service, which may all lead to irreparable blowback, such as data breaches, coercion and blackmail attacks. Luckily, modern cryptography technologies enable designers to create better cryptosystem: do away with these rights and power while still retaining the overall usability of cryptosystems!

Citium take full advantage of these time-tested proven technologies to establish a free, open-source, fully decentralized, permissionless blockchain that features cryptanalytically unbreakable cryptosystems and InfoSec mechanisms, such as Hybrid Cryptosystemthreshold cryptosystemindiscriminate mesh-tree multicast (IMTM), and sockpuppetry. Citium’s current build is capable of serving textimagevideo and real-time voice data. Decentralized Apps (dApps) built on Citium can enjoy extraordinary data security features, such as deniability, which is well-suited to build Off-the-Record Messaging (OTR) Instant Messenger System.

Server IP Obfuscation: Server IP Obfuscation (SIPO) is a unique feature of Citium. It can hide a server’s originating IP address from its visitors while letting them visit HTML5-based content on the server seamlessly. Not only can SIPO effectively prevent distributed denial-of-service (DDoS) attacks, but it can also curtail IP intelligence gathering (e.g. geolocation lookup), effectively preventing web server takedown and seizure.

Security Tradeoff

Why do I observe occasional delay sending and receiving message(s) thru Citium? The short answer is that the occasional delay is the price we pay for the extra peace of mind in security. The extent of a delay highly depends on the size of a message. If it is a text message, which is small in size, the delay will normally be resolved in a few seconds. But if it is a picture, voice clip or video, which is large in size, the delay will be slightly longer but not longer than a couple of minutes. While you are waiting, Citium is busy encrypting your message with a triple layer of encryption, namely ECDSA, BLOWFISH, and XXTEA. Notably, ECDSA is the encryption scheme used by the Bitcoin network, which has stood the test of time. As the market capitalization of Bitcoin is already in the hundreds of billions of dollars, cracking even a fraction of it means jackpot or attestation to a hacker’s ability. In spite of the incentives, no one has been able to crack it. The only reason why ECDSA has not been adapted more widely is due to its hunger for computational power. Mobile devices need time to process the encryption which contributes to the occasional delay. Furthering the delay is the casting of sliced ciphertexts to the P2P networks (i.e. Citium, BitTorrent, Bitcoin) because the ETA in decentralized systems is not as predictable as those in centralized ones. Not to mention, all the while the recipient end is busy fetching these tiny encrypted pieces of message, then decrypting and reassembling them back to the original, readable format. The transmission process is slower than most of the other instant messengers but it is the necessary performance and security tradeoff for Citium users who value confidentiality above all. Technically, the slicing of messages is a concept in threshold cryptography which makes Ctium post-quantum resistant. In plain English it means that even threat actors who come back from the future, armed with quantum strength deciphers, cannot reveal the original text.

Differs from FREE App

Free apps, such as Signal, Telegram, WhatsApp, Facebook Messenger and WeChat, obtain and make use of at least one personal identifier(s), such as through email, SMS or phone, to keep track of you. They can lead back to your real identity. Privacy policies of these companies dictate that their user information is insecure. To make matters worse, their centralized-managed business models make them vulnerable to coercions. It means that they are more than ready to give away your information for their own sake as they have the right to release user information to third parties without user permission. On the other hand, paid apps, such as SkyECC, assign user ID to you so anyone with your ID could potentially locate you and knock on your door. Citium guarantees your privacy by absolutely NOT ASKING for anything about you from the process of payment, installation and to customer service. Our customer service agents do not know about your existence unless you reach out to us. A private e-cert will weld to your phone instead of user ID and password. It will free you from username and password combination leaks, ID theft, phishing, malicious random ping of messages and trash ads. We have no central server so any DDoS attack or attempt to data kidnapping is, by design, impossible. You are the only one who controls when, how and with whom you are chatting.

Sockpuppeting Accounts

Apart from privacy issues, from the encryption algorithm point of view, all these free apps issue the public keys that their users use to encrypt the messages so that the companies know who the users are simply by knowing who’s using which public key. In contrast, each Citium user issues his/her own public key. In fact, every one of your Citium Contacts are communicating with you through some proxy accounts which Citium created for your Contacts individually during out-of-band verifications. Your Contacts do not know if the accounts are only for them or they’re for someone else as well. This scheme essentially disallows your Contacts from turning against you in the future because they cannot prove irrefutably that they are talking to you. Everyone talks through “sockpuppeting accounts” which no one knows for sure who’s talking through them so that everyone in Citium can maintain plausible deniability at all times.

Deniability 

Many centralized communication systems claim to have non-repudiability as one of their FnfoSec features because their users purposely want to systematically hold their communicating parties legally accountable. Citium does not cater to that purpose. In fact, Citium offers the complete opposite: deniability, which is the last line of defense against forced disclosure and its repercussions.

Some service providers, such as Facebook, are trying to offer deniability but they fail to rule themselves out of the picture. Here a direct quote from the Technical Whitepaper of Messenger Secret Conversations in Facebook Messenger published on May 18, 2017:

“[T]he third-party deniability property ensures that no party outside of Facebook can cryptographically determine the validity of a report.”

It implies that Facebook can still be vulnerable to forced disclosure and or even voluntarily submitting to surveillance, not to mention the chance of data breach. Thus, Secret Conversations of Facebook’s Messenger offers half-baked deniability at best. In contrast, Citium offers full deniability; no participant or mediatory machine can compromise deniability in any way.

The primary motivation behind Citium decentralized system protocol is to provide a deniable communication network for the conversation participants while keeping conversations confidential, like a private conversation in real life, or off the record in journalism sourcing. This is in contrast with some other centralized communication systems that produce output which can be later used as a verifiable record of the communication event and the identities of the participants.

SafeMail & SDTP

Citium is inherited from the open-source projects: Bitmessage and SafeMail. Although the Citium Instant Messenger project is fully compatible with SafeMail protocol, we decide to call it Citium Instant Messenger (CIM)  instead of Citium Mail because it is in many ways (e.g. the user interface and operation) more akin to most of the popular instant messengers in the marketplace.

The communication mechanism used by both CIM and SafeMail is the “Safe Data Transfer Protocol” (Safe Data Transfer Protocol). SDTP dictates that all forms of communication push the same generic notification to the intended recipients. Once notified, the intended recipients are required to retrieve the messages on their own.

Push & Pull(Fitch)

Most instant messenger systems are designed that messages are directly pushed onto the client apps of the intended recipients. However, in Citium Instant Messenger (CIM) system, push notification is limited to a generic text reminder (i.e. “You have a new message.”) and a very thin slice of the message encrypted in a ciphertext being sent to the intended recipients. The intended recipients are required to actively fetch the remaining slices on their own from the sea of Citium nodes  (i.e. service & user nodes), and eventually, recombining with the thin slice at hand to acquire the original, correct message.

Threshold Cryptography

In any cryptographic system, the most important component of transforming plaintext messages to ciphertext and back is the key. The key is the foundation of the overall security of cryptography, which means that the protection of the key has also become an important issue. One of the methods that can reduce the risk of the key being compromised is threshold cryptography. The basic idea of threshold cryptography is that the key is divided into n shares before being distributed to the involved entities. In order to generate the key again, not all the shares are needed. Instead, an entity can combine only k shares (known as the threshold value) to reconstruct the key. In other words, even though the key is divided into n shares, only k out of shares is needed to reconstruct the key.

As Extra Security

Historically, only organizations with very valuable secrets, such as certificate authorities, the military, and governments made use of threshold cryptosystem technology. Threshold cryptography scheme in Citium is an advanced and extra step to securing the key and to preventing the key from being compromised. This is because an adversary will need to attack k node(s)  in order to obtain k shares to generate the key, rather than compromising one node  to obtain the key. This makes it more difficult for an attacker.

In Citium, not only the key, but also the ciphertext (i.e. encrypted message) itself are divided into n slices along with the n shares of the key. The shared ciphertexts are distributed indiscriminately to as many Citium nodes (i.e. service & user nodes). In doing so, all contents are benign to the owner of all nodes. No one is needed to be held responsible for any message distributed. No one knows what/whence/to whom they are distributing on their nodes. In the Citium’s threshold cryptosystem, it is designed that k = n. It means all n shares have to be collected and combined. It is the most stringent InfoSec setting on the threshold cryptosystem.

InfoSec Summary

Here is a list of available InfoSec features on Citium. Information security, sometimes shortened to InfoSec, is the practice of protecting information by mitigating information risks. It is part of information risk management. It typically involves preventing or at least reducing the probability of unauthorized/inappropriate access, use, disclosure, disruption, deletion/destruction, corruption, modification, inspection, recording or devaluation, although it may also involve reducing the adverse impacts of incidents (e.g. force disclosure / mandatory key disclosure).


Risk & Threat

Censorship

Data Breach

Tampering

DDoS Attack

Privilege Escalation

Spoofing

Forced Disclosure

Repudiation

InfoSec

Permissionless

Confidentiality

Integrity

Availability

Authorization

Authentication

Deniability

Non-Repudiation

✓ available feature; ✗ unavailable feature

Deniability and Non-Repudiation

In general, cryptographically signed messages provide non-repudiation; i.e. the sender cannot deny having sent the message after it has been received. Citium uses public-key authenticators instead, which guarantee deniability. Any recipient can forge a message that will look just like it was actually generated by the purported sender, so the recipient cannot convince a third party that the message was really generated by the sender and not forged by the recipient. However, the recipient is still protected against forgeries by third parties. The reason is that in order to perform such a forgery, the private key of the recipient is needed. Since the recipient himself will know whether or not he has used his own private key for such a forgery, he can be sure that no third party could have forged the message.

Non-repudiation is a legal concept that is widely used in information security. It refers to any service, which gives a recipient a very strong reason to believe that the message was created by a known sender (authentication) and that the message was not altered in transit (integrity). In other words, non-repudiation makes it very difficult to successfully deny who/where a message came from as well as the authenticity of that message. Note, Citium is not built for this.

Practicality

In practice, deniable communication has been sought by users whose legitimate activities may not always be protected from subpoenas or legal coercion, e.g., journalists and whistleblowers, or lawyers and activists in repressive regimes. Citium allows for denying the existence of messages on any storage medium, and for equivocating those messages.

When two parties want to communicate on a system with deniability as one of the main infosec features, the sender of a message want to plausibly deny that he or she has sent that message, i.e., sender-deniable scheme; the intended recipient of a message wants to plausibly deny that he or she has received that message, i.e., receiver-deniable scheme.

Preempt Coercion

The purpose of deniability is not at all to “convince” the coercer that any surrendered transcript is real; indeed, it is common knowledge that transcript can easily be faked. Instead, the goal is to preempt coercion in the first place by making it useless. Parties who “stick to their stories” explaining to the coercer how Citium works can never be pinned down to the real message.

Deniability in Citium is achieved through three InfoSec mechanisms:

  • Permissionless
  • Deniable Authentication
  • Sockpuppetry

Permissionless 

The main benefit of Citium being a free, open-source, fully decentralized, permissionless blockchain is censorship-resistance. No one can be banned from running nodes. Operators of nodes (e.g. OTS Instant Messenger System Provider (IMSP)) may advertise their own material (e.g. commercial content) to the users who access Citium through their nodes. A sender is free to choose which IMSP’s service node to help relay his/her message to the intended recipient. Any two users (e.g. Alice & Bob) who decide to communicate securely and deniably may hop on any service nodes of Citium at any time without the need to ask for anyone else’s permission. But of course, service nodes are entitled not to serve or not to relay from questionably abusive nodes. It all depends on the self-determination of each participant. No matter from which network communication layer that one looks at Citium, all data look similar. No third party, especially machine intelligence, can tell if data has been forged or tampered with because everyone can forge or tamper with everyone else’s data. In principle, all data are assumed unknown origin (forged) and untrustworthy (tampered) until proven otherwise.

Since Citium adopts a network-wide peer-to-peer (P2P) relationship model, there is no higher or lower privilege to access service. Every node is equal in rights and responsibilities. Thus, infosec exploits, such as horizontal privilege escalation and vertical privilege escalation, are impossible to exist in Citium.

Citium’s Worldview: In order to discourage malicious parties from snooping data or holding data as evidence against others, Citium believes that the best security practice is to openly permit everyone to forge and tamper with data so that no party can possibly differentiate genuine from forged or tampered data.

Deniable Authentication

Citium uses deniable authentication mechanism. When two users (e.g. Alice and Bob) decide to communicate through Citium with each other, they have to become each other’s authenticated users (“Contacts”) in Citium from the outset — i.e. performing an out-of-band key authentication/verification, which eliminates all future possibility of man-in-the-middle attack (MITM) on Citium. This is the only moment in the authentication lifecycle that the two users know for sure that the communicating counterparty (Alice or Bob) is whom they believe to be. But after that, as ironic as it may sound, no one, not even the two users themselves, can irrefutably prove their authenticated Contact relationship even during the course of their communication.

Despite what has just been said, the traditional sense of user authentication (i.e. irrefutably identifying a user) is still preserved because authentication in the Citium universe is no longer bounded by user account alone but by every cryptographically signed message. Any two communicating parties (i.e. the Contacts: Alice & Bob) who communicate with each other must perform out-of-band key authentication/verification (OOBA) from the outset. Once verified, messages sent between Alice and Bob cannot be spoofed by any third party. Although the permissionless nature of Citium dictates that no conventional measure (e.g., anti-spam techniques) is in place to prevent spoofing attack and phishing, perhaps counterintuitively to many, Citium is a pristine environment (i.e. spoof-free & spam-free) from the perspectives of Alice and Bob. Bob always can correctly identify the cryptographically bounded message sent from Alice whom he has authenticated from the outset in spite of many other users pretending to be Alice, and Alice can always be certain that only the one true Bob can correctly decrypt the messages she sends in spite of many other users pretending to be Bob trying to decrypt the message.

Out-of-Band Key Verification

In order for Alice and Bob to become Contacts, one has to initiate an out-of-band key authentication/verification (OOBA). Suppose Alice is the Contacts Initiator. Alice initiates an OOBA with Bob by sending Bob a Friend Invitation Code (FIC), which is a plaintext that looks like this:

{"MSG":"Hi, I'm Alice. This is a Friend Invitation Code (FIC). it is valid for 24 hours. ","APPNAME":"SEMAIL","NICKNAME":"e99bbbe885a6e6b8ace8a9a6","TID":"322","HOST":"68747470733a2f2f7777772e70616e676f3132332e6f7267","MAJOR":"03c86ebf41b02f379823173aafd7bd873efb9b59e06375dac7793342db8b3d9ee7","MINOR":"02307396c7f6ac576544991285b016283fbe2e08f5013f41cf984734ed2bfc814e","SIGNATURE":"304402204ddf9ae16a14dfc70c94c83eb6735419e4e8eb2019853c54336c9af84d425c480220394b6181eccb2df743f78f848f6f2ba9f153e6d5b2a3322e646f4f320666c85531"}

MSG is a friendly readable text for anyone who sees this message to know what it is about. APPNAME is “SEMAIL” by default. It signals compatibility with other services that use Safe Data Transfer Protocol (SDTP). NICKNAME is the ciphertext of the nickname that Alice wants to be known by whoever adds her through this FIC. TID is Alice’s corresponding identifier issued by her service node. HOST is the cyphertext of the host or IP address of Alice’s service node. MAJOR and MINOR are the two public keys. MAJOR the service node to authenticate Alice, and MINOR is used to authorize others to post her messages. SIGNATURE is the digital signature for all the above information to ensure their integrity.

Deniability

In the Citium Contacts mechanism, Alice can send the FIC not only to Bob but also to other people, such as Charlie and Chuck. Only Alice herself knows for sure if it is Bob being the only one who has received the FIC or not. In other words, Alice could have publicly displayed the FIC, so that anyone could have it and post messages to Alice.


Contacts Initiator

Contacts Invitee
Alice
Bob
Alice
Charlie
Alice
Chuck
Alice
a random person D

Alice
a random person E

Alice
a random person F

Alice

Alice

Alice

As you can see, no one could prove irrefutably that which of her Contacts was someone that she has known personally instead of some random person trying to post messages to her. Therefore, Alice can plausibly deny her relationship with any message.

To enhance user experience and simplicity, the default Friend Invitation Code (FIC) authentication has a detection mechanism. As long as a friend accepts the out-of-band verification, the FIC is invalidated. You may see a system message popped up in Citium Instant Messenger saying “Awaiting authorization from the communicating party”. This message indicates that two attempts to authenticate were unsuccessful. If Bob sees this, there are two possibilities: 1. Charlie, Chuck or some random person has used the FIC; 2. There is a problem with the network. However, since CIM  is open-source, anyone can modify this one-to-one authentication restriction of FIC. Deniability still holds.

Sockpuppetry

Sockpuppet is a software measures of countersurveillance. In Citium, sockpuppetry dictates that anyone can pretend to be someone else. The user account nickname is non-exclusive! No user knows for sure which account belongs to whom no matter from which perspective one looks. Sockpuppetry dictates that a user cannot communicate directly to another user but only indirectly through the sea of sockpuppet user accounts in Citium. All accounts are sockpuppets and everyone looks like an anti-surveillance decoy. An account can be communicating on behalf of the account holder or simply just sockpuppeting (communicating on behalf of other accounts by indiscriminate mesh-tree multicast (IMTM)). No one else can scrutinize or prove which account is communicating on behalf of whom except for the account holder him/herself.

To further maximize deniability, all data have limited life expectancy on Citium nodes. For example, cryptographically split multiple slices of ciphertext sitting on users’ mobile nodes are set to self-destruct countdown of 24 hours. The parties can just tell the coercer that they deliberately erased their message according to a published schedule, and therefore cannot surrender them.

Confidentiality, Integrity and Availability

Confidentiality

Most of the conventional instant messenger systems (IMS) are built on a centralized authentication and authorization regime. Unfortunately, any centralized system is inherently susceptible to data breach. (More info here.) In contract, IMS built on top of Citium, paved by a network of decentralized nodes , is not at risk. For example, suppose that two users are trying to communicate with each other on Citium. Sender is Alice and the intended recipient is Bob. No third party can know for sure if he or she has been correctly deciphering a message from Alice to Bob because Citium utilizes the following security mechanisms: 1. Pretty Good Privacy (PGP) Encryption; 2. indiscriminate mesh-tree multicast (IMTM) threshold cryptosystem; and 3. Key/Message Equivocation. PGP is too popular to need further explanation. But since the IMTM threshold cryptosystem is unique to Citium and key/message equivocation is less known, we are going to spend more time explaining their InfoSec advantages.

Figure 1.1: Alice holds the two public keys given by Bob, i.e. KA & KB, because Alice and Bob have performed out-of-band authentication. Note that both of their devices manage their own cryptographic keys. In fact, all keys in Citium are generated or derived on-device. Private keys are never sent to anyone else, not even to the service nodes. Both public keys are used in the Hybrid Encryption module, which combines the deniability of a public-key cryptosystem, the efficiency of a symmetric-key cryptosystem, and the additional protection of threshold cryptosystem.

Figure 1.2: Citium Instant Messenger (CIM)  is an Off-the-Record Messaging (OTR) system. CIM user Alice posts* a message to another Citium user Bob. Here, Alice’s message is converted into a plaintext (M). M and Random Session Key (KR) are going to be processed through the Hybrid Encryption module as follows:

Plaintext (M) is first encrypted by the XXTEA and Blowfish algorithms with the Random Session Key (KR) resulting in a ciphertext (β). Slice β into n ciphertexts; and suppose n = 3, we have β1, β2 and β3.

BLOWFISHKR(XXTEAKR(M)) ⇒ βn=3
⇒ β1, β2, β3

In order to create the θ, one β is randomly picked among the βn. Suppose β1 is randomly picked from βn. KR is encrypted by ECDSA algorithm with KA, resulting which in turn combined with β1 to be encrypted by ECDSA algorithm with KB resulting in a ciphertext (θ):

ECDSAKB1 + ECDSAKA(KR))⇒ θ

Finally, the cipertexts of β2, β3, and θ (i.e. βn-1& θ) are ready for IMTM. Note that β1 is not needed here because it has already been encapsulated in θ.

* We use the word “post” instead of “send” because it makes more sense in the communication network of Citium, which combines the beauty of both cryptography and steganography. But what is steganography? Imagine the word “post” in the sense of Alice posting many anonymous and randomly placed classified ads on multiple newspapers around the world so everyone can see but only the intended recipient Bob knows how to locate them all and make sense of the underlying message. This practice, called steganography, is the flip side of cryptography. In cryptography, everyone involved knows a message has been sent. What’s not known — except to the decoder — is the content of the message. Steganography hides the fact that a message was even sent, usually by hiding it in plain sight.(In the movie “A Beautiful Mind,” the main character, played by Russell Crowe, becomes convinced that the Communists are hiding messages inside news stories and loses his mind trying to decipher them.)

Figure 1.3: Most instant messenger systems are designed that messages are directly pushed onto the client apps of the intended recipients. However, in Citium Instant Messenger system, push notifications are limited to a generic text reminder (i.e. “You have a new message.”)(G) being sent to the intended recipients. The intended recipients are required to fetch in the messages on their own, which will be explained later in the data flow cycle. For now, Alice sends two pieces of information to Bob’s service node IMSP Bolivia in case Bob is not currently online. One is the generic text reminder (i.e. “You have a new message.”)(G), and the other is the ciphertext (θ) that encapsulates the Random Session Key (KR) and one of the randomly chosen sliced ciphertext (β1).

Figure 1.4: The cipertexts of β2, β3(i.e. βn-1) are sent to the Citium network by indiscriminate mesh-tree multicast (IMTM) which distributes indiscriminately to as many Citium nodes (i.e. service nodes and user nodes) as possible by mesh-tree multicasting, effectively preempting link analysis and eliminating data breach due to failure at any single point.

Figure 1.5: If plaintext (M) is larger than 1024 bytes, anything beyond that are separated into a single slice (i.e. the excess ciphertext (βE) uploaded onto the service node of Alice (i.e. IMSP Australia). IMSP Australia will keep the βE for 24 hours before permanently deleting it. This does not only prevent running out of disk space but also further maximizes the deniability nature of Citium.

Figure 1.6: Service node of the intended recipient Bob (i.e. IMSP Bolivia) pushes the generic notification (“You have a new message.”) (G) and the ciphertext (θ) that encapsulates the Random Session Key (KR) and one of the randomly chosen sliced ciphertext (β1) to Bob’s node.

Figure 1.7: At this point, Bob is fully aware of the fact that someone has tried to post a message onto the Citium network with him as the intended recipient. Bob pings the whole Citium network with IMTM to fetch in the cipertexts of β2, β3, (i.e. βn-1).

Figure 1.8: Now, the cipertexts of β2, β3, and θ are ready for the Hybrid Decryption module.

Figure 1.9: Bob’s Private Key A (KA-1) is the corresponding private key to Bob’s Public Key A ((KA). Bob’s Private Key B (KB-1) is the corresponding private key to Bob’s Public Key B ((KB). They are both ready for the Hybrid Decryption module.

Figure 1.10: The Excess Ciphertext (βE) is fetched in from the Service Node of sender Alice (i.e. IMSP Australia) and is ready for the Hybrid Decryption module.

Figure 1.11: Before the deciphering process happens in the Hybrid Decryption module, all the ciphertext slices have to be in place. Assuming all of them from figure 1.8-10 are already in place, we’ll see θ being deciphered first by ESDSA algorithm resulting in β1 and KR.

ECDSAKA-1(ECDSAKB-1(θ)) ⇒ β1, KR

Combining β1 with the rest of its siblings (i.e. β2, β3) that were sliced at Alice’s side, Bob can now decrypt everything back to the plaintext as follows:

XXTEAKR-1(BLOWFISHKR-11 + β2 + β3)) ⇒ M

Finally, the correct plaintext (M) is revealed and delivered to Bob.

IMTM Threshold Cryptosystem

Indiscriminate mesh-tree multicast (IMTM) threshold cryptosystem means that a ciphertext is cryptographically split into multiple slices, which in turn are distributed indiscriminately to as many nodes  as possible by mesh-tree multicasting, effectively preempting link analysis and eliminating data breach due to failure at any single point.

In order for the intended recipient (Bob) to correctly decrypt the message from the sender (Alice), Bob has to obtain all slices of the ciphertext and to decrypt it with the right key. Bob has to make request to as many nodes  as he can through indiscriminate mesh-tree multicast (IMTM) until he collects all the slices. Only the intended recipient (Bob) can correctly reunite and decrypt all slices of the ciphertext.

Cryptanalytically Unbreakable: Unless some hackers can hijack all node  that holds the pertaining sliced ciphertexts and decipher them all with a quantum computer that only exists in theory, nothing during transit of the pertaining sliced ciphertexts can threaten the confidentiality of the message.

Key/Message Equivocation

In the Citium cryptosystem, an enemy hacker or a cryptanalyst might be able to intercept a ciphertext (C). There is a critical concept called key equivocation and message equivocation as shown in the diagram below:

The key and message equivocation are a measure for the strength of a cipher system under a ciphertext only attack for the key and message respectively. Key Equivocation and Message Equivocation refer to key strength under known plaintext attacks and key strength under plaintext attacks. The longer the received ciphertext, the greater the probability that the cryptanalyst will discover the secret key or plaintext. The probability of a cryptanalyst successfully deciphering a ciphertext generally increases with the length of the ciphertext. In Citium, the sliced ciphertexts minimize the size of the individual ciphertext so that the strength of the cipher is maximized.

Integrity

In information security, data integrity means maintaining and assuring the accuracy and completeness of data over its entire lifecycle. InfoSec integrity means that data cannot be modified in an unauthorized or undetected manner, and its definition is not to be confused with referential integrity in databases. A ciphertext slice cannot be changed during transit on Citium because it is encrypted by ECDSA (Elliptic Curve Digital Signature Algorithm). It is not only computationally intractable but also has enjoyed almost two decades of usage in open-source projects, such as Bitcoin. A successful hack (deciphering it without a private key) would allow any would-be attacker to make a tremendous amount of profit. The fact that this appears to have never happened is a very good empirical evidence for its security.

Availability

No single point of failure (SPOF) can impact the spread of cybertext slices and collection of them through indiscriminate mesh-tree multicast (IMTM).

Fully Decentralization: The majority of the contemporary online application service providers are using some forms of centralized methods (e.g. servers hosted in a datacenter) to structure their user management systems. It means monitoring. Because no matter how vigorously the service providers assert that they are effectively guarding the user information (e.g. email, IPs, username & password) against maladministration or hack, theoretically, they hold the power to modify or delete the information. Therefore, decentralization is absolutely necessary to achieve the level of confidence that one can rule out even theoretical mishaps from happening.

Fallibility

Fallible IMSP - Resolve Pain Point

Most instant messenger system providers (IMSPs) in the marketplace require prospective users to send in their personal information (e.g., email, username, and password) to register at the providers’ centralized servers. Only in doing so, the users can use the info to authenticate themselves to the centralized servers when they try to login to access the service in the future. Some prospective users may mistakenly believe that their personal information is unique and that their correspondence is secure because IMSP claims that personal information is checked against existing users for potential duplicates. But in fact, it is the IMSPs who create the account and they can always forge any user information for unethical ends. To tackle that, Citium uses a unique authentication mechanism for better checks and balances between users and IMSP: A user authentication info is entirely generated by the user but no one else. IMSPs still own the rights to grant authorized users access to their services.

Traditional Solution

Traditionally, instant messenger system providers (IMSPs) provide service to their users through the following authentication and authorization regime:

  1. A user submits his/her user info (e.g., account ID and password) to the IMSP.
  2. IMSP authenticates the user info.
  3. IMSP authorizes the user to use its service.

The traditional regime is not cryptanalytically secure, because IMSP holds all user info so that it is theoretically possible for the IMSP to falsify user behavior. Moreover, IMSP sometimes fails to secure against malicious attacks. Last but not least, social hacking preys on careless users who apply the same set of profiles (e.g., same username, gender, and age) at different IMSPs. Security breach at one of these IMSPs may cause Internet-wide privacy leak for the users.

Citium Solution

Citium is different from the traditional authentication and authorization regime. Instead of submitting user info, Citium works as follows:

  1. A user submits his/her user signature pertaining only to the applicable service session to the IMSP.
  2. IMSP authenticates the signature.
  3. IMSP authorizes the user to use its service.

The Citium regime is cryptanalytically secure because IMSPs are theoretically impossible to falsify user behavior. Even if the IMSP is hacked, the attacker is also theoretically unable to falsify the user’s signature or behavior. Most importantly, even the most careless users are unable to leak personal information because the Citium regime is designed like a black-box. Some call such an approach as zero-knowledge proof. IMSPs can authenticate users and authorize communication services without the need to obtain any user privacy information. Since any IMSP or unscrupulous hacker in the Citium regime can no longer be able to selectively delay or deny service, it is impossible to perform unauthorized analysis of user behavior.



en_USEnglish