Encryption

The PSYC protocol syntax allows for encrypted contents in messages, additionally the decentralized structure of PSYC allows not only for client-based encryption applications, but also to have servers interact in protected communications. See also SILC for a chat technology with focus on cryptography.

Contents 1 Encryption in PSYC 2 The Political Issue of Cryptography 3 Perfect forward secrecy 4 State of the Art 4.1 Transport Layer Security (SSL/TLS) 4.2 Secure Shell 4.3 Pretty Good Privacy 4.4 S/MIME 4.5 Off-The-Record Messaging 4.6 Encrypted Session Negotiation 4.7 One-Time Pad encryption 5 Where is PSYC heading? 6 Multicast Cryptography 6.1 Tree-based Group Diffie-Hellman 7 Identity Protection 8 Futures 9 Thoughts 10 Some related things 10.1 Pass phrase management in the browser 10.2 Certification authorities spoofable by intentional ḾD5 collisions 10.3 Hacks concerning https

Encryption in PSYC

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. Reasons for these choices follow.

The Political Issue of Cryptography

A chat should never turn against you in court. If using crypto makes you liable for everything you say, you may not want to use it, or you may want to use OTR (see below), as the developers have spent a lot of thought on the political, moral and legal implications of cryptography. We're keeping our eyes open for options and alternatives.

<chill> Ask not what you can do for your country; ask what your government is doing to you.

<Kol_Panic> Considering the unexpected uses that services like Twitter have been put to, we should plan on introducing PSYC 1.0 with a pathologically paranoid mode.

Perfect forward secrecy

Some TLS ciphers - namely all using DHE - 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. Firefox says it is using AES256-SHA in most cases, which as such would not provide PFS, but it seems to be using DHE-RSA-AES256-SHA in fact, which is a very fine choice for a cipher. You need to test it out by yourself to be sure.

State of the Art

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 Jabber protocol suite uses SASL to negotiate TLS. psyced currently prefers to use TLS immediately in order to reduce latency.

On TLS and PFS Mike says

RSA key exchange provides up to 368 bits of security, but doesn't provide forward secrecy. If I want forward secrecy, then I need to use Diffie-Hellman. A server that has 1024-bit Diffie-Hellman parameters only provides me with somewhere in the neighborhood of 70-80 bits of security (extrapolated from the data in RFC 3526). You are saying that I am a "keylength fetishist" because I want better than 70-80 bits of security? So I'm allowed either lots of "strength" *or* forward secrecy, but not both? That's irresponsible.

Another 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.

Fefe reports

In the wake of the Debian weak key issue it was revealed that whitehouse.gov had a weak key. It turns out that the Akamai SSL key is also weak. Akamai, in case you never heard of them, is a major content distribution network. They have tens of thousands of servers distributed over the world. If you have a high traffic web site, you can contract with them, and they will host it and redirect visitors to the site closest to them. Their customer list includes Microsoft, the New York Times, and -- particularly interesting for this -- ATI's driver downloads. Akamai obviously replaced their keys immediately. BUT. If you were quick enough, you could get their old public key (it is sent as part of the SSL handshake), and since the private key is weak (there are only 32k possible keys), you can generate the private key to it. Someone did (who wishes to remain anonymous) and sent the key to the CCC. I verified it. The key works. The part that has not sunk in yet for most people is: the public key is signed by a CA that browsers trust. I have a public key and a private key. I can now impersonate Akamai. If I can manipulate your TCP connection (which is easy, for example, if you are using Wifi or are on the same LAN with me), I can send you malware instead of the ATI driver. SSL has two defenses for this. First: keys expire. This particular key expires October 2008. Second: Certificate Revocation Lists. SSL originally had the idea that CAs would publish a list of compromised keys, and as part of the SSL handshake, the browser would check if the key is on the list. The problem is: that does not scale. At all. There are billions of SSL connections being established per second, Verisign can not possibly pay for the traffic to send their list to everyone. So -- noone checks the CRLs. This is the main reason why PKI does not work in practice. One more thing: I'd like to stress that Akamai did nothing wrong here. They did everything right and still have a problem. The same problem occurs if someone gets the private key by some other means, for example breaking and entering. The foundation upon which we build our infrastructure is less stable than most people realize.

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.

The only way to use TLS properly and safely is 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.

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

