Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> and has a number of independent implementations

Actually it's slightly more than that: it's standardised. Signal for all it's niceties isn't. Even if you did emulate it (and you can because it's open source), it's a moving target so there is no guarantee what works today would work tomorrow. AFAIK, all existing reimplementations are incompatible.

Worse, it's infrastructure is centralised. There aren't 10 different lookup servers you can use interchangeably and cross validate. There is just one, situated in one country, and it happens to be a country whose government intelligence agencies have a long and colourful history of infiltrating and compromising organisations just like Signal.

The other thing major different is the PGP ecosystem does have key validation system, and in my experience it is actually used. People go to key signing parties and take them seriously. Signal also has very good key validation of course, but nobody uses it.

So while it's true to Signal can let kids chat to each other securely, the reality is it that security is very weak because they don't want to go to all that tedious setup the PGP / X509 ecosystems wants them to do. When they start a chat with someone new, they don't get a warning that could be anyone unless they use Signal's inbuilt (and very well designed) validation system. I guess such a warning might get in the way of the "frictionless experience" seems to love about it. As a consequence, when someone changes phones they have no idea of the importance of porting their Signal identity across, and when the other end gets the "Warning: Person XYZ changed their identity" (or whatever the wording is) they just shrug ignore it ("they must have got a new phone"). And with that whatever security Signal does provide collapses like a house of cards.

If the security industry claims Signal provides the same security as GPG/PGP while being easier to use, all that tells you is how little the people claiming to represent the security industry know about security. (This isn't to say if you use it correctly Signal won't provide a similar level of security - it does. But they it becomes as burdensome to use as PGP.)



These are arguments about things other than safety. In discussions about whether things are "standardized" or "federated" or how their "ecosystems" look, the safety of actual people is an externality. That's especially so because the overwhelming majority of technologists with strong opinions about secure messaging never send a message that needs real cryptographic protection against a motivated adversary; the entire concept of safety is an externality to those people. But the real, life-or-death cases are not rare. It is malpractice to suggest that people entrust their lives (or their life's savings) to shoddy encryption so that other technologists can have a federated ecosystem of standards.

If this were and engineering discussion about tie rods holding elevated walkways in a downtown hotel, we'd have no trouble setting aside all the other arguments and recognize the core, overwhelming priority. But because our discipline is not an engineering discipline, despite pretending otherwise, we're forced to humor these frankly unethical debates.


>There is just one, situated in one country, and it happens to be a country whose government intelligence agencies have a long and colourful history of infiltrating and compromising organisations just like Signal.

Whereas that same agency is under fewer restrictions for targets hosted in other countries.

>the reality is it that security is very weak because they don't want to go to all that tedious setup the PGP / X509 ecosystems wants them to do.

Being tedious doesn't automatically improve security. See https://latacora.micro.blog/2019/07/16/the-pgp-problem.html and https://blog.cryptographyengineering.com/2014/08/13/whats-ma... and https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d695...: see the section on why broken stuff there won't be fixed.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: