Commit 39fd42c4 authored by David Goulet's avatar David Goulet

Add chatifesto post and october 2014 release post

Signed-off-by: default avatarDavid Goulet <dgoulet@ev0ke.net>
parent 7c4530a0
<!DOCTYPE html>
<!--[if lt IE 7]> <html class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]> <html class="no-js lt-ie9 lt-ie8 ie-7"> <![endif]-->
<!--[if IE 8]> <html class="no-js lt-ie13 ie-8"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js"> <!--<![endif]-->
<html lang="en">
<head>
<title>Otr.im - Blog</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link href="https://otr.im/assets/css/style.css" rel="stylesheet">
<link href="css/style.css" rel="stylesheet">
</head>
<body class="blog">
<div class="navbar-wrapper">
<div class="container">
<div class="navbar navbar-inverse navbar-static-top" role="navigation">
<div class="container">
<div class="navbar-header">
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="#">OTR.im</a>
</div>
<div class="navbar-collapse collapse">
<ul class="nav navbar-nav">
<li><a href="https://otr.im/">Home</a></li>
<li><a href="https://otr.im/clients.html">Clients</a></li>
<li><a href="https://otr.im/about.html">About</a></li>
<li class="active"><a href="https://otr.im/blog/">Blog</a></li>
</ul>
</div>
</div>
</div>
</div>
</div>
<div class="container" id="container">
<div class="container-inner">
<div class="hero-unit faq">
<div class="ac">
<h2 class="maintitle">Chatifesto</h2>
</div>
</div>
<div class="post">
<p>This Chatifesto has been written by Elijah from the wonderful leap.se project.</p>
<h2>Old chat, new chat</h2>
<p>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.</p>
<p>The protocols that emerged in this period, such as XMPP and OTR, had this model of interaction in mind when initially designed. </p>
<p>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.</p>
<p>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.</p>
<h2>The goldilocks architecture</h2>
<p>There are three possible architectures for a message system: centralized, peer-to-peer, or federated.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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. </p>
<p>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. </p>
<p>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.</p>
<p>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. </p>
<h2>To the moon</h2>
<p>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.</p>
<p>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. </p>
<p>For example:</p>
<ul>
<li>
<p>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.</p>
</li>
<li>
<p>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. </p>
</li>
<li>
<p>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. </p>
</li>
<li>
<p>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.</p>
</li>
</ul>
<h2>Chat is flexible</h2>
<p>Short messages can be incredibly flexible and lend themselves to many different idioms and patterns of communication.</p>
<p>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.</p>
<p>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.</p>
<h2>The holy grail</h2>
<p>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.</p>
<p>In slightly more detail, this means:</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Secure routing: The user should be protected from analysis of their associations and pattern of message traffic.</p>
<p>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.</p>
<p>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.</p>
<p>Media encryption: Any documents and other media attached to a chat message should be encrypted using the same access controls as the message itself.</p>
<p>Secure storage: Any user data (such as logs, roster, keys, etc) saved locally or synced by the client must be client-encrypted.</p>
<p><em>Semi-goals</em></p>
<p>These would be really nice, but may be very difficult in the near term:</p>
<ul>
<li>Ideally, the server should not know the list of contacts (roster) of a user.</li>
<li>Ideally, the server should not know the membership list of a particular group.</li>
<li>Ideally, the server should not know whom you communicate with.</li>
</ul>
<p><em>Non-goals</em></p>
<p>Although these are nice, we are not trying to achieve any of the following:</p>
<ul>
<li>direct file transfer from one client to another</li>
<li>direct peer to peer messaging without server relays</li>
<li>support for gateways to other chat protocols or SMS</li>
</ul>
<h2>Encryption</h2>
<ul>
<li>
<p>session encryption -- possible to get forward secrecy and deniability. Group session negotiation is experimental and slow.</p>
</li>
<li>
<p>object encryption -- possible for parties to communicate asynchronously (i.e. while only one party is online).</p>
</li>
<li>
<p>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).</p>
</li>
</ul>
<p>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).</p>
<p>There is interesting research in optimizing group session negotiation, but not much code. http://link.springer.com/chapter/10.1007/978-3-540-45146-4_7</p>
<h2>Secure routing</h2>
<p>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.</p>
<p>Some ideas to protect the routing information:</p>
<ul>
<li>
<p>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.</p>
</li>
<li>
<p>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.</p>
</li>
<li>
<p>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.</p>
</li>
<li>
<p>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).</p>
</li>
</ul>
<div class="postmeta">
<p class="text-muted">published on 2014-08-31 14:15:00 by Elijah/Leap.se</p>
</div>
</div>
</div>
</div>
<footer class="footer">
<div class="container-inner">
<p class="pull-right"><a href="#">Back to top</a></p>
<p>OTR - Free and open source software.</p>
<p>We would like to thank <a href="https://www.gandi.net/">Gandi</a> for providing us with a wildcard SSL certificate.</p>
<p class="text-muted">Blog powered by <a href="https://github.com/botherder/habu">habu</a>.</p>
</div>
</footer>
</body>
</html>
\ No newline at end of file
<!DOCTYPE html>
<!--[if lt IE 7]> <html class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]> <html class="no-js lt-ie9 lt-ie8 ie-7"> <![endif]-->
<!--[if IE 8]> <html class="no-js lt-ie13 ie-8"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js"> <!--<![endif]-->
<html lang="en">
<head>
<title>Otr.im - Blog</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link href="https://otr.im/assets/css/style.css" rel="stylesheet">
<link href="css/style.css" rel="stylesheet">
</head>
<body class="blog">
<div class="navbar-wrapper">
<div class="container">
<div class="navbar navbar-inverse navbar-static-top" role="navigation">
<div class="container">
<div class="navbar-header">
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="#">OTR.im</a>
</div>
<div class="navbar-collapse collapse">
<ul class="nav navbar-nav">
<li><a href="https://otr.im/">Home</a></li>
<li><a href="https://otr.im/clients.html">Clients</a></li>
<li><a href="https://otr.im/about.html">About</a></li>
<li class="active"><a href="https://otr.im/blog/">Blog</a></li>
</ul>
</div>
</div>
</div>
</div>
</div>
<div class="container" id="container">
<div class="container-inner">
<div class="hero-unit faq">
<div class="ac">
<h2 class="maintitle">Release of libotr 4.1.0 and Pidgin-OTR 4.0.1</h2>
</div>
</div>
<div class="post">
<p>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.</p>
<h3>Pidgin-otr updates:</h3>
<ul>
<li>Fix max message size for Novell Groupwise</li>
<li>New Czech, Finnish, Brazilian Portuguese, Norwegian Bokmal translations. Updated French, Chinese translations.</li>
<li>The Windows binary has been linked with updated versions of libotr, libgcrypt, and libgpg-error.</li>
</ul>
<h3>libotr updates:</h3>
<ul>
<li>Modernized autoconf build system</li>
<li>Use constant-time comparisons where needed</li>
<li>Use gcrypt secure memory allocation</li>
<li>Correctly reject attempts to fragment a message into too many pieces</li>
<li>Fix a missing opdata when sending message fragments</li>
<li>Don't lose the first user message when REQUIRE_ENCRYPTION is set</li>
<li>Fix some memory leaks</li>
<li>Correctly check for children contexts' state when forgetting a context</li>
<li>Add functions' definition for:<ul>
<li>otrl_context_find_recent_instance()</li>
<li>otrl_context_find_recent_secure_instance()</li>
</ul>
</li>
</ul>
<p>Thanks to everyone who contributed on this release!</p>
<h3>How to report bugs?</h3>
<p>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 <strong><em>cypherpunks</em></strong> account
with password <strong>contribute</strong> on <a href="https://bugs.otr.im">https://bugs.otr.im</a>.</p>
<p>You can also post on the OTR mailing list at
<a href="otr-dev@lists.cypherpunks.ca">otr-dev@lists.cypherpunks.ca</a> for help.</p>
<h3>Where can I find the releases?</h3>
<h4>libotr</h4>
<ul>
<li><a href="https://otr.cypherpunks.ca/libotr-4.1.0.tar.gz">https://otr.cypherpunks.ca/libotr-4.1.0.tar.gz</a></li>
<li>Signature:<a href="https://otr.cypherpunks.ca/libotr-4.1.0.tar.gz.asc"> https://otr.cypherpunks.ca/libotr-4.1.0.tar.gz.asc</a></li>
</ul>
<h4>Pidgin-otr</h4>
<ul>
<li><a href="https://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.1.exe">https://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.1.exe</a></li>
<li>Signature: <a href="https://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.1.exe.asc">https://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.1.exe.asc</a></li>
</ul>
<p>The OTR team.</p>
<div class="postmeta">
<p class="text-muted">published on 2014-10-21 10:45:00 by OTR team</p>
</div>
</div>
</div>
</div>
<footer class="footer">
<div class="container-inner">
<p class="pull-right"><a href="#">Back to top</a></p>
<p>OTR - Free and open source software.</p>
<p>We would like to thank <a href="https://www.gandi.net/">Gandi</a> for providing us with a wildcard SSL certificate.</p>
<p class="text-muted">Blog powered by <a href="https://github.com/botherder/habu">habu</a>.</p>
</div>
</footer>
</body>
</html>
\ No newline at end of file
......@@ -43,69 +43,57 @@
<div class="hero-unit faq">
<div class="ac">
<h2><a href="2014-07-25-hopex mpotr.html">mpOTR progress report - HOPE X in New York 2014</a></h2>
<h2><a href="2014-10-21-libotr 4.1.0 and pidgin-otr 4.0.1 release.html">Release of libotr 4.1.0 and Pidgin-OTR 4.0.1</a></h2>
</div>
</div>
<div class="post firstpost">
<p>Attendees:
- trevp
- infinity0
- DrWhax
- dgoulet
- vmon</p>
<p>This is a progress report on the ongoing mpOTR effort after a meeting at the
HOPE X conference in New York.</p>
<p>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.</p>
<p>This initiative was launched by CryptoCat and eQualit.ie in early 2014 with the
help of OTF for the funding. You can find an overview of the project here
<a href="https://github.com/cryptocat/cryptocat/wiki/mpOTR-Project-Plan">mpOTR</a>. 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.</p>
<p>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.</p>
<p>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.</p>
<p>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
<a href="https://github.com/infinity0/msg-notes">notes</a>.</p>
<p>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.</p>
<p>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.</p>
<p>For the transcript consistency, the discussion was mostly about the performance
overhead of the scheme described
<a href="https://github.com/infinity0/msg-notes/blob/master/causal/02-consistency.rst">here</a>,
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.</p>
<p>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! :)</p>
<p>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.</p>
<h3>Pidgin-otr updates:</h3>
<ul>
<li>Fix max message size for Novell Groupwise</li>
<li>New Czech, Finnish, Brazilian Portuguese, Norwegian Bokmal translations. Updated French, Chinese translations.</li>
<li>The Windows binary has been linked with updated versions of libotr, libgcrypt, and libgpg-error.</li>
</ul>
<h3>libotr updates:</h3>
<ul>
<li>Modernized autoconf build system</li>
<li>Use constant-time comparisons where needed</li>
<li>Use gcrypt secure memory allocation</li>
<li>Correctly reject attempts to fragment a message into too many pieces</li>
<li>Fix a missing opdata when sending message fragments</li>
<li>Don't lose the first user message when REQUIRE_ENCRYPTION is set</li>
<li>Fix some memory leaks</li>
<li>Correctly check for children contexts' state when forgetting a context</li>
<li>Add functions' definition for:<ul>
<li>otrl_context_find_recent_instance()</li>
<li>otrl_context_find_recent_secure_instance()</li>
</ul>
</li>
</ul>
<p>Thanks to everyone who contributed on this release!</p>
<h3>How to report bugs?</h3>
<p>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 <strong><em>cypherpunks</em></strong> account
with password <strong>contribute</strong> on <a href="https://bugs.otr.im">https://bugs.otr.im</a>.</p>
<p>You can also post on the OTR mailing list at
<a href="otr-dev@lists.cypherpunks.ca">otr-dev@lists.cypherpunks.ca</a> for help.</p>
<h3>Where can I find the releases?</h3>
<h4>libotr</h4>
<ul>
<li><a href="https://otr.cypherpunks.ca/libotr-4.1.0.tar.gz">https://otr.cypherpunks.ca/libotr-4.1.0.tar.gz</a></li>
<li>Signature:<a href="https://otr.cypherpunks.ca/libotr-4.1.0.tar.gz.asc"> https://otr.cypherpunks.ca/libotr-4.1.0.tar.gz.asc</a></li>
</ul>
<h4>Pidgin-otr</h4>
<ul>
<li><a href="https://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.1.exe">https://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.1.exe</a></li>
<li>Signature: <a href="https://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.1.exe.asc">https://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.1.exe.asc</a></li>
</ul>
<p>The OTR team.</p>
<div class="postmeta">
<p class="text-muted">published on 2014-07-25 00:00:00 by dgoulet, infinity0</p>
<p class="text-muted">published on 2014-10-21 10:45:00 by OTR team</p>
</div>
</div>
......@@ -115,6 +103,16 @@ we can finally move to an implementation! :)</p>
<h3 class="subtitle">Older Posts</h3>
<ul class="postlist">
<li>
<span>2014-08-31 14:15:00</span>
<a href="2014-08-31-New chat paradigm.html">Chatifesto</a>
</li>
<li>
<span>2014-07-25 00:00:00</span>
<a href="2014-07-25-hopex mpotr.html">mpOTR progress report - HOPE X in New York 2014</a>
</li>
<li>
<span>2014-07-14 12:00:00</span>
<a href="2014-07-14-tails otr hackfest meeting.html">OTR meeting notes - Tails hackfest in Paris 2014</a>
......
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