Commit 4f2bb77f authored by David Goulet's avatar David Goulet

Add mpOTR blog post from HOPE X

Signed-off-by: default avatarDavid Goulet <dgoulet@ev0ke.net>
parent 4bcb9868
<!DOCTYPE html>
<html>
<head>
<title>My Blog</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link href="css/bootstrap.min.css" rel="stylesheet">
<link href="https://fonts.googleapis.com/css?family=Open+Sans" rel="stylesheet" type="text/css">
<link href="https://fonts.googleapis.com/css?family=Yanone+Kaffeesatz" rel="stylesheet" type="text/css">
<style>
body {
font-family: Open Sans;
background-color: #f3f3f3;
}
h1, h2, h3, h4 {
font-family: Yanone Kaffeesatz;
}
.container {
max-width: 730px;
}
.footer {
margin-top: 50px;
font-size: 11px;
text-align: center;
}
</style>
</head>
<body>
<div class="container">
<div class="hero-unit faq">
<div class="ac" style="text-align: center;">
<h1>My Blog</h1>
<a href="index.html">Home</a> &bull; <a href="about.html">About</a> &bull; <a href="feed.xml">Feed</a>
</div>
</div>
<div class="hero-unit faq">
<div class="ac">
<h2>mpOTR progress report - HOPE X in New York 2014</h2>
</div>
</div>
<div>
<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 by 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 mention 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>
<div>
<p class="text-muted">published on 2014-07-25 00:00:00 by dgoulet, infinity0</p>
</div>
</div>
</div>
<div class="footer">
<p class="text-muted">powered by <a href="https://github.com/botherder/habu">habu</a>.</p>
</div>
</body>
</html>
\ No newline at end of file
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