100% secure and reliable communications protocol [Archive]

ckaihatsu

19th April 2012, 17:07

Introduction

Anyone who has ever been part of an ad-hoc-type small group knows the highs and lows of it. When things are working well it feels as if everyone is pushing pedals at just the right time on the same bicycle. But when things aren't going so well it can feel as if everyone suddenly switched to their own language to communicate about how to steer the bicycle.

Based on personal experience I decided to formulate a simple and hopefully effective system that would be a lean, easy tool to use, leveraging basic computer software -- the common spreadsheet. The result was the 'Affinity Group Workflow Tracker' in 2007, available at tinyurl.com/yvn2xq. While it claims to be nothing more than a table for keeping track of points raised within a group of like-minded people, its effective "motor" is the process of having one person define the *process*-oriented, or action-minded, portion of each contribution to the group.

This simple step can be surprisingly helpful, especially in a group that covers a wide variety of ongoing topics in a number of concurrent discussions. While nothing can substitute for a thorough going-over of the particulars of a group discussion, as from emails or a message board, the workflow tracker table can be a bank-statement-like summary-at-a-glance for social and political matters.

The workflow tracker is especially appropriate for our online age, in which not all ad hoc small groups have the luxury of meeting at a physical location on a regular basis. Since we're living in a time when the means of many-to-many communications are inexpensive and now the norm, over the Internet, using regular email accounts allows *any* group of disparate participants to use the A.G.W.T. over the net by designating one person to fill the role of database maintainer, possibly in a shared, rotating capacity.

This 'XOR protocol' is a complement to the original 'Affinity Group Workflow Tracker', making use of further technological advantages available now that enable an affinity group to also ensure a near-perfect degree of authenticity and confidentiality in their internal communications over the net.

The 'XOR protocol' is constructed to serve as the "steel pipes" over the Internet through which participants may be assured of the authenticity of the identities of the other participants they are communicating with. This tool serves as the "socialware", if you will, that can be transparently held up to the light of common sense for one to verify with their own understanding.

The disclaimer here is that nothing technical can substitute for the self-activity of the participants themselves and for the reliability of their own organic social interconnections. If this tool is to be used for serious and non-trivial social matters it is recommended that the participants have opportunities to at least informally get-to-know and "cross-validate" each other to everyone's individual satisfaction -- this may be on the grounds of social and/or political principles, histories, activities, goals, etc.

This "socialware" contains several non-intuitive, possibly surprising advantages made possible by the unique properties of the underlying mathematics that it employs in its component parts. To begin with:

- This protocol allows for the greatest flexibility among participants with the least amount of overhead, or effort. It encourages a mode of communications that can be verified by everyone in the group while retaining absolute privacy for the sender and recipient, while also allowing any number of off-group communication configurations.

- It can be configured to range from an impenetrably super-cryptic super-stealthy mode of operation to a more normal email-message kind of functioning, without compromising its underlying functionality.

- It allows for 'from-me' or 'to-you' types of participant verification per message, or a combination of the two for a 'from-me to-you' method that remains verifiable by anyone in the group. It is essentially a simplification of the public-key encryption method, but using the XOR mathematical logic function as a "shortcut". http://en.wikipedia.org/wiki/Public-key_encryption

- No matter the number of participants the topology remains absolutely decentralized, with no leader or even administrator needed for its ongoing operation. (The group may want to reach agreements on its configuration and future changeability, though.) It encourages and reinforces its validity by usage through the group's participants in common, making patterns of communication transparent to the group while remaining opaque to outsiders or adversaries.

- Its method of encryption is mathematically perfect and remains better than any other encryption method possible. This is because it effectively uses a unique encryption code for *each character* of each message, with a brand new unique code for *every transmission*. The size of the code covers the size of the message entirely, with no space left for attacks that could use a part of the code to "crack" the entire message. The encrypted text and the password fit hand-in-glove, as perfect complementary overlays to each other, with a perfect one-to-one matchup required to extract the encrypted plaintext. This method is called a 'one-time pad'.

