• 1. Introduction.
  • Version.
• 1.1. What is Pest?
  • 1.2. How Pest Differs from IRC and Other Chat Protocols.
    • 1.2.1. One Station -- One Operator.
    • 1.2.2. Nets Instead of Channels.
    • 1.2.3. Identity is not Centrally-Registered.
    • 1.2.4. Messages are Authenticable, but not Opposable.
    • 1.2.5. Ostracism as the Sole Sanction.
    • 1.2.6. Cyclic Connection Graphs Permitted.
• 2. The Pest Station.
  • 2.1. The Station and its Operator.
  • 2.2. Peers and Keys.
  • 2.3. The WOT.
  • 2.4. The AT.
  • 2.5. Operator Console.
    • 2.5.1. Control Commands.
    • 2.5.2. IRC-Compatible Commands.
    • 2.5.3. Optional Commands.
• 3. The Pest Wire Protocol.
  • 3.1. Message.
    • 3.1.1. Timestamp.
    • 3.1.2. SelfChain.
      • 3.1.2.1. SelfChain (Broadcast Messages)
      • 3.1.2.2. SelfChain (Direct Messages)
    • 3.1.3. NetChain.
      • 3.1.3.1. NetChain (Broadcast Messages)
      • 3.1.3.2. NetChain (Direct Messages)
    • 3.1.4. Speaker.
    • 3.1.5. Text.
  • 3.2. Packets.
    • 3.2.1. Red Packet.
      • 3.2.1.1. Nonce.
      • 3.2.1.2. Bounces.
      • 3.2.1.3. Version.
      • 3.2.1.4. Reserved.
      • 3.2.1.5. Command.
      • 3.2.1.6. Message.
    • 3.2.2. Black Packet.
• 4. Worked Examples of Fundamental Mechanisms.
  • 4.1. Message Origination.
    • 4.1.1. Direct Message to a Peer.
    • 4.1.2. Broadcast Message.
  • 4.2. Message Receipt.
    • 4.1.1. Common Procedure for All Packets.
    • 4.1.2. Receiving a Direct Message.
    • 4.1.2. Receiving a Broadcast Message.
    • 4.1.2.1. Receiving a Broadcast Message: Immediate Messages.
    • 4.1.2.2. Receiving a Broadcast Message: Hearsay Messages.
    • 4.1.2.2.1. Simple Hearsay.
    • 4.1.2.2.2. In-WOT Hearsay.
    • 4.1.2.3. Receiving a Broadcast Message: Common Epilogue.
• 5. Test Vectors.
  • 5.1. Keys.
    • 5.1.1. Test Key A.
    • 5.1.2. Test Key B.
  • 5.2. Packets.
• 6. Misc. Clarifications.
  • 6.1. Symmetric Cipher.
  • 6.2. Signature.
  • 6.1. Endianism.
  • 6.2. Bots.
• Notes.

1. Introduction.

Version.

This document represents Protocol Version 0xFF.

1.1. What is Pest?

Pest is a peer-to-peer network protocol intended for IRC-style chat. It is designed for decentralization of control, resistance to natural and artificial interference, and fits-in-head mechanical simplicity -- in that order.

1.2. How Pest Differs from IRC and Other Chat Protocols.

Pest explicitly rejects the inherently-centralizing concepts of IRC (not even speaking of the even more noxious "walled-garden" atrocities perpetrated in recent years.) In place of IRC's collectivist concept of the server, every Pest user instead inhabits a stand-alone station of which he is the sole operator. Pest stations exchange authenticably-encrypted messages exclusively with an operator-configured set of peers.

1.2.1. One Station -- One Operator.

An IRC server is typically inhabited by a multitude of casual users and policed by a small group of privileged curators. A Pest station, on the other hand, is used exclusively by -- and is under the total control of -- one person: its operator.

1.2.2. Nets Instead of Channels.

Pest stations organize into nets. A net is a group of station operators who have a common interest. An operator who wishes to join a net must peer with at least one existing station on that net.

A broadcast message sent by one member of a net will be received by every other member. Nets may easily and organically undergo schismatic splits, or, on the contrary, unite into larger nets, as desired by their participants.

