241–250 of 350 posts
Just to get a sense of the track record here, Signal Protocol powers: * Facebook/WhatsApp * Google/Allo * Microsoft/Skype * Signal Signal is also the basis for the protocols for Wire (Proteus) and Matrix (Olm).
Can't say I am really happy about it. The more the Signal protocol is used the more money is spend on attacking it.
Earlier quoted context omitted.
>the reason Microsoft broke Skype so badly was because they used centralised servers with backdoors for countries who wanted them. That seems like pretty unreasonable tinfoil. There is no reason for Microsoft to want to give information to governments. I assume they don't pay, and the cost is consumer trust. Makes a lot of sense to rearchitect such that you can't give in to government demands.
If only consumers cared. As it stands there's very little downside to handing information over to government(s), and I would assume some upsides (back scratching). Apple might actually be making consumers care in an odd way by making it such a public issue.
https://www.wsj.com/amp/articles/apple-sets-date-for-china-d...
Just to get a sense of the track record here, Signal Protocol powers: * Facebook/WhatsApp * Google/Allo * Microsoft/Skype * Signal Signal is also the basis for the protocols for Wire (Proteus) and Matrix (Olm).
Please note that of the technologies tptacek listed, the only one which can operate in distributed fashion is Matrix.[0] Wire is attempting to pursue decentralization, but federation is not (yet) in their roadmap.[1] [0] https://github.com/matrix-org/synapse [1] https://medium.com/@wireapp/wire-server-code-now-100-open-so...
Matrix is looking good, but again not P2P only federated. This is why we are trying to do fully P2P end-to-end encryption like with https://hackernoon.com/so-you-want-to-build-a-p2p-twitter-wi... .
Earlier quoted context omitted.
And that’s why end-to-end encrypted e-mail is so very hard
I actually wrote a prototype to manage that: http://lettergram.github.io/AnyCrypt/ The problem is we need to stop worrying about end-to-end encrypted . We need something that blocks javascript, and encrypts our messages before they even enter the pipeline (there will still be meta data though). The extension I built was a POC just showing how it could be done easily with Keybase.
Earlier quoted context omitted.
If all the mobile traffic is being routed through a single Microsoft-controlled "super-duper peer", then there is no P2P traffic. Or to put it another way: If I accept the choice is between routing mobile traffic to Microsoft, or no mobile-Skype support, I don't understand how it follows that all traffic needs to move through Microsoft, or no mobile-Skype support.
Because centralized and P2P architecturally are different beasts altogether. It'd be very hard to make a protocol that essentially did both, and centralization covers all use cases, so, as a company, it makes most sense to go with that. I'm sure there were other reasons involved in the decision, I don't pretend to know them, but from a business perspective alone, you choose one connection methodology and you stick wi…
Earlier quoted context omitted.
Can't say I am really happy about it. The more the Signal protocol is used the more money is spend on attacking it.
"If you haven't been hacked by the Chinese you got to ask yourself, does the shit you're doing really even matter?" I prefer for Signal to be attacked and to matter than to be unattacked and to be irrelevant.
How does Signal's chat security compare to Keybase.io's chat? Keybase has more features, but if it's not as secure, then it doesn't matter.
Keybase doesn’t support forward secrecy. The signal protocol does, though I can’t say whether that’s true for Skype's implementation of the protocol
To add a little bit, avoiding forward secrecy was a design decision. We wanted to support adding and removing devices from your account (including removing all of your original devices, if you want), and we wanted new devices to be able to read your message history. I think those two things put together are in conflict with forward secrecy.
That said, we'd like to allow you to turn off history for some messages, and it would be nice if you got forward secrecy for those messages when you did that. We're currently in the middle of figuring out how that's going to work. One of the open problems is this sort of situation: If I have 5 devices, and one of them is a laptop that's been in the closet for 3 years and won't ever rotate its keys again, how do we avoid making that laptop a giant hole in my forward secrecy guarantees?
Just to get a sense of the track record here, Signal Protocol powers: * Facebook/WhatsApp * Google/Allo * Microsoft/Skype * Signal Signal is also the basis for the protocols for Wire (Proteus) and Matrix (Olm).
Please note that of the technologies tptacek listed, the only one which can operate in distributed fashion is Matrix.[0] Wire is attempting to pursue decentralization, but federation is not (yet) in their roadmap.[1] [0] https://github.com/matrix-org/synapse [1] https://medium.com/@wireapp/wire-server-code-now-100-open-so...
Earlier quoted context omitted.
Because centralized and P2P architecturally are different beasts altogether. It'd be very hard to make a protocol that essentially did both, and centralization covers all use cases, so, as a company, it makes most sense to go with that. I'm sure there were other reasons involved in the decision, I don't pretend to know them, but from a business perspective alone, you choose one connection methodology and you stick wi…
Very hard is a strong overstatement, nearly as dubious as saying they did it for the backdoors. It was either a license issue, patent issue, or just unwillingness to maintain the P2P code base in face of some features (mobile, conferencing) needing the centralised one too.