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

51–60 of 87 posts

Re: How the Textsecure Protocol Works

#51

Post by conradev »

lisper wrote: post #40
FabHK wrote: post #5

Earlier quoted context omitted.

- we don't have access to the source code, so who knows what they have implemented? - even if they have implemented it faithfully, you should compare fingerprints. If they don't line up, you might be subject to a MITM attack

Even if you had access to the source code, how would you verify that the app you are running was compiled from that source?

They'd need to be building reproducibly[1], which is somewhat difficult to do on iOS thanks to code signing and App Store encryption[2]. Android is definitely closer[3].

[1] https://reproducible-builds.org

[2] https://github.com/WhisperSystems/Signal-iOS/issues/641

[3] https://f-droid.org/wiki/page/Deterministic,_Reproducible_Bu...

Re: How the Textsecure Protocol Works

#52

Post by verbify »

tedunangst wrote: post #25
frutiger wrote: post #10

Earlier quoted context omitted.

If builds were reproducible (i.e. binaries would be identical if recompiled with the same toolchain on a different machine), then all it would take is N independent builders to verify the app store binary matches their locally built binary to greatly decrease the likelihood of tampering. So, while being open source is not the complete answer, it certainly doesn't hurt.

How do you guarantee the App Store doesn't serve limited edition binaries to selected recipients?

If you suspect yourself to be a selected recipient (e.g. you're Edward Snowden) I reckon you should compile your own binaries. Or read 'Reflections on Trusting Trust'.

Re: How the Textsecure Protocol Works

#53

Post by ChoHag »

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.

I'm not trying to propose a "way" of anything, "secure", "decentralised" or otherwise! Don't you get it? I'm talking about the documentation.

I have no idea if this solution to the problems posed is sound because before I can even get to the source code there is no description of how or even whether it solves the fundamental problems in the cryptographic situation it describes (viz. device which cannot straightaway engage in IP communication requires to receive unsolicitated securely-encrypted messages).

Re: How the Textsecure Protocol Works

#54

Post by conradev »

tptacek wrote: post #9
FabHK wrote: post #5

Earlier quoted context omitted.

- we don't have access to the source code, so who knows what they have implemented? - even if they have implemented it faithfully, you should compare fingerprints. If they don't line up, you might be subject to a MITM attack

1. Anyone who can read a control flow graph. 2. Yes.

When the difference between correct code and a pretty bad bug can be one instruction[1], I'm not sure if "anyone who can read a control flow graph" is going to be able to find implementation flaws (intentional or not).

[1] https://youtu.be/5pAen7beYNc?t=13m51s

Re: How the Textsecure Protocol Works

#55

Post by niftich »

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.

It's about incentives. The heartbleed bug was present in the code for almost two full years before someone who discovered it exercised responsible disclosure. It's possible that others have noticed it before this, but it's highly likely that the only people looking were security researchers, power users (like Google, the ones who first reported it to the authors), or actors looking to exploit it for their own agenda.

As it stands, average people (or average developers) have little incentive to go trawling through the existing body of open source code, mostly because they probably have better things to do with their time. In the commercial world, bug bounties attempt to skew the incentives to encourage the 'more eyes' part of the axiom 'given enough eyeballs, all bugs are shallow'.

Re: How the Textsecure Protocol Works

#56

Post by conradev »

tedunangst wrote: post #25
frutiger wrote: post #10

Earlier quoted context omitted.

If builds were reproducible (i.e. binaries would be identical if recompiled with the same toolchain on a different machine), then all it would take is N independent builders to verify the app store binary matches their locally built binary to greatly decrease the likelihood of tampering. So, while being open source is not the complete answer, it certainly doesn't hurt.

How do you guarantee the App Store doesn't serve limited edition binaries to selected recipients?

Fun fact: The App Store already serves limited edition binaries to everyone because it encrypts them per-account :)

Re: How the Textsecure Protocol Works

#57

Post by tptacek »

pbhjpbhj wrote: post #38
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.

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.

Re: How the Textsecure Protocol Works

#58

Post by ChoHag »

Let me paint you idiots a picture.

I am Alice. I want to talk to Bob, securely. I call Bob into my Safe Space (we have those now, in C21). I lock the tinfoil. I encover the blankets. I intimately verify that Bob is indeed the Bob we all now and love. Bob and I are ready to communicate and we do so. Enthusiastically.

Bob leaves (without even a cuddle!), but I have more messages I want to give to Bob. Bob is too cute to pass up.

You remember your old acquaintance Mallory, except he never looked like Mallory. He looked like Charlie, or maybe the vaguely defined Dave or Eve or Fuckinghellmykidunderstandsthisbullshit.

When you saw Charlie, he told you "Don't worry Alice I'm here for you. I can wait here in your Safe Space and pass messages to Bob even if you're busy on some other Fling. And you don't have to tell me what the message says says, just put it in this box and lock it using these keys Bob gave me (I'm not lying!)".

You don't remember where Dave came from, you were just in the pub one day and after a few pints there he was, promising that he could help you commu^Wfuc^Wtalk to Bob even when Bob wasn't with you because he, Eve, would always be there no matter what and you could depend on him totally because you can trust him and he's totally alright even though he gets nothing back from you he's always got your interests at heart over his own because he's just so trustworthy.

Holy fuck I just can't do it any more. If you can't see it by now then good luck with your life.

Fuckinghellmykidunderstandsthisbullshit.

Re: How the Textsecure Protocol Works

#59

Post by Canada »

ChoHag wrote: post #53
Canada wrote: post #42

Earlier quoted context omitted.

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.

I'm not trying to propose a "way" of anything, "secure", "decentralised" or otherwise! Don't you get it? I'm talking about the documentation . I have no idea if this solution to the problems posed is sound because before I can even get to the source code there is no description of how or even whether it solves the fundamental problems in the cryptographic situation it describes (viz. device which cannot straightaway…

> whether it solves the fundamental problems in the cryptographic situation it describes (viz. device which cannot straightaway engage in IP communication requires to receive unsolicitated securely-encrypted messages).

Please elaborate and clarify.

Re: How the Textsecure Protocol Works

#60

Post by verbify »

niftich wrote: post #55
verbify wrote: post #48

Earlier quoted context omitted.

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

It's about incentives. The heartbleed bug was present in the code for almost two full years before someone who discovered it exercised responsible disclosure. It's possible that others have noticed it before this, but it's highly likely that the only people looking were security researchers, power users (like Google, the ones who first reported it to the authors), or actors looking to exploit it for their own agenda.…

Granted Heartbleed was only exploitable for a few years, but Shellshock was available since '89

And I'm pretty sure bug bounties would apply to shellshock and heartbleed as long as you can find a company with a bounty program that also used openssl or could be exploited via bash.

Post reply on HN