echoplexus and PGP
Originally published on 2014–03–05.
I’m happy to announce that PGP is ready to use on echoplexus. There may be a few user experience bugs (awkward visual appearance).
Preface: As always, don’t trust echoplexus with your life. I am just one person, and it would be irresponsible of me to recommend it as a serious cryptosystem. You should feel more confident that your messages are not being intercepted, but don’t let your guard down.
Why a shared secret was not enough
echoplexus has long supported the use of symmetric cryptography (AES). This allowed you to share a secret passphrase with friends, encrypt your chat for transit, then decrypt messages when they arrived, all using the same passphrase. Simple and elegant, it just works.
There are certain aspects of symmetric cryptography that are not desirable:
- Users are forgetful: If you forget the password, then you can no longer partake in the chat
- Users aren’t security minded: If you’ve forgotten the password, then you might be tempted to simply ask, “What’s the password?” via Google Chat or another channel. However, this is far from secure, as you’ve now transmitted your shared secret over an unsafe channel! Now, anybody could intercept your communications and decrypt them using the password you unintentionally gave them.
Symmetric key cryptography is fine if you can easily get together to share a password that all will remember. However, users often have trouble remembering their own passwords, let alone a password complex enough to protect them. Thus, symmetric key cryptography is not enough!
Identity in a distributed system
Eventually, echoplexus will be a distributed application. Right now, the server is 95%~ router of messages and 5%~ message interpreter (website screenshot-ing, GitHub webhook integration). However, establishing an identity on echoplexus in a distributed environment would have been impossible as soon as it became a node of a distributed message routing system.
In echoplexus 0.2.3, to identify yourself as Alice you had to tell the server a passphrase. The server would consult its records, and if it matched, it would assume that you must be Alice because you had her passphrase. The implementation details are glossed over, but this was essentially the basic scheme. In a lot of ways, this mirrored nickserv for those of you familiar with IRC.
This scheme would go out the window in the face of a distributed environment. The server held all the power in identifying users. What’s to stop a server operator from impersonating Alice? If a node in the echoplexus network relayed a message to a malicious node, nothing could stop the malicious node from changing the contents and rebroadcasting the message!
What we really need is a method for Alice to prove to Bob that she is indeed Alice without needing the server to act as a middle man, since we’ve established that it cannot be trusted. The ultimate goal is to make echoplexus into a secure system that even I, the creator, cannot manipulate for personal gain.
PGP, to the rescue!
So, Alice creates 2 keys. These form her keypair. One is a public key that she freely shares and advertises to others, the other is a private key that she guards with her life. She can even passphrase protect her private key, so that if her computer is stolen it would be difficult for somebody to impersonate her — they’d have to crack that password.
With the private key, Alice can sign a message. Bob uses Alice’s public key to verify that the message was actually sent by Alice. If the signature checks out, then Bob can be almost confident that the sender of that message was actually Alice.
The server has no knowledge of Alice’s private key, so it cannot meddle with the message contents without causing the signature to fail. Upon seeing a failed signature, Bob is alerted that there may be an interloper.
If Bob and Alice trust each others public keys, then they can begin to encrypt messages to each other. Alice encrypts her message using Bob’s public key, and Bob decrypts the message using Bob’s private key. Inversely, for when Bob wants to send Alice a message. The private key never leaves the safety of your computer, but now we’re transferring encrypted information without the burdens that sharing a secret brings.
I’ll highlight some of the use cases I see for using PGP to sign and encrypt messages in echoplexus. I’m very excited about the possibilities.
Ephemeral linked anonymity
Sometimes, you may want to share an opinion without putting a name behind it. Many sites support creating as many accounts as you like, but with each post you leave, you leave behind a trace of your history. Further, the username you choose can betray information about who you are.
I’ve always admired 4chan’s user model: uninhibited anonymity. The thing missing in many web services today is linkable pseudonymity. This is something 4chan accomplishes well via tripcode; if the original poster of a thread did not use a tripcode, then it would be impossible for him to later identify himself in a follow-up post. A nickname is never sufficient for identity since most users are simply “Anonymous”.
Using PGP on echoplexus, you could create as many throwaway keypairs as you like. When you want to tell an enduring multi-day narrative, you can simply choose a new 1024-bit keypair, ignore the passphrase, and start typing.
Users can click on the key icon beside your name to mark that public key as trusted. They’ll see a green lock icon beside your name, along with the fingerprint of the key. Every message is sent with a fingerprint, a unique property of the public key. Thus, the next day, they can be sure that they’re talking to the same person they were talking to yesterday.
All this, and you didn’t even have to change your name from “Anonymous” or supply an email and sign up to create this enduring identity.
Persistent linked identity
Other times, perhaps with a group of friends, on Twitter, on Facebook, you want to have a persistent linked identity. In this case you might choose a stronger key, perhaps protecting it with a passphrase, put in your real name and email, and begin to publicize your public key’s fingerprint. Then, you can continue to use this key until you believe it to be insecure or get tired of it.
Here’s how echoplexus uses both symmetric and asymmetric cryptography:
- An orange key represents a neutral state
- A green key represents trusted
- A red key represents untrusted
- Click a key icon in the user list to toggle trust status, see the messages they’ve sent update
- You can toggle message signing on and off. Turn off PGP temporarily, and re-enable it later. It’s stored in localStorage so be careful not to lose it!
- You can use multiple keys for identities across different channels
- You can encrypt a message using others’ public keys, as long as you mark their public key as trusted (green). When you toggle on PGP encryption, any future messages sent will be delivered to only those keys. Only they will be able to decrypt it. If you’re chatting PGP encrypted with 5 people, then all 5 will receive their own encrypted version of the message. Echoplexus handles this transparently, behind the scenes, for a nice user experience.
- You can use a shared secret as well, which will wrap your PGP messages in another layer of encryption. This is useful when already using a shared secret, but not everyone is necessarily using a PGP keypair: you can still encrypt your signed messages with some level of protection, albeit weaker.
- Your PGP public key and fingerprint are always distributed in plaintext, regardless of the shared secret. Please be careful if you put identifying information into the Name and Email fields!
I hope that explains everything :)