Encrypted messengers: Riot, not Signal, is the future

Re:Encrypted messengers: Riot, not Signal, is the future by cguess on Thursday December 22, 2016 @03:12PM (#13239983)

Technically? There's nothing stopping them. For that matter, there's no stopping Google from doing the same. There's also no stopping Apple from patching LLVM so that only patched versions of OpenSSL are ever compiled against. The question is how paranoid are you and what is your threat model?

We have to trust someone, eventually. This is especially true for the 99% of the population who doesn't have the skill to compile source themselves (nor should they have to).

[ Parent | on HN ]

Re:Encrypted messengers: Riot, not Signal, is the future by iagreeentirely on Thursday December 22, 2016 @03:52PM (#13240293)

Just in case nobody has gotten to enjoy this gem:

http://wiki.c2.com/?TheKenThompsonHack

Ken describes how he injected a virus into a compiler. Not only did his compiler know it was compiling the login function and inject a backdoor, but it also knew when it was compiling itself and injected the backdoor generator into the compiler it was creating. The source code for the compiler thereafter contains no evidence of either virus.

[ Parent | on HN ]

Re:Encrypted messengers: Riot, not Signal, is the future by Sanddancer on Thursday December 22, 2016 @04:28PM (#13240542)

Which is why standardization is just as important, if not moreso, than openness in making sure things stay secure. Such an attack is made a lot more difficult if you have a second toolchain you can use to verify things, and even moreso if you have a third.

[ Parent | on HN ]

Re:Encrypted messengers: Riot, not Signal, is the future by haffenloher on Thursday December 22, 2016 @06:03PM (#13241204)

> For that matter, there's no stopping Google from doing the same.

That's the exact reason why package signing is decentralized in the Android ecosystem. All apps in the Play Store are signed by their developers.

[ Parent | on HN ]