The PSYC protocol syntax allows for application of encryption on message content, variable data or the entire packet or circuit.

psyced supports TLS wrapping for all kinds of client protocol accesses and also allows for TLS interserver encryption, although it is currently broken for outgoing PSYC1 links. Additionally, psyced supports installation as a Tor hidden service for increased authentication security and opportunistic anonymity.

With PSYC2 instead, cryptography is fundamental to the entire routing system, so it not only provided for forward secure end-to-end encryption, it is aattempted to also hide the information of who is talking to whom (so-called metadata) rather than just the contents.

Encryption in federated PSYC1

We employ TLS with a subset of ciphers in PSYC circuits as described in Spec:Circuit. We recommend users to use OTR in their clients, using any access protocol such as XMPP, IRC or native PSYC. Still, federated encryption does not protect your metadata, so we recommend you to support the development of PSYC2.

Perfect forward secrecy

Some TLS ciphers - namely all using DHE (Diffie-Hellman Exchanges) - are capable of achieving perfect forward secrecy. If you don't use them or communicate with a server that does not offer them, your traffic may be decryptable retroactively should anyone break into your server and get its keys.

• SSH and OTR provide PFS.
• PFS is an optional feature in IPsec (RFC 2412).
• PFS is also optional in TLS, but unfortunately modern web browsers by default do not show whether they employ those ciphers or not.
• Some pseudonymous routing technologies still do not implement DHE!

Forward secrecy is usually a problem when sender and recipient aren't online at the same time. The usual strategy to circumvent that is to maintain the DHE state as shown by modern implementations such as Axolotl.

Transport Layer Security (SSL/TLS)

All access protocols can either switch to TLS encryption, or there is a specific access port which supports it from the start. The XMPP protocol suite uses SASL to negotiate TLS. psyced currently prefers to use TLS immediately in order to reduce latency and autodetect TLS on incoming sockets.

A bad aspect about TLS is how web browsers expect you to trust several dozen certification authorities even to the point of them updating any website's certificate without you being notified about it. This is impractical, as any government might read in on your https: communication simply by doing a man in the middle attack using on-the-fly generated fake certificates signed by any certification authority that handed over its private key to such government agency. So essentially https: is unsafe if any government in the transit route of your communication has an interest in reading in on it.

As a side note, see also OCSP on certificate revocation notification and its imaginary relationship to PSYC.

Also, to improve your web browsing safety, have a look at Certificate Patrol add-on for Firefox.

A way to use TLS properly and safely for PSYC1 could have been to implement it yourself in client and server, ensuring that you don't use any public certification authority, but rather somehow employ the PSYC web of trust or any other trust mechanism you feel comfortable with, and additionally ensure that only PFS algorithms (described above) are employed. Update 2016: With GNUnet, PSYC2 is throwing this entire TLS/X.509 architecture to the bin.

One more problem about TLS may be how it is not designed to handle N to N host names on a single TCP line. You only get one certificate, which at best contains several host names or host masks. You can't negotiate for further host names dynamically, you can't throw new certificates into the mix of an existing connection. The new specification expects all host names to be defined in that single certificate, meaning that we need ways to frequently upgrade certificates to reflect changes in the host alias configuration of a server.

Not talking about deployment issues if there isn't a clear strategy in place.

In other words, it's tricky to have true privacy based on TLS. It's a toolbox that can work, but you have to know it very well and force it to.

Secure Shell

psyced is frequently used with an IRC or telnet client on the same host (your server somewhere on the Internet), and instead connecting to this server via the SSH protocol. This choice also provides perfect forward secrecy but you need to fully trust your server.

Looks like SSH is in some aspects a safer encryption choice for TCP sessions than TLS.

Pretty Good Privacy

<lynX> For reasons that the OTR documentation explains finely I recommend not to move further on PGP. PGP does not provide forward secrecy. More reasons not to get started with PGP are available at http://secushare.org/PGP

S/MIME