1.2.3. Identity is not Centrally-Registered.

To join a Pest net, an operator must simply find one or more existing members of that net who would peer with his station, and securely exchange a small amount of information.

He may choose any handle he likes, so long as it does not collide with that of a peer. Importantly, one person may easily operate multiple Pest stations, and inhabit multiple disjoint nets; and may use, if he wishes, a different handle on each net.

1.2.4. Messages are Authenticable, but not Opposable.

All Pest messages are authenticable -- a station will only accept a message if it carries a valid signature from a WOT peer (though in some cases, the message may not have been authored by that peer.)

However, they are also repudiatable (i.e. non-opposable) -- since all packet signatures are produced with symmetric keys, the recipient of a message cannot, at any point in time, prove to a third party that he was not in fact the author of that message.

Of course, Pest does not somehow prevent operators from creating opposably-signed messages using other software and transmitting them to their peers, on the rare occasions which actually call for this.

1.2.5. Ostracism as the Sole Sanction.

Because Pest does not impose -- unlike IRC -- a hierarchical structure of control, it offers no direct equivalents to IRC's "kick" and "ban". An annoying, tedious, or habitually-spamming station operator is instead to be, at first -- warned by his fellows; then -- ignored via Usenet-style killfiles, and -- if he proves incorrigible -- unpeered by his peers. In the end, the malefactor will find himself where he belongs: either alone or in the company of his own kind.

1.2.6. Cyclic Connection Graphs Permitted.

Pest broadcast messages are flood-routed -- i.e. they traverse all available propagation paths. Unlike IRC relays, Pest stations may be connected in any topology their operators prefer; concretely, loops are permitted, in the interest of decentralization.

Infinite packet storms are prevented via deduplication at the station level -- rather than by prohibiting loops, or via a spanning tree protocol, or any other traditional routing schemes that enforce acyclic connection graphs by demanding the existence of "root nodes", "supernodes", centrally agreed-upon tables, etc.

Pest station operators are not merely permitted, but in fact are encouraged to form richly cyclic connection graphs for the highest attainable resiliency.

2. The Pest Station.

2.1. The Station and its Operator.

The operator of a Pest station -- who may be a human or a bot -- has absolute control of the station and its configuration.

A station communicates exclusively with:

1. The operator -- via the operator console, an IRC-compatible interface.

2. An operator-selected set of remote peer stations -- via datagrams.

2.2. Peers and Keys.

In order for a pair of Pest stations to communicate, their operators must decide to peer them by agreeing¹ on a shared secret key K. Additionally, at least one of the peers must have a routable, static address (here and below: IPv4 address and port, in a.b.c.d:p notation), and it must be known to the other peer. Every packet sent by one peer to the other is signed/enciphered by the sender and verified/deciphered by the receiver using this K.

If, at some future time, the operator of either station no longer wishes to continue in this relationship, he may terminate the peering unilaterally, and the two stations will then be said to have unpeered.

2.3. The WOT.

A Pest station may have any number of peers. One or more² K for each peer is kept in a data structure referred to as the station's WOT (Web of Trust). The operator may edit this structure at any time, and changes take effect immediately. The WOT is never altered by the station except by direct command of the operator.

2.4. The AT.

A Pest station has another data structure, the AT (Address Table), which holds the last known address³ of each WOT peer. Like the WOT, the AT may also be edited by the operator at any time. Unlike the WOT, the AT is automatically updated by the station when a valid (per K) packet is received from a peer who is transmitting from a new IP.

Addresses in the AT play no role in the authentication of incoming packets: which peer a packet originated from is determined solely using the WOT. Rather, the AT is used exclusively for determining where to send outgoing packets.

2.5. Operator Console.

A Pest station is controlled by its operator through the operator console -- an interface implementing a minimal subset of the classical IRC protocol.

Traditional IRC offers no provisions for secure authentication or encryption; hence, it is recommended that a Pest station and its IRC client reside in one physical machine. Alternatively, they may run on separate machines and connect via an SSH tunnel or similar mechanism.

