Hint: backdoors
I wouldn't trust any federally approved encryption. From any country.
I wouldn't trust them, but I WOULD use them, given no other choice to reach the users I'm after. But always assume zero trust. With any computer thing, zero trust. Computer systems and those who orchestrate them are sneaky little devils.
That's the difference between "you have to trust WeChat" and "anyone can read your chats". Of course you may not personally be interested because you don't personally use WeChat, but for the billion active users who do, I think it should matter.
>The name 996.ICU refers to "Work by '996', sick in ICU", an ironic saying among Chinese developers, which means that by following the "996" work schedule, you are risking yourself getting into the ICU (Intensive Care Unit)
Bad non-end-to-end encryption is exactly that: "anyone can read your chats". That's not what the research found, it's just the implication of your original statement.
- against random 3rd party, even WeChat is ok
- against random black hats, most of chat software is ok, maybe even WeChat
- against gov agencies, nothing is going to protect you
When I am in China, i happily use WeChat including the gazillion of services available through it. Buying metro pass, ordering food, getting a battery pack and so on.
Btw no country could replicate this outside of China, which is an interesting phenomenon. We have endless ads including actual scams and malware distributed by Google Ads yet I cannot buy train tickets in the EU through a single app and order food as well, let alone getting a cab. It would be great though.
Off topic (or is it?): While back a western journalist in China reported that her wechat account was banned 10 minutes after changing her password to "fuckCCP"...
Signal and Matrix can be pressured with a rubber hose if there’s enough desire. And I imagine bureaucratic equivalents exits for iMessage and WhatsApp. But the CCP can offer genuine protection to WeChat executives.
A quick skim of the referenced document did not show where NIST recommended against the use of deterministic IVs. The document actually spends a significant amount of text in discussing how one would do such a thing. Did I miss something?
>Lack of forward secrecy
The article mentions that the key is forgotten when you close the app. Probably enough forward secrecy for most people.
>Since AES-CBC is used alongside PKCS7 padding, it is possible that the use of this encryption on its own would be susceptible to an AES-CBC padding oracle, which can lead to recovery of the encrypted plaintext.
This is a messaging app. Is there actually an available oracle? Does the implementation even generate a padding error?
[1] https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli...
How does the 'rubber hose' threat apply to Matrix? So long as you are in control of your home server (or at least use a home server you trust) I am not sure who your advisary would pressure.
That is not how cryptography works.
If you use proper end-to-end encryption (e.g. the Signal protocol), and assuming that you use it properly, then the server does not have access to the content of the encrypted messages. So the server cannot be pressured, period. So the Signal protocol is strictly better than a protocol that is audited and found wanting (TFA talking about the WeChat protocol here).
I didn't. I answered to what you wrote, which I quoted. But I can quote it again:
> I don't really feel like I care a whole lot between good non-end-to-end encryption and bad non-end-to-end encryption.
Not even talking about server side, things are just grim there.
PRC seems to like their home-grown cryptography gated behind language barrier. Maybe they're hedging on bet that enough diverse implementations better than eggs in single basket. Or the amount of Chinese fluency decreasing in west going to add another layer of security/obscurity. Ultimately who knows, other than PRC would be idiotic to listen to OTF-ICFP funded recommendations, a program that avoids "focus" on countries with minimal information controls, i.e. if there's a reason not to trust western scrutinized crypto systems, you likely won't find it from OTF and citizenlab.
What I would like to see are similar efforts directed at the tower of complexity that is the modern TLS stack. From the Snowden leaks we know that the NSA has tried to break cryptographic algorithms for decades via their project Bullrun, and that they bribed the RSA to default to their compromised algorithm. From the recent XZ incident we also know that supply chain attacks can be very sophisticated and difficult to detect.
How likely is it that the protocols we consider secure today are silently compromised by an undetected agent? Should we just assume that they are, like a sibling comment suggested?
I'm frankly more interested in knowing if there is oversight of these complex technologies that could possibly alert us of any anomalies of this type, so that we don't have to rely on whistleblowers or people who happen to notice strange behavior and decide to look into it out of curiosity. Too much is at stake for this to be left up to chance.
Trust in a crypto system is established by having multiple adversarial parties use it and the system being open to attack for many years without success.
Now of course I personally don't check the app shipped to me from the Google Play Store, but at least I could!
It's not that I disagree with your point at all. There are still many places for world powers to compel companies to spy on users (in both hardware and software). Just want to call out that Signal is doing pretty much the best they can.
Regarding padding oracles: it is most definitely not necessary for a target to generate a "padding error", or even an explicit error of any sort, to enable the attack.
I would be happier if there were fewer vague assertions in these sorts of writeups...
Additionally, it's unlikely that the protocol has government-mandated vulnerabilities, as such weaknesses could potentially allow foreign governments to spy on WeChat users that are abroad. The Chinese government doesn't need such weaknesses, as they have access to the servers.
Because you only get 96 bits of nonce space with vanilla GCM, there's common advice to use a counter as the nonce.
Security researchers need to stop beating the dead horse. The encryption mechanism is mostly used for compliance or certification. In fact many corp-intranet middleboxes can decrypt wechat communications, it's not a bug, it's a feature.
IRL people just treat wechat as somekind of Discord with payment options. If you say something slightly wrong your account would instantly get into trouble. Just assume your wechat chat records are public one way or another.
If you think about it, no it's not in this case.
The "end" you are refering to here, are mostly Chinese android phones.
The system just hook into your apk, read your (encrypted) sqlite3 local data, or screen-read your UI for content.
Even the Wechat realized how badly the landscape was, so they even rolled rolled out inhouse "input method" for "privacy conerns"
as I commented on other thread, they don't even bother with network protocols.
They just mandate install spyware on your end devices. So E2EE won't help here.
Chinese Android ROMs are notorious for this. Even the phone manufacturers are collecting data
https://stulle123.github.io/posts/kakaotalk/secret-chat/
https://stulle123.github.io/posts/kakaotalk-account-takeover..., https://news.ycombinator.com/item?id=40776880
Wondering if Line is next up!
Do we really know system hasn't been attacked without success when there's frequent PRC penetration in the news. What we do know is west/US has advtanges along the hardware/software stack, so smart for PRC to obfusgate and add complexity at points they can control. And that one of OTF's explicit mission, especially ICFP funded fellows is to undermine PRC controlled web - it would be incredibly dumb for PRC to take their advice seriously.
Oh dear, I need to rant about this.
Everyone and their grandma know in their guts that the ccp keep every single thing you ever send. So why on earth do wechat not back up your convo (a bog standard feature that is available to even e2ee messengers) when you need to switch to a new phone? Yes, I know you can transfer data locally (with unintuitive process since wechat does not support simultaneous login on multiple devices) but what happens if your old phone outright died? I already relinquish all my privacy to the overlord so can they at least give us back some usability instead of this archaic pos?
Just need to vent my recent painful experience.
But why are Chinese companies making their own security protocol / libraries rather adopting "cryptographic best practices"? Do they actually think that common crypto libraries are flawed? Or is this a part of China's deep tech / self-sufficient efforts?
One of my family members who lived in China was involved in a Ponzi fraud couple years ago. They told me that when they entered the interrogation room, officers had already printed out their WeChat chatting history, even before they handed out their phone.
But first, consider the CCP. The CCP has nearly 100 million members. That's a lot of people. More than many countries. It's not a very exclusive club. Clearly such a large organization cannot be considered as a united whole. It's not just whether "the CCP can read it" it's about which part of the CCP can read it.
Can the low ranking CCP member read the wechat message of the high ranking member fucking his wife? Maybe not? But maybe he would like to? Maybe he knows a mathematician that can help him for a reasonable sum of money? Or maybe someone wants to do a bit of corporate espionage?
In other words the inner core of the party wants nobus, whereas the periphery has incentives to undermine it.
There are many scenarios where the existence of an official investigation as evidenced by said audit logs is undesirable for a variety of reasons.
Back in those days where the CN internet infrastructure as we see today was laid down, devs and PMs literally didn't know for sure what were they doing, but they still worked overnight because it the new features must be shipped before next weekend.
And since the services worked pretty well until today it's kinda better to keep the s__tpile there and don't change it. Also there's a lot of unmaintained 'PWA's in the wild that relies on legacy APIs that you dare not to break.
In Western countries, yes - but even there, abuse and evasion of audit trails is quite common. The most infamous scandal here in Germany was around a cop station that more than not resembled a pig sty when it comes to procedures [1] - after the address of a lawyer representing the victims of the far-right NSU terror crew got leaked to another far-right terror cell, the audit trail led to a precinct in Frankfurt but went cold there as supposedly, the cops there all used a shared account of one of them. IMHO, every single one of these cops should have faced a year or two in jail for that stunt.
[1] https://taz.de/Ermittlungen-zu-NSU-20-eingestellt/!5989941/
This is actually a big problem with all the web-based stuff where you re-download your client everytime you use it.
Now for an open source mobile app, you can actually compile it from source without having to disassemble. But of course it's not practical to audit it yourself. However, if the same binary is distributed to millions of people, you only need one of them to see the exploit.
If Signal updated the app to send the key, it would do it for millions of people through the Play Store. That's risky. Unless Signal convinced Google to send a specific binary to a specific user of course, but that's harder.
If, however, you don't send messages you would like to send because you don't trust the service, then it is true that you are not trusting the service, but you are not using it (for those sensitive messages) either.
As soon as you actually use something that matters, you have to trust it. Sending sensitive messages over a system that you don't trust while admitting you don't trust it is... weird.
The comments on MMTLS don't seem that terrible. Is it really a problem to generate an IV once per connection and then increment it? My understanding (which could be wrong) is that's pretty much how people use AES-GCM? Maybe there's a concern about how they generate the IV, but that isn't stated or was lost in translation.
The comment about forward security on shortlink is that that's all in early data, so the PSK is problematic. It'd be early data with a PSK for TLS 1.3 too; eliminating a round trip for crypto establishment is a clear goal to reduce latency in message submission. The comment about longlink connections being long feels like it'd be a problem in TLS 1.3 as well.
From what I can tell, this report is lacking details (which may be in the original chinese report), but MMTLS looks like WeChat checked out the drafts of TLS 1.3 and did something roughly equivalent, and then tunnels it through whatever connectivity they have. Could they have come back after TLS 1.3 exited draft and redo it with a standard? sure; does it gain much? probably not. Switching to QUIC (or TCP fast open) may enable a single round trip for connectivity and crypto establishment, but there needs to be a fallback to regular TCP, because not all clients have UDP connectivity.
Then there's issues with the 'business layer' encryption, but that's not MMTLS.
If you set your clients and servers to TLS 1.3 only (which I consider the modern TLS stack), you only have a handful of ciphers to choose from (AES128-GCM, AES256-GCM, and ChaCha20-Poly1305), which avoids any issues with CBC constructions. Most of your issues are going to be around x.509 certificate processing, because TLS protocol and ciphers are easier to use correctly than in the past, but x.509 hasn't changed significantly.