If that were true, Bezos's case would be an example of how that approach to security is double-edged. Backdoors can be just as useful to foreign intelligence as they are to whoever pushed for their implementation.
> The encryption of Signal (=WhatsApp, FB) was funded by the US Government. I predict a backdoor will be found there within 5 years from now.
He seems to enjoy throwing out loosly supported accusations. He might be right in some of them, but stopped clocks and so forth.
He's also been accused himself of deliberately sabotaging the security of his own encrypted messenger app (Telegram). There's no real evidence, but he did hire a bunch of math PhDs to figure out encryption from first principles
> The team behind Telegram, led by Nikolai Durov, consists of six ACM champions, half of them Ph.Ds in math. It took them about two years to roll out the current version of MTProto. Names and degrees may indeed not mean as much in some fields as they do in others, but this protocol is the result of thougtful and prolonged work of professionals. [1]
Note: Signal, like TOR, is funded in part by the Open Technology Fund of Radio Free Asia, which is controlled and funded by Congress. So far there has been no public evidence that this funding has come with any malicious strings. The stated goal of the fund is to promote democracy in developing countries, and Signal and TOR are obviously in line with that overt goal. Radio Free Asia used to be a CIA front during the Cold War, but there's been no public evidence that the transfer of control away from the CIA to Congress was in any way a sham.
[0]: https://techcrunch.com/2017/09/18/signal-moxie-marlinspike-t...
Any suggestion that Telegram's cryptography is somehow comparable owing to "half of them Ph.D's in math", or that Signal's extensively-reviewed cryptography is backdoored, is pretty clearly risible.
OTF, meanwhile, funded basically the whole of the privacy-preserving cryptography field, for years (they may still, for all I know); for many years, they were simply throwing money at privacy projects to hire 3rd party auditors, none of whom were at all affiliated with OTF (how I know this is that we participated). People who claim OTF is somehow a snakey USG backdooring enterprise are saying more about themselves than they are about any kind of sophisticated understanding of how crypto software is built.
There is zero compelling reason to believe that signal is uniquely flawed.
Open source vs closed source is not meaningful here.
While there's only one vuln that have been discussed publicly at HN. The only issue is they are in russian as well.
At least one more was exposed[0] by the same person shortly after, i mean days after the initial. Over here[1] the same researcher wonders whether any other flaws exist.
And here's[2] how the self-proclaimed `part time-troll` Pavel Durov (the Telegram CEO) reacts to [1]. To me it's obvious he is being haugty towards HN community with `venerable HN cryptographers`.
To add to his general slandering approach towards competition while handling own product flaws without any transparency and publicity mind his company is now under investigation by SEC[3].
[0] https://translate.google.com/translate?sl=auto&tl=en&u=https...
[1] https://translate.google.com/translate?sl=auto&tl=en&u=https...
[2] https://translate.google.com/translate?hl=&sl=ru&tl=en&u=htt...
[3] https://www.natlawreview.com/article/let-slip-dogs-war-sec-v...
And for the paltry $200k they are offering for breaking it I'd bet you could find a magnitude more with little effort on the grey markets.
But no, absolutely no proof the underlying crypto has been broken. It doesn't need to be when government requests for data stored on their servers does more than enough.
So far, Roskomnadzor has "no urgent request" to include Viber and WhatsApp messengers in the register of organizers and distributors of information. According to Interfax, this was stated by the head of the Department, Alexander Zharov. He was asked when these companies will be included in the register. "We had a stormy substantive dialogue with the telegram messenger," the official recalled. "We are consulting with all other companies on this topic until there is an urgent request to include them in the register."
Maybe gn. Zharov uses whatsapp for chatting with his family and they didn’t like the appearance of mail.ru’s tamtam.chat.
* Group chats can only use the default encryption, not end to end encryption.
* The end to end encrypted chats are tied to a single device, and there's no sync across devices (in contrast, all chats on Wire are end to end encrypted and sync across devices within a limited time period).
The default use cases of almost all users has the chat messages stored in plain text on the Telegram servers. This is one of the reasons search (done on the server side) is quite fast on Telegram.
P.S.: Despite these limitations, I prefer Telegram for its superior UX and for not having metadata shared with Facebook. My wish is that someday Telegram makes E2E the default everywhere.
E: Well, I took a look at the desktop client with wireshark. It appears to just do MTProto on port 443, not TLS. When I use iptables to drop traffic on port 443, it falls back to MTProto over HTTP(!).
They list some alternate transports on their website, but it looks like you need to host them yourself. https://core.telegram.org/mtproto/transports
I reminisce that when Durov was questioned about the abscence of secure connection to the servers, he told it's a too much of overhead and may impact QoS badly.
Some time they rolled out an `always use https` option and buried it deep in the user preferences. Meaning most of non-tech savvy audience kept using the service unaware they are not secure.
The obvious pattern here is they tend to use plain http as a default transport unerminig established security practices.
[0] https://translate.google.com/translate?sl=auto&tl=en&u=https...
Could you expand on their usage of TLS and HTTP? Surely they don't send anything in plain-text over HTTP?
I thought they used TLS wrapping in some markets for censorship resistance, but apparently that is not the case unless you set up your own proxy.
You of all should know better than to conflate the general concept of encryption with the very nice special case that is end-to-end encryption!
> and 1:1 E2E is disabled by default.
It is not disabled in any way. It just isn't default.
There are really enough real reasons to criticize Telegram, absolutely no reason to 1. redefine words to have narrower definitions 2. Write outright misinformation.
I respect you a whole lot but your somewhat sloppy handling of facts detract a whole lot from the overall image.
When this design flaw came to be known, Telegram released a newer version where the user has more control on who can know that they're on Telegram. With that change, even if you had someone's number in your contacts list, you wouldn't know if/when they join/are available on Telegram unless they choose to make themselves visible.
From my understanding, TOR was created with the intent of hiding US intelligence communications[0]. From my naive understanding, this only works if 1) no one else can back door it (which is critical since it is presumed you're using it to hide from highly technical state actors) 2) there are a sufficient number of users that are not intelligence actors (so you can hide among them. Otherwise you get "Oh, that person connected to a TOR node, let's go pick them up and grab their computer").
Maybe I'm naive, but it seems like the crypto people and the US government have aligned interests here.
> The stated goal of the fund is to promote democracy in developing countries
With an additional alignment of interests, I think many believe that being able to "talk shit" on your leaders is a key part to democracy. And if you're able to do this without fear of your government coming after you (aka: backdoors), then you will freely acknowledge your dissent, find support, and democracy is the likely outcome. I'm not sure if that's true, but I've definitely heard intelligence people suggest that.
So even if it was controlled by the CIA, would this be an issue? It seems like it is actively in their best interest to use real encryption and no backdoors. You don't want all your potential rebels to get caught. You want them to be able to organize out of the eyes of the government that the CIA is trying to overthrow. Having a backdoor just puts a timebomb on it, and one that isn't going to last very long.
Or I guess there's another answer to this. The CIA is pretty fucking dumb. Which is a reasonable answer that I'll accept too, but I think the people working on this stuff would be well aware (since they're probably experts in hacking similarly encrypted systems)
https://support.torproject.org/about/why-is-it-called-tor/
Note: even though it originally came from an acronym,
Tor is not spelled "TOR". Only the first letter is
capitalized. In fact, we can usually spot people
who haven't read any of our website (and have
instead learned everything they know about Tor from
news articles) by the fact that they spell it wrong.> To protect the data that is not covered by end-to-end encryption, Telegram uses a distributed infrastructure. Cloud chat data is stored in multiple data centers around the globe that are controlled by different legal entities spread across different jurisdictions. The relevant decryption keys are split into parts and are never kept in the same place as the data they protect. As a result, several court orders from different jurisdictions are required to force us to give up any data.
https://telegram.org/faq#q-do-you-process-data-requests
If we register Telegram, Telegram has our master key. I am not sure they are really that secure. Yes, it makes politically hard to disclose any data, but it does not mean impossible.
OLD COMMENT:
E2e using a client that is not opensource (on a system that is not trusted) is not helping much.
E2e where the server is not open source should be okay, because the server-end can only snoop on some meta data (how much, when, what IP, chunk sizes, etc.) but not the content.
For instance, anything that can hook directly on a build machine, or artifact upload, or even just simply precompiled into one of the black-box 3rd party dependencies that basically never get recompiled.
All of these mechanism have vectors that would be easy to obfuscate and don't rely on any changes to any repo code. I think there is a good chance that a normal engineer could likely hide something that could make it into a final build product.
Now, combine that with the fact that even the most open of companies have some sort of protected infrastructure (Could be permissions on an S3 bucket, locked data-center or even just a locked away Cat-5 cable in the process. Someone high in the org could easily inject some process that could stay hidden from even the most prying of internal eyes.
Now, while I agree that it's a bit tinfoil-hat-y to believe that this actually -is- happening. I absolutely believe that the technical capability is both there and well within practical effort. And combine this with a few bad incentives it's easy to see how it -could- happen.
I'd also say it's not completely unrelated. Let's consider a hidden build machine process. Once you've hidden that, preventing modifications to the build process by people "not in the know" makes it much less likely that said process can be discovered (either on purpose or accident) If everyone can and does have full access to those build machines it increases the likelihood that someone making a modification could run into said process.
Doing it this way you only really have to control a core part of the release team to hide the slight of hand between the published version and the clean 'published' version.
Alternatively just bury the same thing deep in the codebase using techniques like people use for the Obfuscated C competition every year. Any changes could be delayed/deprioritized/handled by a team in the know about the backdoor.
These are not any individual who would do deliberately. I bet these conversations go differently for ex need to certain kinds of debugging vs the improbability of actually pulling off an attack or prioritising a release dealing and making a design decision to implement a feature in a specific way which is intended to be updated later on opening up windows for attack. They would genuinely be improbable unless someone knows that they are there and committed enough to try.
Just underfund the security department, don't adopt systems/languages that prevent the worse bugs, and keep the core protocol proprietary.
On the other side let the governments invest in operations to hack the product.
Vulnerabilities will appear and be discovered by the security analysts in your government.
Whey they suspect other countries have the same 0days they'll notify you of it and you fix it.
Also, FWIW we know that Google did this with its data center breach and likely many other cases.
At WhatsApp/Google scale the attack is extremely cost effective.
[1] https://www.zdnet.com/article/meet-muscular-nsa-accused-of-t...
There is not really any fundamental difference between abetting the data center breach and opting not to offer warrant canaries. Likely tens of thousands of Google users are searched every day due to easy FISC warrants and wide investigative nets.
The state sponsored attacks on Google would of course allow Google to plausibly deny cooperation, but obviously Google has every incentive to cooperate fully, as is evidenced by the lack of warrant canaries.
A person on StackExchange put it well
> The distinction between revealing the existence of the subpoena by action, rather than by inaction, is a false one. It's exactly the kind of cutesy legal formality that non-lawyers love to rely on, but real judges ignore. If you tell someone: "Hey, you know John Smith's three sons, Joe, Ted, and Bill? Joe and Ted are good people; they have never molested any children. As for Bill--well, I don't have anything to say about Bill." If Bill is not a child molester, you have defamed him, and you are not going to convince a judge otherwise. [1]
Here's how the EFF puts it.
> Are there any cases upholding warrant canaries?
> Not yet. EFF believes that warrant canaries are legal, and the government should not be able to compel a lie. To borrow a phrase from Winston Churchill, no one can guarantee success in litigation, but only deserve it.
I'm also not sure how warrant canaries relate to your parents' point.
The same applies to declining to cooperate with government surveillance operations. We don't really know how the government likes it when a big company obstructs its surveillance goals.
On HN today was a headline about Apple reversing course on a business decision voluntarily, simply to please government.
> I'm also not sure how warrant canaries relate to your parents' point.
The points above I believe link the two business decisions.
My point is that all indications point to Google being unbelievably cooperative with the US Government, essentially allowing whatever legal or extralegal (per Snowden) back doors were requested.
It is not much of a leap to conclude that Google was both aware and cooperative with the harvesting of unencrypted traffic. This does not mean that all employees were aware of it.
The analysis should be to discover how few employees would have had to be complicit for the attack to be carried out successfully.
There is no way that such an attack would succeed if too many were aware, since it is obviously in the extralegal (Snowden revelation) category, and since most Google employees are ethical humans, it would have provoked outrage if widely known.
This has been obvious in places like the United Arab Emirates (aka Dubai) where services like FaceTime etc. (sometimes even voice chat in games) are blocked by the government but they allow WhatsApp (but not WhatsApp voice calls).
Not a big problem if you're the top dog and most foreign countries can't do much in practice even if they have the intelligence...
does the theory suggest that US DoJ does not know how to exploit these backdoors, but other agencies (CIA/NSA, foreign intel services) do?
If anything there's incentive to do so even if they do, in creating plausible deniability.