
(n+1)sec – a protocol for distributed multiparty chat encryption - ycmbntrthrwaway
https://equalit.ie/introducing-n1sec-a-protocol-for-distributed-multiparty-chat-encryption/
======
sillysaurus3
Some of you might recognize NCC Group, the company that performed the
cryptographic review. They acquired Matasano, tptacek's prior company.
Collectively they have some of the most talented pentesters and cryptographic
analysts.

It's a safe bet that the (n+1)sec protocol has an excellent security rating on
the basis that they only found one low-severity issue and two informational
issues during the analysis.

[https://github.com/equalitie/np1sec/raw/master/doc/NCC_Group...](https://github.com/equalitie/np1sec/raw/master/doc/NCC_Group_Equalitie_N1Sec_Report_2017-07-21_v1.pdf)

Note the caveat:

 _NCC Group reviewed the full specification, however, only the portions of the
library that lined up with the protocol were reviewed. NCC Group did not
perform a line-by-line review of the entire library. Additionally, the review
focused on the library and not a chat client implementing the library._

This means that the theory is sound, but the library itself wasn't actually
pentested. That isn't an indication that there are problems -- just that no
one has looked for them yet. As a specific example:
[https://github.com/equalitie/np1sec/blob/05b73b506b83be9724c...](https://github.com/equalitie/np1sec/blob/05b73b506b83be9724c61bdd46973eee96fa2e31/src/message.cc#L159-L162)
It sounds like assessing memory errors was outside the scope of the security
review, so it seems unlikely that anyone was thinking about questions like "is
there a way for an attacker to trick buffer.size() into becoming -1 and DoSing
the system?" It was focused mostly on the mathematical soundness of the
cryptosystem.

It's extraordinarily expensive to schedule a two-week pentest, but
implementation errors are far more commonly exploited than attacking the
properties of a cryptosystem directly. It might be good to schedule an
additional pentest if possible.

That said, this is mostly incidental. Congrats on shipping!

~~~
ec109685
How much is extraordinarily expensive?

~~~
sillysaurus3
I wouldn't be surprised if this cryptographic review cost $40k without
breaking a sweat.

There's an interesting blog post just waiting to be written about _why_ this
makes sense. It's something you have to experience as an insider to
understand. It's why most attempts at creating a startup to do it cheaply at
scale have failed, for example. It ends up a nice consulting business for
those lone-wolf pentesters, but not a startup. If you're going to be a startup
like Matasano you have to be up front about the cost and not compete
_primarily_ on cost.

The reason this pricing structure makes sense is because there are two aspects
to security: 1. being secure, 2. security theater. Critically, both are
valuable, and dismissing #2 is a mistake.

If something goes wrong, you need that security audit document to fall back
on. NCC Group's reputation is at stake. When they say there is only one low
severity finding and some info findings, what they're really saying is that a
bad guy has to be smarter than the reviewers Alex Bladucci, Jake Meredith and
Andy Lee working together to break your system for two solid weeks. And even
then the bad guy might get lucky or genuinely _be_ smarter.

That's 10 days that they cannot do anything else. You can see that if you have
100 clients in your pipeline, this quickly becomes a problem. It's why
Matasano didn't fall over when they started reaching this scale -- their
recruitment challenges ensured they had the talent to meet the demand.
Literally anyone off the street could do them and become a pentester.

Corollary: If you're going to review 100 companies' codebases, you either need
to raise the price to shocking levels, or you need to recruit a small
pentester army. NCC's strategy for the latter seems to be to buy them all.
With effective results.

As a dev, you'll recognize the classic problem here: you can't have a baby in
less than 9 months, no matter how much you try to shift the schedule around.
It takes two people two weeks to pentest a client. And if you don't have two
people working to break a codebase/cryptosystem for two weeks, I would be very
hesitant to call it secure. It takes almost a week to get your mind into a
state where you understand the target well enough to exploit it in creative
ways. (There are usually lots of easier un-creative exploits lurking though,
so that week is typically still productive.)

My $40k number might be off by $20k in either direction, but it's
fundamentally a shocking number. The salespeoples' job is to make people
understand the value. And to capture the big companies, who can afford to do
pentests every release cycle.

That leaves a massive gap that seems like an opportunity: YC startups. They've
only recently gotten enough investment in the initial stages where spending
that amount of money can make some kind of sense. Spending 10% of your runway
is incredibly scary. I've spent a long time thinking of how to resolve this
problem without much success. For example, I'd be available to do it less
expensively, but I'm one person. If something goes wrong, you can't say "well
sillysaurus pentested us." I've thought about starting a company to do this,
but then you're back to square one: competing on price alone. That inevitably
devolves into a consulting business, not a startup. And even then you won't be
able to keep those kinds of prices that low for very long.

So what do you do if you want to create a startup to fill this gap? Make
tools, and let the tools do the work. Sadly, this is about as easy as making
that sufficiently smart compiler that we've been working on for the last 60
years. You could argue that there is value in letting an automated tool scan
your codebase, and that maybe you could throw deep learning at the problem to
achieve some success. Maybe. I have an xss.txt file that contains exploits
that work on almost every client I throw them at. But occasionally you'll run
into a situation where it works, but only with a twist. And those twists seem
very hard to automate. Pentesting is as creative as programming, so when you
claim you can make a startup to solve "the security problem" (aka nobody can
afford it), what you're saying is you either have a way to recruit lots of
pentesters or you've figured out how to automate a field that relies on
creativity at its core.

~~~
caf
$40k doesn't seem particularly shocking to me. If you have a team of 5 working
on developing the thing that'd be roughly what your own team cost you for 2
weeks anyway (counting salary, benefits, leave, equipment, office space and
overheads).

~~~
baby
You're effectively hiring highly trained engineers to join your team for 2
weeks at that price. People who read and break crypto every day and who've
been doing that for a fairly large amount of big companies and for various
kind of projects.

------
cyphar
Matrix also has an OTR-like multi-party encryption scheme based on the Axolotl
ratchet called Olm[1]. It also went through an NCC security audit[2]. I
believe it has many of the same features as (n+1)sec, so I'm a little confused
why they said

> Now that a _first protocol_ for secure distributed multiparty chat exists

are they not aware of Olm, or do they not think it provides the same
guarantees?

[1]:
[https://git.matrix.org/git/olm/about/](https://git.matrix.org/git/olm/about/)
[2]: [https://www.nccgroup.trust/us/our-research/matrix-olm-
crypto...](https://www.nccgroup.trust/us/our-research/matrix-olm-
cryptographic-review/)

~~~
wuch
(n+1)sec attempts to address the issue of transcript consistency, which is
completely out of scope for megolm. Though, it puts additional requirements on
the chart room, in particular "members of the chat room receive the same chat
events in the same order". I wonder how well this works in practice; does XMPP
chat rooms usually ensure this or not; what about flaky internet connection,
etc.

~~~
hvidgaard
The protocol itself could implement an ITC, with deterministic rules for
concurrent events, and thus have an identical ordering for all members. It
would make sense to make this as an extra layer on top of the core protocol
when using distribution mechanics that cannot guarantee ordering (which is
most of them).

------
lucb1e
From this[1] answer on the IT Security StackExchange site:

> N+1Sec is a similar protocol [to multi-party OTR, which requires
> participants to be online at all times to renegotiate keying material] with
> some improvements. Note that these protocols have a lot of algorithmic
> complexity and tend to scale badly, especially when you add latency into the
> mix.

It's unclear to me, though I can hardly imagine it being the case, whether
this protocol requires all participants to be online at all times. The quoted
answer surely sounds like it has that drawback, which is why I never really
considered it as an option (leaving the Signal Protocol with "server-side fan-
out" as the only good option).

If it does not have that drawback, having another protocol is a great thing,
assuming what Wire says is true regarding OpenWhisperSystems trying to get
millions from them for implementing a supposedly open source protocol.[2]

[1]
[https://security.stackexchange.com/a/127331/10863](https://security.stackexchange.com/a/127331/10863)

[2] [https://medium.com/@wireapp/axolotl-and-
proteus-788519b186a7](https://medium.com/@wireapp/axolotl-and-
proteus-788519b186a7)

~~~
the8472
Skimming the protocol specification it seems like they renegotiate a subession
whenever someone joins or leaves a group.

> The quoted answer surely sounds like it has that drawback

For IRC you would probably run this on a bouncer, which is essentially always-
on even if the device from which you access the bouncer is not. Of course this
only works for people who have the technical skill to configure one in the
first place.

~~~
ecma
Not sure what you mean by a sub-session but my perusal suggests an entirely
new conversation key is negotiated by current participants when those
participants change. The spec doesn't say anything about requiring everyone to
be online but I think it's implied. It may be that not everyone has to be
online at the same time (which would just delay the negotiation IIUC) which is
interesting but I wonder what would happen if an offline participate rejoins
and doesn't get a full transcript from when they were last online with the
carrier. Sounds entirely possible for an IRC/XMPP carrier with people not
using bouncers.

~~~
victorcase
I also think that it's implied, maybe like Telegram Private Chat - when you
need to wait the peer to go online before complete the key exchange.

However when scale to a group with N peers.. we need to wait all of them,
maybe they do waking up the peer's via Silent Notification or something like
that..

Yeah it's a real fight usability vs security.

------
ycmbntrthrwaway
How does it compare to OMEMO? Here is what the page says about OMEMO (aka
Signal Protocol): "It is an incredibly powerful solution but it is reliant on
asynchronous communication and is therefore also dependent on the messaging
platform — a central server that can become a single point of failure (or
metadata collection)." But AFAIK OMEMO works with XMPP even with federation.
What are they talking about?

Well, XEP-0384 [1] says users must publish their keys via PEP (personal
eventing protocol), but that is to allow sending messages when recipient is
offline. And it does not leak more metadata that already leaks during actual
message transmission. [1]
[https://xmpp.org/extensions/xep-0384.html](https://xmpp.org/extensions/xep-0384.html)

~~~
wuch
OMEMO ensures neither room consistency nor transcript consistency. In fact,
last time I checked you could easily send different transcript to different
participants (for example by simply not providing them decryption key or
providing an incorrect one; some clients do not provide any feedback to the
user that something is going wrong).

~~~
jbermudes
One of the more frustrating aspects of some clients like Gajim is that you can
be in a multiparty chat, but there's no way to tell why OMEMO isn't working.
You're probably missing somebody's keys, but unless you go spelunking through
debug logs you're never going to know. And good luck if one of the members of
the memberlist rarely signs in, then you'll never get his key thus rendering
OMEMO useless!

~~~
madez
What I think is even more frustrating is that OMEMO is not required by
default. I try to communicate with a group of people without WhatsApp, but I'm
not in a position to tell them each which options to check, and what to look
for. That's too much hassle for them. That's why I think Jabber/XMPP is lost.

Encryption must be on by default. Better if there is no option of unencrypted
communication at all. Go get a debug build for that.

Receiving receipts and reading receipts are a must. It must be on by default.
Communication always goes two ways. I had enough situations where one couldn't
be sure if the other person has read an urgent info and whether the situation
needed escalation.

Account information must be hidden, if the system is not decentralized. People
don't want to remember account names and passwords. Get device specific keys,
or whatever. Just hide it from the user, unless they want to look at it.
People don't want to hear about servers.

------
hobarrera
In reality, the most important thing isn't really the protocol, but how to
market it.

We've had open, standard, (some also federated) IM protocols that were on-par
with proprietary ones at the time multiple times in the past.

The problem has always been the same: no mainstream adoption, only nerds use
it, they stagnate, and a few years later, they're behind what mainstream
proprietary apps use. What we really really need to work on is how to get the
general population to adopt these things rather than Facebook's next IM. And
_that_ 's the really hard part!

~~~
Tossrock
This is part of what makes Signal exciting - great crypto backed by a lot of
security folks, yes, but also mindshare and adoption, even among not
traditionally security minded users. I've seen a wave of "X is now on Signal!"
roll through my contact list in the past year or so.

~~~
detaro
Sadly the trend seems to go backwards with people around me, since many
enthusiastically jumped to Signal and now are leaving again to more reliable
messengers.

~~~
baby
Can attest to that, most crypto and security groups I'm in have moved to
WhatsApp for group messaging.

In any case, people tend to be less concerned about security in group
messaging since you tend to trust the group less.

One-to-one discussions are still done over Signal for the most part.

------
pacificresearch
I fail to see how this is a major improvement over OMEMO? OMEMO is also an
asynchronous multi-party chat algorithm, except it's already widely adopted by
clients on several different platforms (Android, iOS, Windows, Mac) and has
also received a significant amount of attention from security researchers.

OMEMO's cryptographic security has already been audited as well:
[https://conversations.im/omemo/audit.pdf](https://conversations.im/omemo/audit.pdf)
. I should know as we (Pacific Research Alliance) funded the audit of OMEMO ;)
. Auditing merely the protocol seems a little problematic, it's quite rare for
vulnerabilities to be in an encryption protocol itself and much more common
for it to be in the implementation. There doesn't seem to be any application
which actually implements this library right now, let alone a network capable
of supporting it. In OMEMO's case we also audited the OMEMO implementation in
Conversations where it was originally conceived.

The only difference I can tell from their website is "Room consistency: Group
chat participants are confident that they are in the same room". This seems
like a pretty niche area to be concerned about, and in practice can be solved
by a properly secured network. Although I am no cryptographer I believe OMEMO
may offer the same quality as well, because all the messages must be encrypted
for each participant, so at worst you could fake an identical room with
identical participants, which doesn't really seem like a valid security
problem.

While I love to see new research and further development into this area, it
seems this is a little late to the party.

~~~
kelnage
I would argue that the reason protocol errors are perceived to be "quite rare"
is because the security guarantees that many (most?) security protocols offer
are usually under-specified, if at all. When auditing protocols, analysts
often have to infer what properties a user might expect.

A great example of this would be [1], where a number of ISO-standardised
authentication protocols failed to give even the most basic authentication
properties. And this kind of issue isn't limited to ISO - the same kinds of
issues appeared when analysing TLS, Signal, and others.

The problem is that implementation errors are usually more clearly violations
of confidentiality (i.e. it is obvious that an attacker is able to access
something they weren't supposed to) - so they are generally held to be more
valuable - and hence more eyes spend time looking for them.

(Disclaimer: I am doing a PhD in this field with Prof Cas Cremers, which might
bias my views on this subject a little)

1\.
[http://www.cs.ox.ac.uk/people/cas.cremers/downloads/papers/B...](http://www.cs.ox.ac.uk/people/cas.cremers/downloads/papers/BCM2013-iso9798-JCS.pdf)

~~~
wuch
What issue do you refer to in context of Signal protocol?

~~~
kelnage
Sorry, I didn't make myself clear there. Under-specified security properties.
Although they (and TLS, honestly) do a better job than others, in their
protocol documentation they really don't go to any lengths to describe what
actual security the protocol provides - just that it is "secure". This makes
verifying these protocols nigh impossible - and usually you end up with the
analyst having to reverse-engineer what security properties they think the
designers wanted the protocol to ensure.

------
daurnimator
I've been looking for a secure alternative to IRC. Looking through this:

Is there a way to turn off forward secrecy? For many uses cases you don't want
it. I guess you can always add a way after the fact (e.g. by including
previous key in each new message)

> New participants cannot join a channel without approval of all existing
> participants. Participants know the exact set of participants in the channel
> at all times.

This seems problematic for anything more than a trivial number of
participants.

~~~
cyphar
> I've been looking for a secure alternative to IRC. Looking through this:

Have you looked at Matrix[1]? It's federated, also has multiparty OTR-like
encryption, supports multiple devices for each user (with granular trust). And
they have many different clients. It also synchronises your chat history.

> Is there a way to turn off forward secrecy? For many uses cases you don't
> want it. I guess you can always add a way after the fact (e.g. by including
> previous key in each new message)

I believe that you'd always want forward secrecy for any transmitted
information. However, you could do what Signal does by storing all of your
messages with a single encryption key (so you don't store all of the historic
keys, which would be bad).

[1]: [https://matrix.org/](https://matrix.org/)

~~~
daurnimator
> Have you looked at Matrix

Yes I have.

Have been working on a kubernetes setup for it last week infact:
[http://github.com/hashbang/kubernetes-
matrix](http://github.com/hashbang/kubernetes-matrix)

~~~
cyphar
Cool, I might spin that up on my local Kubernetes cluster. I was thinking
about how hard it would be to self-host a Matrix server (I didn't see any k8s
configurations published, and their Docker setup is questionable).

------
natch
"Forward secrecy" is listed as a feature. I've heard of "perfect forward
secrecy" \-- is there a distinction between the two?

~~~
nullc
It's a bad idea to use the perfect term, because "oh it has perfect secrecy!
that will keep my data safe no matter what!"

~~~
natch
Yeah good point; that could be misleading to average people.

Reminds me of when I once did a short gig at a place where the differently-
clued owner had purchased some "BackUPS(TM)" brand backup power battery
devices. Of course these have absolutely nothing whatsoever to do with data
backup, but he was very satisfied with himself that he had checked off the
requisite checkbox for data backups.

------
secfirstmd
Congrats to Dmitri and all the folks who have been working on this for a long
time. Also kudos to the Open Tech Fund for getting behind it.

------
acdjuiamadfn
Anybody knows how whatsapp does it currently?

~~~
baby
They use Whisper Systems specs:

* [https://whispersystems.org/docs/specifications/x3dh/](https://whispersystems.org/docs/specifications/x3dh/)

* [https://whispersystems.org/docs/specifications/doubleratchet...](https://whispersystems.org/docs/specifications/doubleratchet/)

------
buttcake
Great.

Now just implement a client using web technologies and distribute it embedded
in a standalone seperate chromium client.

