October 30



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.


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:

  1. Permissionless
  2. Deniable Authentication
  3. 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.

Authorization ✓

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.


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 InitiatorContacts Invitee
Alicea random person D
Alicea random person E
Alicea random person F

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.


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.



You may also like

The Unsecure Email

Define: Message-oriented middleware (MOM)

Leave a Reply

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

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Subscribe to our newsletter now!