Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How the Textsecure Protocol Works

alexkyte.me

Post reply on HN
Print view View original

71–80 of 87 posts

Re: How the Textsecure Protocol Works

#71

Post by eatbitseveryday »

oakwhiz wrote: post #27
FabHK wrote: post #7

Earlier quoted context omitted.

Wire seems fairly fully featured, open source, and claim to have a feasible "freemium" business model, i.e. later selling premium services on the platform. They claim they use the Axolotl double ratchet, though Moxie/OWS claims Wire uses a variation of the protocol they don't recommend.

I would be interested to know exactly what it is about Wire that OWS doesn't seem to approve of

> Wire does not use Signal Protocol, they used some of our code to create a protocol of their own devising that we do not recommend.

4 days ago, no follow-ups to questions for details.

https://news.ycombinator.com/item?id=12688012#12690148

Re: How the Textsecure Protocol Works

#72

Post by newjersey »

stouset wrote: post #66
newjersey wrote: post #35

Earlier quoted context omitted.

Instead of responding to the tone, let's concentrate on the merits. For most people, it is unacceptable to require both parties to be simultaneously online in a chat session. I'm very interested in any potential implementation that allows asymmetric conversations without a dedicated third node (if we don't like the name server) somewhere in between.

Of course tone is relevant. Tone is how one has a civil conversation with another person, even if they disagree.

Ah, thanks for displaying your civility with a down vote, downvoter.

Some people are rougher around the edges than others. I thought this place was a sjw heaven but clearly some people want this place to be a monoculture as well.

Re: How the Textsecure Protocol Works

#73

Post by petre »

verbify wrote: post #48
stouset wrote: post #26

Earlier quoted context omitted.

The point was you don't, but plenty of people do. And those people haven't sounded the alarm on any red flags.

We had access to openssl code, and yet heartbleed happened.

Bugs were also discovered in Cisco IOS and Juniper JunOS that led to security compromises and a leaked NSA rootkit. At least open source code cand be audited by independent security experts, forked, rewritten and fixed (see LibreSSL).

Re: How the Textsecure Protocol Works

#74

Post by Natanael_L »

Arathorn wrote: post #21

isn't the "double ratchet" describing the presence of both a DH ratchet as well as a hash ratchet, rather than "send" and "receive"?

Triple DH + the double hash ratchet makes up two of the big (separate) parts of the crypto in the protocol. One does key exchange, the other does per-message PFS.

Re: How the Textsecure Protocol Works

#75

Post by Natanael_L »

Canada wrote: post #42
ChoHag wrote: post #32

Earlier quoted context omitted.

It lacks the most basic, fundamental property of a secure system: A demonstration (actual proof can wait!) that it can be trusted without handwavium. I don't care if it's the dog's bollocks or the bee's knees. If I can't trust it, it's useless for secure communication. I don't give the tiniest shit how many hours some twat on the internet, or well-paid collection of highly-trained twats, has poured into its creation…

Feel free to propose a secure, decentralized way to pass the payload between the endpoints. Be sure your solution includes an effective mechanism to mitigate spam. Bonus if your solution denies attackers access to the same metadata centralized systems do. Double bonus if you can support push messaging systems to deliver timely notification that users have come to expect.

Home servers connected over I2P, hopefully.

Re: How the Textsecure Protocol Works

#76

Post by ChoHag »

dfox wrote: post #65
ChoHag wrote: post #43

Earlier quoted context omitted.

Good! Say that! Then the entire protocol and its description can be reduced to "this is a cache of ephemeral public keys and messages encrypted using them". I know that doesn't sound quite so impressive, but that's because it isn't.

Cryptographic protocols are not supposed to be impressive. But on the other hand your shortened description describes the main difference between Signal and traditional OTR, it does not describe how the protocol works after you get the ephemeral key of the receiver. Additional and to some extent non-trivial difference from traditional OTR is in how these ephemeral keys are used in key exchange, whose result depends n…

That was made apparent in their documentation.

Or would have been, if they had any.

Re: How the Textsecure Protocol Works

#77

Post by dredmorbius »

stouset wrote: post #66
newjersey wrote: post #35

Earlier quoted context omitted.

Instead of responding to the tone, let's concentrate on the merits. For most people, it is unacceptable to require both parties to be simultaneously online in a chat session. I'm very interested in any potential implementation that allows asymmetric conversations without a dedicated third node (if we don't like the name server) somewhere in between.

Of course tone is relevant. Tone is how one has a civil conversation with another person, even if they disagree.

Tone matters. It's not everything, but it matters.

There are people, and/or messages, in which a lack of civility needn't warrant a complete dismissal. They're relatively rare.

I'm willing to give a hearing here. Crypto is, for better or worse, an area in which there is a tendency toward both informed and abrasive contributions.

I'm aware HN doesn't take well to that. I've been arguing the opposite strategy for the past few days with a friend (he likes tossing bollocks about, I prefer avoiding that). I'd advise ChoHag to tone it down (and reconsider their chosen handle), but contribute. I did consider vouching the flagged/dead comment, but decided against in this case.

Re: How the Textsecure Protocol Works

#78

Post by [deleted] »

tptacek wrote: post #69
conradev wrote: post #63

Earlier quoted context omitted.

This is a valid point. Both the source code and the CFG can hide bugs pretty easily. I would argue that reading source code is much easier, though. For example, if you are auditing code written in a memory-safe language, you don't need to look for memory corruption bugs. You also have an audit trail for all source code changes.

It's not like this code was originally written in Haskell. Come on.

[deleted]

Re: How the Textsecure Protocol Works

#79

Post by WhitneyLand »

tptacek wrote: post #57
pbhjpbhj wrote: post #38

Earlier quoted context omitted.

So if they implemented a small extra procedure to copy text and send on a side-channel when a flag was set externally, if such a thing was done then this would be obvious to many people despite it being closed source? Aren't these apps developed modularly? Or indeed if it were a patch that could be initiated as forced update at will from the server-side, again that would be clear to "people" based on the client side…

That's not really what "side channel" means. You mean "covert channel", a related but different concept.

The bigger point he's making is that your comment "Anyone who can read a control flow graph" can be taken to mean everything is fine here when it's really not.

Its not hard to imagine how WA could be compromised without anyone knowing for many years.

Re: How the Textsecure Protocol Works

#80

Post by tptacek »

WhitneyLand wrote: post #79
tptacek wrote: post #57

Earlier quoted context omitted.

That's not really what "side channel" means. You mean "covert channel", a related but different concept.

The bigger point he's making is that your comment "Anyone who can read a control flow graph" can be taken to mean everything is fine here when it's really not. Its not hard to imagine how WA could be compromised without anyone knowing for many years.

I don't understand what you are trying to say here, sorry.
Post reply on HN