S/MIME sucks because it also depends on the corrupted X.509 public certification infrastructure. We don't do this.

Off-The-Record Messaging

Until PSYC2 is around, which is natively end-to-end encrypted, you can use OTR over psyced.

OTR was great. I hope you know about OTR. If not, go read about it. Should you prefer an audio introduction to OTR rather than reading the website, we have made a convenient mp3 of Ian Goldberg's OTR talk published at Waterloo University, Canada. The video is less useful as the slides are unreadable, but the lecture is fine to be listened to as a radio show. So instead of downloading 460 megabytes, take eleven. Personal use only, copyright remains with uwaterloo.

OTR has two requirements which are worth mentioning:

• The underlying protocol should respect order of messages. PSYC over TCP does that, but when using UDP there is a very unlikely chance for packets to not arrive in order. We currently aren't using UDP PSYC for real messages, anyway, so there is no problem.
• OTR can only operate in real-time while both parties' OTR applications are online, so it doesn't work for asynchronous communications, like leaving a message, an e-mail or a file.

What's different with OTR?

• OTRv2 no longer throws away MACs after each and every message, so let's hope it's not such a performance brake any longer.^((s))
• They have a brilliant new thing called socialist millionaire protocol which replaces checking each other's fingerprints at the beginning of an encrypted friendship with simply having any free format string agreed out of band.
• They are thinking about how to apply OTR to chatrooms in more than just one way, since different semantics may be favorable in different situations - So we can expect more useful tools from them in that area.

Nice try: Somebody tried to write a Man in the Middle attack module for OTR. Even with the old version using fingerprints, it only works if people are lazy enough not to check them. But since the invention of the socialist millionaire protocol the OTR software itself can tell when somebody is trying to trick it.

OTR runs on the PSYC backbone using its regular ASCII encoding. See http://www.cypherpunks.ca/otr/software.php for a list of OTR-enabled Jabber and IRC clients such as pidgin, psi and irssi. Dyskinesia also supports OTR, natively via PSYC.

One uncool aspect about OTR is, by being transport agnostic, how it ignores delivery errors and collides with people switching client applications on the fly: If your smart phone takes over your communications (because you are leaving home) it will receive encrypted OTR packets out of the blue which it cannot display and the sender will believe you are actually receiving these messages as there is no support for acks or echoes.

Multicast cryptography

How can you have an encrypted conversation with several recipients? You can either defy multicast, encrypt your message for every recipient, then unicast it to them. Or you can use multicast, requiring you to create a symmetric key for the context at hand, and distribute the key to all participants. Let's look at the latter option.

To implement this we need the context master (the place program, in PSYC1 that is ideally on a stand-alone PSYC server – with PSYC2 this is a volatile role in conference control) to be able to generate keys and to send them to all participants in unicast, encrypted to their personal public keys. This is a rather costly non-multicast operation that doesn't scale too well, but it still scales better than doing this for every single message, which was the other option.

From then on, every participant can encrypt their messages to the common key of the room and let PSYC multicast it to all participants, so the context master no longer has to do any crypto maths.

Would be even better if the context owner was generating and distributing the symmetric key on her local device so the distributing servers do not need to know the symmetric key at all.

In special cases you may want to regenerate the symmetric key. I would not presume that this is always necessary, even when a participant got kicked, but leave it to the room administrators to choose or manually trigger such a /rekey operation. Also consider this constellation for friendcasting operations such as microblogging and activity streams.

See Crypto sharing on implementing this.

Tree-based Group Diffie-Hellman

Researchers at Ruhr-Universität Bochum have come up with a cryptographic multicast algorithm called TGDH. Go ahead and study the work: Secure Multicast Chat Plug-In for Lucane Groupware. I didn't think we'd need something so complicated, but.. why not?

Multiparty OTR

Similar proposal from the developers of OTR, http://www.cypherpunks.ca/~iang/pubs/mpotr.pdf

Old outdated information on cryptography has moved to Archive:Encryption...