31–40 of 87 posts
Earlier quoted context omitted.
I just love reading post-optimisation machine code.
The point was you don't, but plenty of people do. And those people haven't sounded the alarm on any red flags.
Earlier quoted context omitted.
Oh it's not warranted is it? Does whichever butthurt shill clicked that button want to suggest why we don't need more detail on which central server stores what in this self-proclaimed "secure" system?
Perhaps people are responding to your unwarranted, toxic tone, your rudeness elsewhere in the comments, and your inability to give even a modicum of respect to the developers who've not only designed and openly published groundbreaking advances in secure private messaging protocols, and not only implemented them and freely distributed those implementations, but have also worked to have those designs incorporated into…
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 if they can't even be arsed to give a basic description of its most fundamental property. And that moniker can remain until they do.
Nice overview. I only wish for there to be an implementation of the signal protocol that fits my needs. In WhatsApp and Allo there are concerns of ad companies using your metadata, and the Signal app is lackluster in the UX department and OWS's affinity with Google is rather disappointing also.
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.
[1] https://news.ycombinator.com/item?id=12148728
[2] https://news.ycombinator.com/item?id=12361410
[3] https://hn.algolia.com/?query=%22wire%20does%20not%20use%22%...
[4] (long but enlightening read) https://news.ycombinator.com/item?id=11725602
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?
Earlier quoted context omitted.
Oh it's not warranted is it? Does whichever butthurt shill clicked that button want to suggest why we don't need more detail on which central server stores what in this self-proclaimed "secure" system?
Perhaps people are responding to your unwarranted, toxic tone, your rudeness elsewhere in the comments, and your inability to give even a modicum of respect to the developers who've not only designed and openly published groundbreaking advances in secure private messaging protocols, and not only implemented them and freely distributed those implementations, but have also worked to have those designs incorporated into…
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.
Earlier quoted context omitted.
The server role seems quite clearly described in more detail in the actual protocol description, is there something missing? The section you quote just describes the high-level idea of why and how to introduce the server in the scheme.
No. If the section beginning "Protocol" is what you refer to as the "actual protocol description" then no, the server role does not seem clearly described in any level of detail. To cut a long story short: Alice gives the cache, aka Mallory, a set of secret data which are implied but not proven to be able to be used by Bob to create cryptographic text which Alice can decrypt but this magic cache, aka Mallory , cannot…
So: making the whole thing completely public only enables adversary to match session initializations with receivers, which the server can do by definition as it has to route the messages to correct recipient. (In the case without such central server, anybody observing the traffic could do that, as another role of the central server is to mask sender addresses on the lower protocol layers)
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?
I don't think we have good solutions for the problem of malicious updates in general.
The only one I can think of is a trusted hypervisor that hashes memory in the guest and reports on it. And even then, how do we trust that?
Earlier quoted context omitted.
I just love reading post-optimisation machine code.
The point was you don't, but plenty of people do. And those people haven't sounded the alarm on any red flags.
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 binary?
These are the ways I imagine I'd snoop on supposed end-to-end encrypted communication channels; there's probably something much cleverer, but again, we're saying that can be detected easily?
Genuine questions, not a programmer, not familiar with the state-of-the-art of reading machine code/interpreting network traffic, nor indeed with which watchdogs are guarding against abuse by the TLAs.
Earlier quoted context omitted.
I just love reading post-optimisation machine code.
The point was you don't, but plenty of people do. And those people haven't sounded the alarm on any red flags.
That is, those who read WhatsApp disassembly and did thourough enough review to warrant with sufficient confidence not raising any flags. It would also help to know which specific build the were looking at.
Since What'sApp uses textsecure, can we be sure that they are blind to the content of our messages? Is there any way for them to get the key, still claim it's e2e encrypted, except for when they want to hand the key over to various states etc?
- 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