There is a specific _notice_private_encrypt_gpg (why gpg? shouldn't it be openpgp or at least gnupg? _notice is wrong too, see also Method Naming) method which transports ascii encoded pgp data from jabber into PSYC. Nei says his irssi can handle that. PSYC doesn't generate such messages as yet.

<lynX> For reasons that the OTR documentation explains finely I recommend not to move further on PGP.

S/MIME

Nothing done here. Is it politically okay to send encrypted messages without signing them? Hope so. One way or the other, S/MIME should be embeddable into PSYC - we just have no specific methods or anything for now. Make some up. That's what method inheritance is for.

<lynX> Presumably same problem as above with PGP.

Off-The-Record Messaging

OTR is 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 new 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 stupid 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.

Encrypted Session Negotiation

Ian Paterson has provided XMPP with several extension protocols, XEP-0116, XEP-0200, XEP-0217 and XEP-0187, which are directly inspired by OTR, and thus semantically very similar. XEP-0188 explains the maths behind things and gives OTR proper credit for its pioneering work. Let's abbreviate Encrypted Session Negotiation by calling it ESN here. The main differences to OTR are:

• ESN uses an XML-based protocol embedded into XMPP rather than something independent from transport medium like OTR. This may or may not be seen as cleaner, but that's certainly just a belly feeling - technically the overhead of using XML and no binary data makes these XEPs just as inefficient encodingwise as OTR.
• ESN has this 187 extension for leaving encrypted offline messages. It's a hack, but it's better than nothing. OTR has no such offering yet. This is a major cause for headache, as not being able to leave a message is very annoying. Probably the only real solution is to never log out and redirect your OTR messages to your mobile communicator instead. You should have a mobile phone you can trust, anyway. This is a separate problem which can be best addressed by an open-source mobile phone.
• While OTR currently only encrypts normal message body text, ESN can be applied to XML, thus encrypting richer data formats, like all the details of a presence packet. Unfortunately presence normally needs to be delivered by multicast to be scalable, which has encryption requirements not covered by neither ESN nor OTR (see further low for multicast encryption).
• More improved details that we overlooked.
• While OTR was designed by a cryptography professor, ESN is still in need of review. stpeter says "we basically can't get ESessions reviewed, which means we're flying blind to a large extent."
• Is there any implementation out there? Edit here.
• It's XMPP-centricness is somewhat limiting. However using PSYC's ability to deliver arbitrary XMPP packets, ESN should also work using ESN Jabber clients connected to psyceds in theory.
• According to the XEP, ESN is apparently designed to work together with OTR somehow, or to be able to carry it. It's not entirely clear.
• ESN also provides support for backdoors for legal reasons. That's not a nice thing to offer, then again - better to be warned of disclosure rather than to have no choice. Still, providing a disclosure flag will only help you in cases where the other side is willing to let you know about it. Finally, the OTR algorithms provide deniability, so if ESN correctly adapted the OTR principles, the disclosure of communications should be of no legal value and thus irrelevant as it could be purely fictional content.

One-Time Pad encryption

As implemented by http://pidgin-paranoia.sourceforge.net – this scheme generates one time encryption keys and requires you to install them manually on the communication partner's machine (transferring it by USB key or something), after that you can exchange a predefined number of messages, each encoded to a one time key, thus extremely hard to crack. Not very practical though. See also https://cryptoanarchy.org/wiki/One_Time_Pad

Where is PSYC heading?

OTR is already very popular, in particular with the AIM/ICQ crowd. It is a good idea to start out with OTR (Dyskinesia implements that over PSYC for example), then there are some possible refinements:

• Both OTR and ESN protocols can be adapted for native PSYC encoding. This means that all binary data is actually delivered as binary, reducing the overhead of encrypted communications a lot.
• In both cases those encodings could be converted back to regular OTR or ESN if either legacy clients or networks require so.
• It's not a priority, it's a nice-to-have, unless we start to do some traffic intensive application with it like telephony.

But what is really interesting is to apply end-to-end cryptography to the entire PSYC packets (except for the routing layer). Having a native OTR-like encryption would also allow for better signaling (like re-encrypted echo to ensure the recipient really received a message). Also a really hot topic is the following:

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, possibly on a stand-alone PSYC server) 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 costy 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 her 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?

Identity Protection

First of all, a passphrase should never be stored anywhere - making the private key usable is the job of the client. If we were to do server-based encryption in psyced, we could still let the final step be taken in a client - be it a web browser or a PSYC client. Ok, with the web browser it gets a little tricky.

Splitting identity is also a good plan (as suggested by el): You pick one server to hold your UNI for receiving messages, as always, but you also allocate an account on an alternate (secret) server, which only serves as to provide the PSYC client with private key and key ring. The client logs into both of these UNIs using the link procedure optionally enhanced by TLS, retrieves the messages from the first and the keys from the second (see Storage), then asks the user for passphrase and off you headstart into crypto communications.

Futures

See Software Projects for the idea of creating a Crypto Chatroom Server.

Thoughts

11:51:10 lynx sagt: hmm... userfreundlichkeit und cryptographie... das widerspricht sich ja oft
11:51:34 lynx sagt: ein gedanke: wie kann man es anstellen, dass ein user sich an einen blitzeblankneuen rechner setzt
11:51:46 lynx sagt: ne software aus dem netz zieht und seine alte identität annimmt
11:52:00 lynx sagt: es ist den usern nicht beizubiegen, dass sie den private key selbst aufbewahren müssten
11:52:18 lynx sagt: also könnte man nur sowas machen wie den private key per passphrase geschützt auf dem eigenen server unterzustellen
    kuchn broeselt: wie waers, wenn clients aes/rindjael implementieren und der verschluesselte key so gespeichert wird? psyc bietet
                    doch ein storage-feature.. der admin des servers sieht da dann nix vom schluessel, der trotzdem
                    jederzeit ueber ein passphrase zum client des users kommen kann, waehrend der oeffentliche ueber
                    psyc von jedermann abrufbar sei.
    kuchn broeselt: aber fuer raeume, da ist asymmetrische verschluesselung doch nicht wirklich passend;
                    im kontext sollte dann wohl eher simmetrisch, da ist ein regelmaessiger keychange einfacher;
                    und dieser key koennte ja am server mit dem public key eines partizipierenden users verschluesselt werden..
                    (ersetzt diffie hellmann) just an idea..

Some related things

• Darknets

Pass phrase management in the browser

This is an interesting trick that the freenigma system apparently implements. To make encryption for end users easy, they keep keyrings and secret keys on the server side. Still they manage to not store the pass phrase on the server. The pass phrase is applied to the secret key in the browser, making the data unusable to freenigma should a ever ask them to release their data. Unfortunately this isn't exactly true, as the browser still submits the passphrase to the server which then decodes the private key with it. So all an external force has to do to get to the identities is modify the process to log the passphrase.

Certification authorities spoofable by intentional ḾD5 collisions

As presented at the Chaos Computer Congress 2008:

Hacks concerning https

• sslstrip as presented at blackhat 2009.