1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
:textile
h1(first). Small messages, big hearts
Short messages and chat have proven to be indispensable tools for mobilization for activists around the world, particularly on mobile devices. Unfortunately, very few options exist that are both secure and easy to use. Even solutions that people rely on for high security, such as OTR, are vulnerable to association mapping and do not work with asynchronous communication (where both parties do not need to be online at the same time).
Experimental secure peer-to-peer messaging does exist, but adoption rates have been low because these protocols are incompatible with existing message networks and typically require both parties to be running the application at the same time. When asynchronous messaging is supported, it is slow and lacks the reliability users have come to rely on.
h1. Secure and federated chat
The LEAP approach to instant message and chat is to build on stable, federated chat technologies and add support for greatly enhanced security. The goal is to allow users to communicate with existing messaging networks, as well as enjoy a higher degree of protection when communicating with networks that support the enhanced protocols.
h3. Open protocols, improved
The primary open protocol for chat is called XMPP. It provides a good foundation for federated chat, but it is sorely lacking key security safeguards and standards for asynchronous messaging. Our additions to XMPP address these limitations:
*Secure identity:*
*Client-encrypted cloud data:* Chat applications work much better with a cloud component. For example, this allows you to have the same roster, chat history, and account information on all your clients. There is currently no provision in XMPP for client-encrypting this data. We will create one, and implement it on the client and server.
*Asynchronous messages:* Currently, patchy adoption of different methods of handling offline messaging result in confusing situations where you often have no indication if a message will be delivered to its recipient or not.
*Anonymous rosters:* XMPP requires that the server is aware of your list of contacts. This part cannot be client-encrypted, but it can be made highly resistant to association mapping by adding one-time aliases. If a friend on another server wants to add me to their roster, I will give them a unique alias for my actual chat address. Only my server will know that the alias belongs to me.
*Secure groups:*
*Required TLS:* As with email, there is no mechanism in XMPP for requiring TLS (the server can advertise that TLS is required, but this is easily thwarted by an attacker). We will add one.
|