- This entire tool makes use of the XOR function at every step. It is a fundamental mathematical calculation that is 100% undefeatable. To use an analogy the best way to describe it would be to imagine starting by selecting a number at random that is between negative-infinity and infinity. Now, within that range select a *second*, *different* number. Take the *difference* of those two numbers to produce a *third* number. The critical question here is would someone be able to guess or calculate that *third* number if they were missing either the *first* number or the *second* number? Think about this for awhile and prove it to yourself. (For example [1] could be 582,032. [2] could be -9,030,213,040,056. The *difference* between these two numbers is [3] 9,030,213,622,088. Would someone be able to find [3] if they knew [2] but were missing [1]? Or what if they knew [1] but didn't know [2] -- could they still figure out [3]?) A more *humanistic* analogy for the XOR function would be a person's own unique identity, or individuality -- the [3] part. If [1] is the person's description of their past, and [2] is the person's description of themselves in the *present*, we might say that they then have [3] -- their *overall* individual identity. But if someone -- for whatever reason -- can't describe [1], their past, or [2], their present, then it is very difficult for them to define their [3] *total* identity. Analogies aside, the logic of the XOR function is this: It's either *one*, or the *other*, but *not both*, and *not neither*. So, for any given two elements out of a set of three, if any two are empty then the third one is, too, otherwise any two elements out of the three will be full with the remaining one empty. In practice this logic allows any two elements to *recreate* the third element if any one out of the three elements is damaged or goes missing.

- Want to get started right away? Do two web searches to find the following free applications that are written in JavaScript. You'll want to get the 'One-Time Pad Generator', for generating random blocks of encryption code, and the 'Padlock Disposable-Key Cipher (DKC)', for the XOR operation on blocks of text.

Definitions

There are only nine components to this protocol, and only one mathematical operation ever, the exclusive-or (XOR) function. While nine components may sound like a lot, at least three of them are static, and only three XOR operations are needed for any outgoing or incoming message (four are required for *both* from-me and to-you types of authentication).

- PIK (most transparent) -- The Participant Internal Key is your "public" key to the group. This key enables others to authenticate messages to or from you since it is visible to everyone in the group and is indexed to your person.

- GCK -- The Group Common Key is unique to the group and should be kept secret to the group by all participants. It is used in conjunction with the PIK to cross-authenticate that messages are unique to the group *and* that they originate from or are intended for certain participants in the group.

- PIM -- The Participant ID Mix is the result of an XOR operation performed on the Group Common Key (GCK) and the Participant Internal Key (PIK). The PIM, when used in conjunction with additional XOR operations, cross-authenticates that messages are unique to the group *and* that they originate from or are intended for certain participants in the group.

- PPK (private) -- The Participant Personal Key is your *own* private key that should never be divulged to anyone else. It is used to derive a *secondary* component (the PKM) that effectively serves as the "membrane" between you and outgoing or incoming messages. As long as it remains static or is kept track of, it can provide return-reliable decryption ability and proof of authenticity.

- ART (private) -- The Arbitrary Random Text is a block of randomly generated code that becomes part of the unique per-message messaging pipeline. It must be newly generated for each outgoing message, or designated-return incoming message, to provide the intended full encryption and authentication functionality of the protocol, in accordance with the underlying operation of the one-time pad.

- PKM -- The Personal Key Mix is the "membrane" between you and outgoing or incoming messages. The PKM is the result of an XOR operation performed on your Participant Personal Key (PPK) and the Arbitrary Random Text (ART). It is sent as the second transmission (out of 2 total) for any given message, and serves to encrypt and authenticate according to you and your person only, without divulging your actual consistent Participant Personal Key (since it is mixed with the ART to create the outgoing PKM). A person cannot derive either your Participant Personal Key or your Arbitrary Random Text from possessing only your Personal Key Mix. A unique PKM is generated (through the generation of a unique ART) for each individual message sent out or designated-return incoming message.

- PTM -- The Plaintext Message is the human-readable text message that is either sent out or received. Needless to say, it is *never* sent out as-is, but rather is used as one component of this protocol's pipeline.

- PMM -- The Personal Message Mix is the result of an XOR operation performed on the Plaintext Message (PTM) and your Personal Key Mix (PKM). Because of the exclusivity of the XOR function a person who receives a communication *must* have both the Personal Message Mix (PMM) *and* the Personal Key Mix (PKM) in order to find out the Plaintext Message (PTM). This is why messages sent with this protocol are made up of two separate, independent transmissions. (For example the Personal Message Mix may be readily derived by anyone in the group, as for authentication and verification purposes, but without also having the PKM for that message the Plaintext Message within will not be recoverable.)

- MPR -- The Message Parcel is the result of an XOR operation performed on the Personal Message Mix (PMM) and the Participant ID Mix (PIM). Since it is derived from only these two components it provides absolute proof of authenticity according to the Participant ID Mix, which itself is derived only from the Group Common Key (GCK) and the Participant Internal Key (PIK). The Message Parcel (MPR) may be posted out in the open, for all of the group's participants to observe and verify according to the Participant ID Mix (PIM) contained within, providing that participants are informed (or can determine with several "brute-force" attempts) *which* PIM to check for. (The PIM -XOR- MPR will yield the PMM, Personal Message Mix, but the Personal Message Mix, PMM, *requires* possession of the corresponding PKM, Personal Key Mix, to recover the actual Plaintext Message.)

In this way the Message Parcel (MPR) contains authentication of *one* Participant ID Mix (PIM), or actual person. This MPR's participant could either be the sender or the recipient, but not both. (The other component of the MPR is the PMM, Personal Message Mix, which contains the Plaintext Message unique to the Message Parcel.) If *both* 'from-me' and 'to-you' authentication is required then the initial MPR will use the *sender's* PIM, to authenticate the sender, and will then have to be combined with the *recipient's* PIM, using XOR, to produce a *second* (or secondary) MPR that may then be sent along. Stripping the second MPR of its PIM will recover the *initial* MPR that contains the *sender's* PIM. Then, stripping the initial MPR of its sender's PIM will recover the Personal Message Mix that will only release its Plaintext Message if the corresponding Personal Key Mix is in possession.

Initial Configuration

All participants should have a common area in which everyone can see messages (MPRs) posted. This could be the 'Reply All' function of email, a message board, a one-off posting service, a blog, a wiki, or anything else. While using a common area is not a *requirement*, the protocol *does* rely on social group dynamics to a large extent, particularly for open cross-verification of MPRs sent, against their respective PIMs.

All participants should make sure that they are all oriented to the same common area, that they all have each other PIKs, and that they have the Group Common Key (GCK) in secret. Finally every participant should have at least one *private* channel of communication for every other, for the second-step transmission of the Personal Key Mix (PKM), per Plaintext Message (PTM). Depending on particular social circumstances this may be *all* that's needed, meaning that a high degree of anonymity may be maintained, with social cohesion being built from scratch through ongoing participation.

A "super-stealthy" mode of communication could be implemented, at the cost of increased attention from all participants, by having only MPRs posted at the common area, with no accompanying comments or information whatsoever. All participants would have to check each and every MPR posted against their own individual PIM to see if the MPR is directed to them individually. If a match is found the participant would know to anticipate that the corresponding PKM will be transferred to them through their private channel of communication.

More realistically, though, email could be used with minimal open content used to specify who an MPR is directed to, or to the group as a whole, etc. Another option might be to use hashes of PIMs to provide a directed "heads-up", etc.

On the more-transparent side of things the PKM for an MPR could be sent out in the open as well, so that all participants could see a message in common, while retaining the authentication and encryption function of the protocol, limited to participants only.

The process of the protocol's pipeline could also be reversed, to enable a designated-return route, by request. The requester could begin by sending any arbitrary random code text, as a pre-defined PKM to the sender. The sender would receive that PKM and use the XOR function to combine it with the Plaintext Message to produce a PMM. The PMM would *not* be sent back, though, because an adversary who obtained both of the two transmissions would have both the PKM and the PMM required to recover the Plaintext Message. Instead, the regular second step of combining the PMM with the sender's PIM would produce a return-MPR to send to the requester. This method would effectively create a one-time specified *channel* for a communication between two participants, either through or outside of the common area. The only proviso is that if the common area is used for both the PKM and the MPR the original Plaintext Message could be recovered by any participant by determining the MPR's corresponding PIM.

Outbound

A sender begins with a fixed-length block of text -- one may want to generate a random block of code and then "hollow it out" to make just enough "room" for the desired text within. Any irregular spacing of words and sentences can be used within the "padding", as long as it's still readable. Various non-space symbols may also be used instead of spaces for a "paranoid" level of non-pattern-making message text security. The final resulting block of text is the Plaintext Message (PTM).

The same fixed-length size of text is generated randomly to produce a one-time Arbitrary Random Text (ART). This ART is then combined with the participant's Participant Personal Key (PPK) using the XOR function to create a one-time Personal Key Mix (PKM). This Personal Key Mix is XORed with the Plaintext Message (PTM) to produce a Personal Message Mix (PMM). Finally, the Personal Message Mix is XORed with the sender's Participant ID Mix (PIM) to create the Message Parcel (MPR) which is then ready for transmission. The Personal Key Mix has to be sent separately, through an appropriate channel, for the recipient to be able to recover the original Plaintext Message.

In a variation of this method the sender would not include *their own* PIM with the PMM to produce the MPR -- instead they could direct the MPR *at* a participant in particular by using the *recipient's* PIM with the PMM to produce the MPR.

In either case the recipient would have to either strip out *their own* PIM from the MPR to recover the PMM (then XORed with the received PKM to recover the PTM), or else would have to know the correct PIM to strip away, or would have to determine it from using several "brute force" attempts on the MPR from known group PIMs.

Inbound

Most typically a recipient would see something posted to the common area with themselves listed as the recipient. This would let them know to copy off that block of text and to treat it as an MPR. If they knew it was a 'from-me' *and* a 'to-you' MPR they would know to first strip away their own PIM using an XOR operation to recover the *underlying* MPR. They would then use another XOR operation to strip away the *sender's* PIM to recover the Private Message Mix (PMM) within.

(*Any* participant could realistically do this step if they knew the process required and the respective PIMs involved, or could figure it out from several attempts at the posted MPR. The group may decide to *encourage* this practice by making the process clear, so that all postings can be verified by all participants according to each MPR's contained PIM(s). Participants could get as far as recovering the PMM from any posting, but would have to also know the corresponding PKM as well to be able to recover the included Plaintext Message.)

The recipient would finish by XORing the PMM with the PKM received from the sender, recovering the original Plaintext Message.

Adversary

An adversary with no inside knowledge whatsoever would not know where to start with any MPR they found posted. The protocol requires specific information, processed in specific steps, for an all-or-nothing result. To the casual observer all MPR postings would be impenetrable.

The Group Common Key (GCK) should be kept under the strictest security among all participants in the group. It is what all participants have in common and it defines the internal formal cohesion of the group according to its weakest link. Likewise, each participant's own Participant Internal Key (PIK) should be kept internal to the group, although it's understood that all PIKs will be openly available within the group.

An adversary would have to know the Group Common Key, the respective PIK(s), access an MPR posting, *and* know something of the structure or process involved to take the first step at penetrating the protocol's communications (to determine the PMM). Then, as for any group participant, the appropriate PKM would have to be obtained as well to match up with the PMM in order to recover the Plaintext Message.

An adversary who only compromised *private* (one-to-one) channels of communication would likewise only have a useless one-half of the XOR whole, if the regular configuration was in use. Without internal-group access no MPRs would be found to complete the puzzle.