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.
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... 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!
But how do you achieve fully decentralized group chat while at the same time knowing the ordering of the messages?
As far as I know, CRDTs and other techniques are not resilient in yhe face of byzantine failures. For one writer and many readers we have scuttlebutt type solutions. For many writers we have blockchains as the state of the art. How does this protocol solve the problem?
Let's say in a multiplayer game I claim that I made a move before I saw the game state change. Or I made 1000 moves. How do you prevent this?
Because the threat model is different. Why would your friends and colleagues in a group chat want to tinker with the order of messages? Just trust a sender's timestamp, provided it's within X minutes.
$10,000 - $12,000 per week is normal for an application security assessment. Go ahead and double that for a specialization like protocol cryptanalysis.
Ballpark $40,000; maybe more because there were three consultants, not two. I wouldn't be surprised at the price until it hit $60,000; I'd be outright shocked at $100,000.
If you have two or three consultants working on this full time, you're charging $7000 - $10,000 per consultant-week of time. Those numbers would only be shocking to someone who has never been a consultant or who has never engaged in an assessment; the margin is lower than it looks when you account for the peripheral staff aside from the consultants working on the engagement.
Consulting for a variety of software specializations very easily hits five figures per week.
Well, the third pentester was a shadow, which is a wildcard in terms of value and probably wasn't an influence during the initial sales negotiations.
Ballpark $40,000; maybe more because there were three consultants, not two.
In this case it was a cryptographic review, so it's probably closer to $80k. I forgot to take that into account in my other comment. $40k would be a pretty standard price point for a regular pentest. NCC also incurs additional risk to their reputation when organizations publish documents like this, so another $20k might've been necessary to get them to this point. I'm not positive it works that way, but I know that publishing a document like this is generally more significant than the usual "here's a secret document" deliverable. There have only been 17 public reports in total, for example: https://www.nccgroup.trust/us/our-research/?research=Public+... So it's a bigger deal on both sides of the table.
I think your $100k figure is pretty on-point. Or at least not unrealistic to be closing in on that.
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.
$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).
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.
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?
(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.
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).
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]
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.
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.
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..
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
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).
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!
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.
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!
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.
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.
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 . 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.
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)
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.
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.
> 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).
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).
There should still be http://silcnet.org/ although I have no idea what is the development status these days. Several years ago, it was quite lively, and looked promising.
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.
Actually it loks like (n+1)sec isn't perfect: a symmetric key is shared by all participants for a certain amount of time, until a participant joins or leaves or asks for re-keying. So you have a chunk of messages, with no upper bound on how many messages share the same symmetric key.
I believe it is pairwise (i.e. every chat member does a handshake with every other chat member), although there is some debate about this in the academic community.
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...
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... 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!