(n+1)sec – a protocol for distributed multiparty chat encryption

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.

This is NCC Cryptography Practice, so "significantly more expensive than a normal NCC audit".

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.

I think sakurity charges $35,000 for example.

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).

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.

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!

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.

The signal ios app is really bad though, much worse than telegram's for example.

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

> 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

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.