Per RFC-1459, an IRC message shall not exceed 512 bytes in length, including the mandatory CR-LF terminator. Thus, there are 510 bytes available for a command entered into the console (including its parameters); and similarly for any message emitted via the console.

2.5.1. Control Commands.

Control commands allow a Pest station's operator to review or modify the station's configuration. They follow the traditional IRC syntax (i.e. /COMMAND ARGUMENT). Any such command may be issued at any time, and must take effect (including preserving any state change to persistent storage) immediately.

Responses to control commands will be emitted through the console in the form of IRC NOTICE messages.

The following basic set of control commands must be supported:

2.5.2. IRC-Compatible Commands.

The console will accept, at minimum, the following IRC-compatible commands:

2.5.3. Optional Commands.

The console may support certain other commands:

3. The Pest Wire Protocol.

3.1. Message.

When a line of text is entered into the operator console, this text -- along with certain other data -- together will form a new message. This message may then be encoded into a packet and transmitted to peers; and these, in turn, will forward it to their operator consoles (and relay it to their peers) if the necessary conditions are met.

A Pest Message consists of 424 bytes, representing the following fields:

3.1.1. Timestamp.

A 64-bit timestamp⁴ from the packet's originator station. A station relaying a Broadcast packet must preserve the original's timestamp.

