One of the greatest heroes we have to thank are Diffie and Hellman who put up a fight when US government went against their research on public key cryptography.
But I suppose the reason NSA was delaying was they had to develop a workaround for the encryption. Remember, while public key crypto got strong in 1996 when the key lengths ended Tailored Access Operations (NSA's hacking team) was created in 1998, before DES was replaced with AES in 2001.
Now obviously it's not that simple. Phasing out weak standards has taken very long. Personally, I would love to understand what goes on in the heads of developers who still use age old primitives like MD5 and RSA-1280 (iMessage).
> I suppose the reason NSA was delaying was they had to develop a workaround for the encryption
No. Their primary purpose was never to protect anybody else but their own operations (the concept "Nobody but us" is older and broader than Wikipedia currently knows https://en.wikipedia.org/wiki/NOBUS ) especially not "common citizens". The NSA is mainly a military institution. Had they been able to get by with nobody being allowed to use crypto but they, they would have done that and continue doing.
"Often hear that the reason today’s Internet is not more secure is that the early designers failed to imagine that security could ever matter."
Related to this, you should definitely watch Moxie Marlinspike's (lead dev of Signal) talk where he tells about his discussion with Kipp Hickman, a developer of SSL: https://www.youtube.com/watch?v=UawS3_iuHoA#t=13m52s (until 16:33)
It's also unethical to solve world hunger by feeding the poor to the hungry. If defending is done not by installing firewalls, but by spying on everyone in case they do something bad, you have a huge problem.
Fully agree and I want to elaborate. After SHA-1 broke, IETF's OpenPGP work group have failed the community by wrestling hand over what hash function should be in 5th revision of fingerprint protocol. When they couldn't reach an agreement, the development of the next standard was abandoned, leaving all users vulnerable with no date for fix.
And FFS, it hasn't even got anything to do with protocol, it's something the client can do by itself. Having worked on secure messaging apps, I would never go to federated protocols. Signal's infrastructure allows rapid improvement of protocol and fast elimination of insecure protocol revisions. That's where we need to be at. Just look at the history of TLS and the potential in downgrade attacks. Old revisions die slowly. Signal can easily monitor what versions are still running, push updates to users and ensure codebase isn't bloated by code that merely represents insecure protocols.
Signal succeeds because of it's "closed" ecosystem, it doesn't suffer from the tyranny of the majority that occurs when there's disagreement about e.g. seriousness of some attack, when some feature might be risky. With Matrix, I worry developers of clients can affect choices, and the protocol is already dangerous, to ensure (backwards) compatibility with older clients and (other) protocols, Matrix is not end-to-end encrypted by default. I will eat my hat with mustard the day I see all Matrix clients support only end-to-end encryption for everything.
You mean, Matrix does not pose arbitrary limitations to clients that want to use end-to-end encryption. Clients that do not yet feature it by default, and that give huge warnings when you try to enable it. Clients that have problems with complex navigation when trying to verify fingerprints. Matrix is not the future, because at some point you're going to need to defeat metadata, and decentralized platforms can't do that. The future is in apps like Ricochet and Briar.
To be fair; Matrix's crypto is fairly solid. The key management however is a mess, and we have run late on fixing it - but we're working on it currently. The metadata concern is bogus however: we designed Matrix to evolve into a hybrid p2p/decentralised architecture in future without changing a line of clientside code, so folks who want to store their metadata on their client rather than their server can do so - https://matrix.org/~matthew/2016-12-22%20Matrix%20Balancing%... has some notes on that. In practice, we think neither pure federation (like XMPP) or pure p2p (like Riocochet) or pure centralisation (like Signal) is desirable - you want to have a hybrid of decentralisation & p2p so you can get the best of both worlds.
What are the benefits of decentralized servers over p2p?
"Metadata concern is bogus" yet the linked documentation explicitly says bridges expose metadata, and that home servers expose metadata.
One advantage of Pond-hybrid is "Supports any and all Matrix clients via the existing standard client-server API". This means the issue is desire to remain compatible with insecure clients. This is lack of agility is not needed.
I hope you fix things before it's too late and focus on Pond or other Tor hidden service based communication.
> What are the benefits of decentralized servers over p2p?
* A server-based system gives you a well-defined secure place to keep an always-on copy of your data, with whatever physical/geographic/network security model you prefer... rather than smearing it across a bunch of handsets or laptops which could get lost/stolen/run-out-of-storage etc.
* Thin-client protocols like Matrix or XMPP are going to typically use way less battery and bandwidth than maintaining a full p2p mesh on a mobile device, which is generally desirable. The way to fix that in p2p is to introduce master nodes of some flavour... at which point you're back in a hybrid p2p/federated architecture again.
* A thin-client-first approach also means that you can easily support different clients (and bots/bridges etc) rather than the client being tightly coupled to a complicated p2p protocol.
To repeat: i'm advocating a hybrid p2p/decentralised approach - not religiously pure decentralisation, nor religiously pure p2p either.
> "Metadata concern is bogus" yet the linked documentation explicitly says bridges expose metadata, and that home servers expose metadata.
My point was that in the medium/long term we have a clear route to avoid having to expose metadata on servers.
> One advantage of Pond-hybrid is "Supports any and all Matrix clients via the existing standard client-server API". This means the issue is desire to remain compatible with insecure clients. This is lack of agility is not needed.
You're missing the point. There's nothing insecure about the clients. The whole idea of the PDF is to spell out that you could swap out a federated server for a local p2p-based server (perhaps even running in the client) whilst reusing all the same clients... which now magically become p2p (if desired). This agility is very desirable indeed, given the huge amount of effort which has now gone into writing good Matrix clients like Riot, nheko, Quaternion etc.
But I suppose the reason NSA was delaying was they had to develop a workaround for the encryption. Remember, while public key crypto got strong in 1996 when the key lengths ended Tailored Access Operations (NSA's hacking team) was created in 1998, before DES was replaced with AES in 2001.
Now obviously it's not that simple. Phasing out weak standards has taken very long. Personally, I would love to understand what goes on in the heads of developers who still use age old primitives like MD5 and RSA-1280 (iMessage).