Commit 9563593d authored by David Goulet's avatar David Goulet
Browse files

Add a habu posts repository for backup

Signed-off-by: default avatarDavid Goulet <>
parent 66e50e51
Title: Chatifesto
Slug: New chat paradigm
Date: 2014-08-31 14:15:00
Author: Elijah/
This Chatifesto has been written by Elijah from the wonderful project.
Old chat, new chat
The model of chat popularized in the 2000s was simple but useful: you had a client that listed your online contacts, and you could chat with them in real time if you were both online.
The protocols that emerged in this period, such as XMPP and OTR, had this model of interaction in mind when initially designed.
Since then, a new type of chat has started to rapidly overtake old chat. This new chat allows one to switch smoothly between synchronous and asynchronous communication. If you send someone a message with new chat, you have a very high degree of confidence that they will get it eventually, and not get lost when they turn off a device without reading it or silently bounced because they were not online at the moment. New chat is more media rich, allowing images and video inline. New chat promises that your data will be available, you can switch from device to device without losing messages or worrying about where they are stored. New chat is sometimes transport agnostic, switching between data or SMS as available. With new chat, it is often super easy to create new invite-only groups by listing a few of your contacts and sending a message. New chat often allows you to use mobile, desktop, or web clients.
New chat is not simply old chat with better features. It is a distinct and, in most cases, simplified user experience. People communicate differently with new chat. Most importantly, old chat is declining rapidly as new chat expands rapidly. We need to update our approach to securing chat to be compatible with a new chat model.
The goldilocks architecture
There are three possible architectures for a message system: centralized, peer-to-peer, or federated.
In a centralized model, all messages are passed through a single organization. Typically, everything works and is easy to use, but the user loses control over their data and must entirely place all their security in the hands of the central authority.
In a peer-to-peer model, all users communicate directly with one another, cutting out the dependency on an authority. This comes at a cost: peer-to-peer system are more difficult to use, the data is less available when you want it, they don't work well on mobile devices or with intermittent network connections, and authenticity becomes much more challenging to establish. Experience has shown that when authenticity is difficult, most people don't bother, thus greatly undermining the security of the system as a whole.
In a federated model, messages are passed from a user to their provider, relayed to the recipient's provider, and then finally to the recipient. A federated model is halfway between a centralized model and a peer-to-peer model. There are still authorities, but the user is free to choose whichever one they want, and they can later switch if they so desire. The user is not completely autonomous, but they still have control over their data.
Centralized models should be abandoned as quickly as possible. They are easy to implement, but are dead end streets. Once upon a time, nothing on the internet was centralized. The last decade has seen the rise of centralized platforms, but it is likely they will not stand the test of history once open protocols are mature enough to catch up in terms of ease and features.
Peer-to-peer models are perhaps the future, but the far future. There are serious and difficult problems intrinsic to peer-to-peer approaches that are unlikely to be solved any time soon, such as authenticity, availability, and resistance to traffic analysis.
Federated models represent a goldilocks middle ground between centralized and peer-to-peer. Federated approaches have the potential to allow us the availability and user friendliness of centralized systems while also retaining a large degree of control and freedom concerning our data.
Some might say that federated systems are not that different because they still rely on the central authority of the root DNS zone. This authority is very different than other forms of central authority, because the actions taken by the root DNS zone are necessarily visible and auditable by external observers.
To the moon
Federated secure chat is like the moon landing. It is interesting in itself, but mostly the benefit comes from all the positive externalities that come from solving the problem of getting to the moon.
Chat is centrally situated in the world of secure communication, and touches upon nearly all the interesting and hard problems we must eventually tackle in order to achieve communication security.
For example:
* automatic authenticity. the problem of authenticating the identity of other users is incredibly important, because all other security properties depend on it. the only proven models that are easy enough for wide adoption are centralized. if we don't create a federated system of authenticity that is easy to use, we will be creating secure system with a huge vulnerability: human error in validating public keys.
* cryptographic groups. what constitutes a secure group, what does membership mean, who controls a group, how do we adapt public key cryptography to groups, how do we negotiate a session key in a group? these are core questions which must be answered for any secure communication that is not strictly one to one.
* federated storage. chat is media rich, so we have to tackle how we can do secure cloud storage, not tied to any one provider, that you can grant specific access to particular media assets.
* secure routing. metadata must be regarded as extremely sensitive information. it is a detailed blueprint of how you interact with society and is often far more revealing than content. what the NSA can do today, repressive governments will be able to do tomorrow.
Chat is flexible
Short messages can be incredibly flexible and lend themselves to many different idioms and patterns of communication.
The core of the XMPP chat protocol is not complex, but it lends itself to a lot of possibilities. People use XMPP not just for chat, but to control servers, transport data for multi-player games and real time document collaboration, implement a follow/subscribe model like twitter, or a friend update model like facebook. Chat is also a particularly good session negotiation protocol for audio and video conferencing.
Solving the problem of secure chat does not simply mean we have secure chat. It means we are very far along the road to also creating secure federated social networking, secure document collaboration, and secure notification.
The holy grail
Our broad goal is secure and easy to use chat that is always available, works across all your devices, and where you don't have to worry if the people you chat with are online or not.
In slightly more detail, this means:
Client encryption: The content of every message (or other stanza) from one user A to user B must be encrypted on the client device of user A and decrypted on the client device of user B.
Offline messages: Every server must be able to receive offline messages on behalf of a user, and forward these messages to the user's client when they next appear online.
Automatic authenticity: The user's client must attempt to automatically validate the public keys of other users. If the client is unable to do so, it must indicate this visually.
Groups: Every client and server must support encrypted multi-user chat. Access to group chats should be granted by one of the following: invite, membership in a pre-defined cryptographic group, or open to anyone.
Device portable: The user should be able to communicate via multiple devices, on any platform, without losing messages. The protocol must be able to function well on mobile devices with spotty network and limited battery.
Secure routing: The user should be protected from analysis of their associations and pattern of message traffic.
Transport encryption: Both clients and servers must require transport encryption of the communication stream using a cipher with forward secrecy. This includes client to server and server to server communication.
Easy to use: The client must be auto-configuring based on the information advertised by a service provider. The client should provide some visual confirmation that a message has been received by recipient server.
Media encryption: Any documents and other media attached to a chat message should be encrypted using the same access controls as the message itself.
Secure storage: Any user data (such as logs, roster, keys, etc) saved locally or synced by the client must be client-encrypted.
These would be really nice, but may be very difficult in the near term:
* Ideally, the server should not know the list of contacts (roster) of a user.
* Ideally, the server should not know the membership list of a particular group.
* Ideally, the server should not know whom you communicate with.
Although these are nice, we are not trying to achieve any of the following:
* direct file transfer from one client to another
* direct peer to peer messaging without server relays
* support for gateways to other chat protocols or SMS
* session encryption -- possible to get forward secrecy and deniability. Group session negotiation is experimental and slow.
* object encryption -- possible for parties to communicate asynchronously (i.e. while only one party is online).
* hybrid approach -- long lived session keys that can be used for online communication, or forward hashes of these keys (so keeping the key around does not make past conversation vulnerable).
Session encryption provides the highest security, but we also need the ability to support offline communication. Object encryption could be paired with transport that was forward secret to obviate some of its security problems (although not against an attack from the provider).
There is interesting research in optimizing group session negotiation, but not much code.
Secure routing
By secure routing, we mean that the "from" and "to" information of every message or stanza should be protected from association analysis by servers that relay messages.
Some ideas to protect the routing information:
* Auto-aliases: Each party auto-negotiates aliases for communicating with each other. Behind the scenes, the client then invisibly uses these aliases for subsequent communication. The advantage is that this is backward compatible with existing routing. The disadvantage is that the user's server stores a list of their aliases. As an improvement, you could add the possibility of a third party service to maintain the alias map.
* Onion headers: A message from user A to user B is encoded so that the "to" routing information only contains the name of B's server. When B's server receives the message, it unwraps (unencrypts) a supplementary header that contains the actual user "B". Like aliases, this provides no benefit if both users are on the same server. As an improvement, the message could bounce around intermediary servers, like mixmaster.
* Third party dropbox: To exchange messages, user A and user B negotiate a unique "dropbox" URL for depositing messages, potentially using a third party. To send a message, user A would post the message to the "dropbox". To receive a message, user B would regularly polls this URL to see if there are new messages.
* Mixmaster with signatures: Messages are bounced through a mixmaster-like set of anonymization relays and then finally delivered to the recipient's server. The user's client only displays the message if it is encrypted, has a valid signature, and the user has previously added the sender to a 'allow list' (perhaps automatically generated from the list of validated public keys).
Title: Debian OTR team
Slug: debian otr
Date: 2014-04-27 14:15:00
Author: Debian OTR team
Today we launch the Debian OTR team. OTR stands for "Off-the-Record" messaging which provides encryption, authentication, deniability and perfect forward secrecy. The team was started by various maintainers of software that feature "OTR" support. OTR is used for instant messaging. It adds an encryption layer over existing instant messaging protocols like Jabber and IRC and is implemented in several instant messaging clients, which we aim to support and maintain in Debian.
In a post-Snowden age, it is important that Debian provides encryption to those who want to protect their communications. OTR is one of the protocols that is relatively easy to use for end-users. Its end-to-end encryption makes it harder for attackers to decrypt the communication between two parties.
The Debian OTR team is supported by, a community of OTR developers, whose aim it is to work effectively together, peer-review each other's work and encourage people to step in and work together on the OTR ecosystem and OTR upstream.
Now for the burning question, how can you contribute? We welcome any contribution! From bug reporting and triaging, to bugfixing, packaging and backporting. We will help newcomers if needed and are very grateful for your contribution!
You can find the Debian OTR homepage with all the information on how to get involved: [here](
Title: Launch of
Slug: Let the ecosystem bloom off-the-record
Date: 2014-04-27 14:00:00
[]( was started to strengthen the OTR community by providing a hub where developers can find each other, improve their respective projects and contribute to the OTR community.
[Libotr]( is now accessible using a new [bugtracker]( This bugtracker is a new place for contributing to the reference implementation, libotr.
We also want to provide new and/or existing projects with hosting, i.e, giving them access to the bugtracker and git repositories. As of now, along with libotr, the pidgin-otr plugin is also hosted there.
However, is not a replacement for [](, it is merely an addition to the community as a whole and a way to do the project hosting.
There has been increased interest in OTR and [mpOTR]( the past few months. In April 2014, the [Debian OTR team]( has been announced. Furthermore, a group of cryptographers and developers is working on an mpOTR specification, which would allow more than 2 people to chat with each other using end-to-end encryption.
This initiative was brought to you by the [useotr]( folks, who are dedicated to strengthen the OTR ecosystem and bridging gaps between users and developers.
Since Snowden's revelations have been published the need for secure end-to-end communication has become clearer. We aim to help out with providing that. In collaboration with the libotr authors and the various implementation developers.
Last but not least, [get involved](
Title: Debian OTR team featured on LWN
Slug: LWN
Date: 2014-04-27 16:00:00
[Linux Weekly News]( featured the Debian OTR team this week. Check it out.
Title: mpOTR progress report - HOPE X in New York 2014
Slug: hopex mpotr
Date: 2014-07-25 00:00:00
Author: dgoulet, infinity0
- trevp
- infinity0
- DrWhax
- dgoulet
- vmon
This is a progress report on the ongoing mpOTR effort after a meeting at the
HOPE X conference in New York.
First of all, the name of the protocol has not been yet decided thus we'll use
mpOTR in this report so everyone understand what we are talking about.
This initiative was launched by CryptoCat and in early 2014 with the
help of OTF for the funding. You can find an overview of the project here
[mpOTR]( Quite
of work has been put into this new protocol and a second draft of the mpOTR
protocol should be release to the public soon.
Now a quick summary of what we discussed. It is divided into roughly two parts,
the key agreement to establish the session, and mechanisms to ensure transcript
consistency during the session. The key agreement can itself be thought as a
combination of a forward-secure confidentiality key agreement, and a deniable
authentication key agreement.
Unlike OTR which is a bidirectionnal data exchange, a cryptographic agreement
between all parties need to be established before having a group chat secure
channel. There are multiple methods to achieve that, such has having each
participant broadcasting her/his key ("sender keys") or using a common key for
the whole chat session ("group key"). It's also important to consider the
transport protocols that support group chat such as IRC and XMPP; these all
have different semantics for reachability, presence, delivery and so on. In
order for mpOTR to be transport agnostic, we need to assume as little as
possible about the transport, and/or think about how to adapt the semantics we
choose for mpOTR, into the semantics of each transport.
mpOTR will most likely introduce new properties on top of the secure channel
that make sure the transcript between all participants is ordered and
consistent. This is to prevent an insider attacker that decides to send
different information to different people in the group chat - this would be as
disastrous as a non-secure communication channel. I won't go into any more
details but I encourage you all to read infinity0
So back to the HOPE X meeting. The discussion was aimed at trying to get to an
agreement between attendees mostly on two aspects, which key agreement scheme
to use and the transcript consistency property. I'll describe what they are
briefly here but will not go into deep technical details since no decision have
been made.
As mentionned before, there are multiple key agreement scheme that can be used
but there is still a debate on which one to use in mpOTR, sender keys or a
common group key. Each of these have advantages and disadvantages, but details
are being worked out to decide which one the next draft will follow.
For the transcript consistency, the discussion was mostly about the performance
overhead of the scheme described
and whether simpler schemes achieve security guarantees that are strong enough.
Again, I'm not going to go into more details since I feel that this would need
its own blog post/paper and the goal here is to show what's being worked on
right now for mpOTR.
As I said, the second draft will be release soon (hopefully with an official
name) which you, the public, should bring a HUGE amount of scrutiny to it and
we can finally move to an implementation! :)
Title: Release of libotr 4.1.0 and Pidgin-OTR 4.0.1
Slug: libotr 4.1.0 and pidgin-otr 4.0.1 release
Date: 2014-10-21 10:45:00
Author: OTR team
We are pleased to announce the release of pidgin-otr (4.0.1) and libotr
(4.1.0). These are mostly bugfixes as well as some new translations for
### Pidgin-otr updates:
* Fix max message size for Novell Groupwise
* New Czech, Finnish, Brazilian Portuguese, Norwegian Bokmal translations. Updated French, Chinese translations.
* The Windows binary has been linked with updated versions of libotr, libgcrypt, and libgpg-error.
### libotr updates:
* Modernized autoconf build system
* Use constant-time comparisons where needed
* Use gcrypt secure memory allocation
* Correctly reject attempts to fragment a message into too many pieces
* Fix a missing opdata when sending message fragments
* Don't lose the first user message when REQUIRE_ENCRYPTION is set
* Fix some memory leaks
* Correctly check for children contexts' state when forgetting a context
* Add functions' definition for:
* otrl_context_find_recent_instance()
* otrl_context_find_recent_secure_instance()
Thanks to everyone who contributed on this release!
### How to report bugs?
If you found any bugs or want to contribute to the otr project. The best way is
to create an account or login using the anonymous ***cypherpunks*** account
with password **contribute** on [](
You can also post on the OTR mailing list at
[]( for help.
### Where can I find the releases?
#### libotr
* [](
* Signature:[](
#### Pidgin-otr
* [](
* Signature: [](
The OTR team.
Title: OTR meeting notes - Tails hackfest in Paris 2014
Slug: tails otr hackfest meeting
Date: 2014-07-14 12:00:00
- jvoisin
- infinity0
- dgoulet
- drwhax
- vmon
1) Modern cryptography
Migrating current OTR protocol to use modern cryptography. We would like to
replace the DSA signature to "ed25519". The DH exchange should be replaced by
"curve25519". libgcrypt supports ed25519 since version 1.6 (package
libgcrypt20). The curve25519 is unclear if it's merged or a work in progress.
The new key(s) should be derived from the old one so users can keep their
current fingerprint.
For that, we discussed the need to cross sign keys for the transition.
Also, should chacha20 and/or poly1305 should be considered as well? No one had
a strong opinion on that.
A proposal of these changes should be written first before any code starts and
Acked-by maintainers/developers/contributors off the community.
2) Tests suite
You can find here a branch of the test suite started by dgoulet which contains
some basic unit tests now integrated with libtap.
(branch: test-suites)
We agree that an "OTR fuzzer" would be great also to basically hunt bug and
also be able to add this to a continious integration system.
There is a bunch of open bugs/features on that we need to tackle but we all
agree that we should *first* make the test suite with a descent code coverage
so we can actually confirm that what we are fixing/implementing is not breaking
Once we have that, there is some kniffing to do especially on some part of the
internal ABI (for instance, second comments of this Memory allocation used without checks, stuff
like that. Mostly this kniffing would be simply to improve the code to make it
more easily maintainable and robust.
We have a twitter account now to tweet about some stuff that's going on in the
OTR community I guess and news/update... So send anything you think might be
worth tweeting :).
Also, we discussed having more action on the blog (
especially maybe putting a "Call to action" for testing.
A new git repository containing the specifications would be a good idea to
create so we can have people looking at the progress of the modern crypto spec.
for instance.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment