Pathologically paranoid PSYC deployment and operations

This is a proposal by Kol Panic to implement our own pseudonymous routing.

Requirements

1. Repeatable identity - Users must be able to build reputation without necessarily linking their user identity to a real world identity.
2. Location independence - It must not be possible to prevent a user from distributing content under an identity by conducting DoS against his home server.
3. Anonymous routing - It must conduct reliable round trip transactions with perfect anonymity of the physical and logical route taken by the message.
4. Usability - All cryptography must be automated in a task-oriented fashion. The client should use standard library to manage the keys of the user and the contact. Servers should manage all keys used in routing.

<lynX> PSYC over pseudonymous routing technology intends to fulfil these requirements. We are working on it!

Elements

Public key infrastructure

Each server participating in the P3DO infrastructure is a certificate authority with signing authority for its domain. It is responsible for:

1. Signing the keys of users registered to that domain
2. Countersigning keys of the servers with which it has federated
3. Contributing to the PKI by maintaining a key server
4. Maintaining copies of all keys that it has signed on both its key server and its key ring

Due to the demands of P3DO, the psyc encryption community should maintain its own public key infrastructure. This infrastructure uses DNS to distribute public keys. Due to the limitations of DNS as a delivery vector, the TXT records used will contain a public key finger print and pointers to key servers rather than the key itself. This is also one reason for the countersignature requirement. Reciprocal signing of servers' public keys signals when there are key changes, mitigating the exposure to DNS exploits.

By signing user keys, the server allows the user to authenticate even when the server itself is not available. Any server with access to a copy of the server's public key -- whether through the DNS pointer, cache, or discovery on a key server -- can authenticate the user and allow him to use that identity. This allows the authenticating server to connect the user to the network where the user can use onion routing or other strategies to communicate from that identity.

Multicast onion routing

Each server participating in the P3DO infrastructure shall maintain one or more multicast contexts with listener components that are dedicated to multicast onion routing traffic.

Listener components are bots that subscribe to another context. When the context to which the listener is subscribed sends a message, that message is processed by the bot:

• If it has seen the message before then the listener will ignore it.
• If it knows the owner of the public key with which the message is encrypted, it will forward the message to the key owner as well as rebroadcasting it on its own multicast context.
• If the listener does not know the key owner then it will rebroadcast the message on its speaking context without forwarding it.

Routing is possible because servers sign the keys of other servers they know. The user can specify a general route of 2 or more hops by selecting the keys with which the message is encrypted. Servers then add additional hops when they forward messages that are decrypted with their own server key. Additional hops must not include a server key, but should instead use the public keys of MOR contexts that it knows to be routes to the destination. The public keys of MOR contexts are not published on the keyservers, but are only available by querying a MOR context of which the listening service is a member.

TLS - transport layer security

Although content will be encrypted, routing can only be obfuscated. Therefore P3DO servers should employ a recent TLS protocol. This is particularly important for the client to server endpoints where the sender or the recipient may be identified.

Use cases

• Geeks - Face it. As Geeks, we want to be naughty but we don't really know how. Going overboard on encryption that we don't need allows us to pretend we are naughtier than we are. That's fun.
• Political dissidents - The value of Twitter to those protesting the 2009 Iranian elections was that it allowed anonymous repeatable identity for content delivery to a social network, albeit with limitations[1].
• Personal business - It doesn't really matter why people may want to use encryption.

Non-use cases

Here are things that people may think are use cases for secure communications, but aren't really. Not that criminals of different kinds won't use the infrastructure, but that restricting its use for these reasons is silly[2].

• Pedophiles - In 1988, police in 14 States and 4 countries simultaneously executed 21 search warrants resulting in 13 arrests and broke up a usenet-based pedophilia social network called "Pedo U". These individuals were exposed by social engineering attacks as much as by a failure of their security precautions. No functional communication system will ever be secure enough to protect a person with an obsession from their own destructive impulses.
• Organized crime - The mafia already has secure communications.
• Terrorists - Cyber terrorism 'overhyped' 'Nuff said.