A station must reject any incoming packet with a timestamp more than 15 minutes in either direction (i.e. into the past or the future) from the moment (per the station's clock) the packet was received.

3.1.2. SelfChain.

3.1.2.1. SelfChain (Broadcast Messages)

A 256-bit hash⁵ of the most recent previous message originated by the originator of this message.

A station originating a broadcast message for the first time must set SelfChain to zero.

If a station receives a broadcast message where SelfChain is equal to zero, where Speaker is e.g. nebuchadnezzar, and this speaker had never been seen previously, it will emit to the operator console a warning of the following form:

Met nebuchadnezzar !

If however any messages with a Speaker of nebuchadnezzar have been seen previously, but this message's SelfChain does not match the hash of the immediately-preceding one, the following warning shall be emitted to the console:

nebuchadnezzar forked! prev.: "blah..."

... where "blah..." is the text of the previously-seen message pointed to by the SelfChain (if available in the buffer; if not, a base-16 representation of SelfChain is displayed instead.)

And nebuchadnezzar is henceforth considered forked. While he is forked, the warning, in the above form, shall be emitted in the console (via NOTICE) after every message received where Speaker is equal to nebuchadnezzar.

The fork will be considered resolved only after the station operator executes the command /RESOLVE nebuchadnezzar (after having a stern talk with the peer who had been relaying messages from the phony nebuchadnezzar!)

A station must not reject a broadcast message simply because its Speaker and SelfChain indicate a state of forkage. Doing so would make recovery from certain failures (lost packets; data corruption) impossible, and constitutes a denial-of-service vector. However, station operators are encouraged to make use of out-of-band (e.g. GPG) methods to resolve a fork, should one happen to arise; and to mercilessly unpeer anyone found to be deliberately causing a fork under whatever pretext.

3.1.2.2. SelfChain (Direct Messages)

A 256-bit hash of the most recent previous message generated by the originator of this message in direct message sessions with this station.

In every other respect, the same rules as for broadcast messages apply.

3.1.3. NetChain.

3.1.3.1. NetChain (Broadcast Messages)

A 256-bit hash of the most recent previous broadcast message seen by the originator of this message.

Currently this is not used for anything.

3.1.3.2. NetChain (Direct Messages)

Must be set to zero.

3.1.4. Speaker.

A 32-byte field representing the Handle used by the originator of this packet. If this string consists of fewer than 32 characters, all unused bytes must be set to zero.

3.1.5. Text.

The (typically, human-readable) payload of the message. All unused trailing bytes must be set to zero.

3.2. Packets.

A message, together with certain information which helps its recipient decide what to do with it, is termed a packet. Every packet starts life as red⁶ (i.e. plaintext).

3.2.1. Red Packet.

A red packet consists of 444 bytes, representing the following fields:

3.2.1.1. Nonce.

16 bytes of garbage, exclusively for use as cipher nonce; obtained from TRNG, if possible.

3.2.1.2. Bounces.

This 1-byte field represents the number of times the message in this packet had been relayed between stations. A station must reject messages which have experienced more than a preconfigured number of bounces. The recommended cutoff value is 3.

3.2.1.3. Version.

This is a 1-byte field representing a "degrees Kelvin" (i.e. decrementing) version. (See version.)

3.2.1.4. Reserved.

This 1-byte field must equal 0.

3.2.1.5. Command.

This 1-byte field represents the intended purpose of the message M carried by the packet, as stated by its originator, and must have one of these values:

3.2.1.6. Message.

A Pest message can be either:

1. Direct -- Intended for a single recipient.

2. Broadcast -- Intended for the widest possible dissemination. A broadcast message may be either immediate or hearsay.

A message which is marked direct is sent to a single peer. A broadcast message is sent to every peer in the originator station's WOT, and will be propagated to their peers, and so on.

A broadcast message will often reach stations which are not in its originator's WOT. From the point of view of these stations, such a message is termed hearsay; and, when it is forwarded to an operator console, it is specially marked so as to distinguish it from an immediate message.

3.2.2. Black Packet.

Prior to leaving a station, a red packet must be ciphered and signed using a K found in the WOT for the peer who is to receive it. After this happens, the packet is referred to as black.

A black Pest packet consists of 508 bytes (excluding IP and UDP headers) representing the following fields:

A third party without knowledge of K is unable to read such a packet; to distinguish it from arbitrary random noise; or to generate a spurious replacement (including via replay, in whole or in part, of a previously-sent packet) that could be accepted by the addressee.

Every incoming (without exception, black) packet has its Signature verified against each K in the receiving station's WOT, in random order.

If verification of the packet against a given K succeeds, it is then known to have been signed by the peer associated with that K. The packet is then decrypted (with K) and becomes red once again; at this point, the station is able to process the message it carried.

However, if none of the attempted verifications succeed, the packet is considered "martian" and silently discarded⁷. The receipt of a martian packet has absolutely no effect on a station, aside from wasting a small amount of CPU time. This provides a reasonable degree of DDOS resistance. A station may keep inexpensive statistical counters of martian packets.

4. Worked Examples of Fundamental Mechanisms.

4.1. Message Origination.

When a line of text is entered by the station operator into the operator's console, the station is termed the originator of the message.

There are two possible scenarios:

4.1.1. Direct Message to a Peer.

Suppose a station operator using the handle shalmaneser had issued the command /PRIVMSG nebuchadnezzar Come to tea. the following actions will be performed:

1. A WOT peer entry with a handle nebuchadnezzar will be located. (If one such does not exist, or nebuchadnezzar is currently paused, nothing further happens, and a warning will be emitted to the console.)
2. The most-recently used key K for nebuchadnezzar will be located. (If no keys are known for nebuchadnezzar, nothing further happens, and a warning will be emitted to the console.)
3. K will be separated into K(S) -- the first 32 bytes of K being the signing key, and K(C) -- the cipher key (the last 32 bytes of K.)
4. The AT entry for nebuchadnezzar will be located. (If one such does not exist... see above.)

5. A red packet will be created, where:

   Bytes	Description	Value
   16	Nonce	random bytes
   1	Bounces	0
   1	Version	255
   1	Reserved	0
   1	Command	0x01 (Direct Message)
   424	Message	as given below:

   Bytes	Description	Value
   8	Timestamp	shalmaneser's current time
   32	SelfChain	hash of shalmaneser's previous direct message to nebuchadnezzar
   32	NetChain	0
   32	Speaker	shalmaneser (padded with null bytes.)
   320	Text	Come to tea. (Followed by 308 null bytes.)

6. A black packet is created from the above red packet, where:

   Bytes	Description	Value
   444	Ciphertext	The red packet, after ciphering with key K(C).
   64	Signature	The result of signing Ciphertext with K(S).

7. The black packet (henceforth -- packet) is stored in shalmaneser's transmission queue.

8. The packet is transmitted to nebuchadnezzar's current address, determined in step 4.

9. When an identical packet is echoed back from the above address, the transmission is considered complete. This is expected to happen within an operator-configurable period of time (recommended: 1 second.) If it does not, a warning will be displayed in shalmaneser's console:

   nebuchadnezzar did not ACK!

10. The packet is removed from shalmaneser's transmission queue.

4.1.2. Broadcast Message.

Suppose a station operator using the handle shalmaneser had issued the command /PRIVMSG #pest Good morning, everyone! the following actions will be performed:

1. For each WOT peer P in shalmaneser's WOT:
2. The most-recently used key Pk for P will be located. (If no keys are known for P, P is simply ignored.)
3. Pk will be separated into Pk(S) -- the first 32 bytes of Pk, being the signing key and Pk(C) -- the cipher key (the last 32 bytes of Pk.)
4. The AT entry for P will be located. (If one such does not exist, P will be ignored and we move on to the next peer.)

5. For each peer, a red packet will be created, where:

   Bytes	Description	Value
   16	Nonce	random bytes
   1	Bounces	0
   1	Version	255
   1	Reserved	0
   1	Command	0x00 (Broadcast Message)
   424	Message	as given below:

   Bytes	Description	Value
   8	Timestamp	shalmaneser's current time
   32	SelfChain	hash of shalmaneser's previous broadcast message
   32	NetChain	hash of the previous broadcast message seen by shalmaneser
   32	Speaker	shalmaneser (padded with null bytes.)
   320	Text	Good morning, everyone! (padded with null bytes.)

6. A black packet is created from the above red packet, where:

   Bytes	Description	Value
   444	Ciphertext	The red packet, after ciphering with key Pk(C).
   64	Signature	The result of signing Ciphertext with Pk(S).

7. The black packets (one for each peer) are stored in shalmaneser's transmission queue.

8. From here, proceed exactly as in the direct message example.

4.2. Message Receipt.

4.1.1. Common Procedure for All Packets.

Suppose a station operated by nebuchadnezzar has received a packet. (The packet is from shalmaneser, but nebuchadnezzar does not know this yet, he has to first authenticate and decrypt it.) As all Pest packets traveling over the public internet are black packets, it has the structure:

nebuchadnezzar's station will carry out the following procedure:

1. For each WOT peer P in nebuchadnezzar's WOT, in random order:
2. Pk for P will be located. (If no keys are known for P, P is simply ignored.)
3. Pk will be separated into Pk(S) -- the first 32 bytes of Pk, being the signing key and Pk(C) -- the cipher key (the last 32 bytes of Pk.)
4. HMAC256(Ciphertext, Pk(S)) is compared to Signature. If they do not match, the next P is tried. If none match, the packet is declared martian and silently discarded.
5. If a match has been found, Pk(C) is used to decrypt Ciphertext and reproduce the original red packet.
6. The Timestamp is compared to the current system time and if it is more than 15 minutes in the past or the future, the packet is declared stale and is silently discarded.
7. The message is compared to the contents of the deduplication queue, a ring buffer holding the last hour's worth of messages, or last 256kB, whichever represents a greater number of messages. If an identical message is found in the queue, the packet is declared stale and is silently discarded and we stop here.
8. The message was not stale; it is placed into the deduplication queue.
9. At this point, the next step in the algorithm depends on the value of the Command field...

4.1.2. Receiving a Direct Message.

Continuing after the final step of the Common Procedure:

1. The Speaker field is compared to all handles known for the peer from whom the packet came (per step 4.) If none match, a warning is emitted, e.g.: Direct message from 'bob' (shalmaneser) ... where the string in the parentheses is a WOT handle stored with the K which had validated the packet in step 4.
2. nebuchadnezzar's console will display the Speaker, followed by the Text, e.g. shalmaneser: Come to tea. in the standard format for IRC private messages.
3. Any possible SelfChain warning is displayed.

4.1.2. Receiving a Broadcast Message.

Continuing after the final step of the Common Procedure:

1. The Bounces field of the red packet is compared to the operator-configured cutoff. If it is in excess of the cutoff, the packet is silently discarded.
2. The Speaker field is compared to all handles known for the peer from whom the packet came (per step 4.). The next step of the algorithm depends on the result of this comparison.

4.1.2.1. Receiving a Broadcast Message: Immediate Messages.

If the value of Speaker corresponds to one of the handles stored in nebuchadnezzar's WOT for the key K which had validated the packet (in this case, shalmaneser), the message is known as an immediate message. It is considered prima facie authentic, and displayed in nebuchadnezzar's console in the standard form for IRC messages, marked with channel #pest.

4.1.2.2. Receiving a Broadcast Message: Hearsay Messages.

4.1.2.2.1. Simple Hearsay.

If the value of Speaker does not correspond to any of the handles stored in nebuchadnezzar's WOT for the key K which had validated the packet, the message is known as a hearsay message.

Consider the case where the K which had validated the message corresponds to shalmaneser, but the Speaker of the message is hammurabi (and there is not a hammurabi in nebuchadnezzar's WOT.)

nebuchadnezzar's station still knows which of his peers had sent in the message (shalmaneser), because it had been signed and decrypted with that peer's K. However, it also knows that the message had not been originated by shalmaneser. (Or, if it had been, he is perhaps suffering from multiple personality disease.)

In any case, nebuchadnezzar must be warned that the message is hearsay.

Therefore the Text will be displayed in nebuchadnezzar's console (in channel #pest) in the following form:

hammurabi(shalmaneser): hey listen!

... where the handle in parentheses corresponds to the WOT peer from whom the packet had come.

4.1.2.2.2. In-WOT Hearsay.

Consider the case where the value of Speaker in an incoming message does not correspond to any of the handles stored in the receiver's WOT for the key K which had validated the packet, but in fact represents a handle used by another member of that WOT. This can happen if the immediate copy of that packet (i.e. received directly from its originator) has been lost or delayed in transit.

When such a packet is received and validated, it is placed into the station's embargo buffer and will remain there for an operator-configurable interval (recommended: 1 second) with the expectation that the immediate copy of the packet will arrive shortly, and "knock out" the embargoed hearsay version. If however the embargo interval elapses and the immediate copy of this packet is not received -- it will be placed into the deduplication buffer, emitted to the station's console, and rebroadcast to peers (see below.)

4.1.2.3. Receiving a Broadcast Message: Common Epilogue.

In both Immediate and Hearsay cases, after the message Text is displayed in the receiver's console:

1. The Bounces field is incremented by 1.
2. The message is rebroadcast (see 4.1.2. Broadcast Message) to each of his WOT peers, in random order.

5. Test Vectors.

5.1. Keys.

5.1.1. Test Key A.

The base64-encoded key:

2Newlil7CEAcrLlLJhJaX1bOhYMzhbzX5s/UPYGXM3xTTry7sqvwYyp6ffinpQmgVVKZahjgIGILrPcAH2oI6A==

... when correctly decoded and broken into two 256-bit segments, represents the following (shown here in base-16) signing key:

d8d7b096297b08401cacb94b26125a5f56ce85833385bcd7e6cfd43d8197337c

... and the following cipher key:

534ebcbbb2abf0632a7a7df8a7a509a05552996a18e020620bacf7001f6a08e8

5.1.2. Test Key B.

The base64-encoded key:

DpLg4cXUoraDQHaSfScfO7rV4jJGDKvq1RkpSnHRKKhhCZXMSvaq6QGKgcAbYriNXsw0bdiiz2/M0VeKL1Cb6g==

... when correctly decoded and broken into two 256-bit segments, represents the following (shown here in base-16) signing key:

0e92e0e1c5d4a2b6834076927d271f3bbad5e232460cabead519294a71d128a8

... and the following cipher key:

610995cc4af6aae9018a81c01b62b88d5ecc346dd8a2cf6fccd1578a2f509bea

5.2. Packets.

TBD

6. Misc. Clarifications.

6.1. Symmetric Cipher.

Serpent is the only symmetric cipher to be used.

6.2. Signature.

All signatures are to be carried out using HMAC-256.

6.1. Endianism.

All byte ordering in Pest, without exception, is little-endian unless otherwise stated.

6.2. Bots.

If an operator wishes to run bots, guest accounts, etc., additional stations may be set up to peer with his primary one; on the same physical machine, if so desired.

Notes.