The Chinese government has direct access to the WeChat backend so it's unlikely that these weaknesses were government mandated. Probably just the result of overworked 996 developers:
>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)
> The Chinese government has direct access to the WeChat backend
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?
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.
Yes. The Chinese government likely have "front door" access rather than having to rely on capturing network traffic and exploit some hidden weakness in a protocol.
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?
Most of those devs back in 2011 were rookies, and many still are now. It would've been lucky enough for them to have even heard of the word 'asymmetric encryption'. And you can still find many public APIs in the WeChat docs (in 2022) that uses hand-written AES stuff that, unfortunately, uses ECB.
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.
China have their own crypto standard OSCCA, which uses the SM4 cipher, SM3 hash function etc instead of using the AES, ECDH, RSA algorithms everyone else does. The OSCCA standard are only approved for use in China.
WeChat is basically one of the tools the communist party uses to control the population. If something is on there it is most likely by design.
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"...
The point being made in the preceding comment is that the threat model for WeChat already overtly includes its operators being able to puncture its confidentiality. It doesn't make a lot of operational sense to introduce complicated cryptographic backdoors (such as the IV construction, which the authors say could potentially introduce an AES-GCM key/IV brute forcing attack) when you control the keys for all the connections in the first place.
And the argument is pretty weak. It doesnt cost them much to introduce cryptographic backdoors. Once they have done this they have even more control. It is then also less effort, because you don't have to deal with a company (like WeChat) directly to spy on their customers.
Look at the weaknesses in this blog post; can you tell me which ones are suggestive of a broadly-useful backdoor that would be deployed to avoid having to deal directly with Tencent, which is already controlled by the CCP?
I had my account banned for absolutely no reason (I didn't even use it to talk to anyone and was simply learning the interface myself to explain it later to a friend who was traveling to China). You can't infer anything from that story. Their "security" automation is even more paranoid than Google's, that's probably all there's to it.
The issue of accounts being banned after a password change is quite common, especially outside of China. This isn't related to the content of the new password.
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.
“The government” isn’t a single entity. Agents within the bureaucracy have to within rules and policies. And the front door access methods have things like audit trails to prevent internal abuse.
There are many scenarios where the existence of an official investigation as evidenced by said audit logs is undesirable for a variety of reasons.
> Agents within the bureaucracy have to within rules and policies. And the front door access methods have things like audit trails to prevent internal abuse.
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.
> If something is on there it is most likely by design.
It's a common mistake to overestimate the 'bad guy'. The Chinese government, like all other large human institutions, certainly does plenty of dumb stuff.
The server-side store a full plain text archive with government access is by design.
the weak encryption is NOT by design. It's due to incompetent programmers.
>Generally, NIST recommends[1] not using a wholly deterministic derivation for IVs in AES-GCM since it is easy to accidentally re-use IVs.
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?
The GCM IV thing didn't ring true to me either; in fact, the whole reason we have XAES-type constructions is to enable fully nondeterministic IVs, which don't fit comfortably in the GCM IV space.
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.
There has to be some reverse channel to do an oracle. Timing? That might not be a thing for messaging. Signal apparently also uses CBC with the same type of padding. So the same shade could be thrown in that direction if someone really wanted to do so.
I would be happier if there were fewer vague assertions in these sorts of writeups...
I'm not sure what part of Signal you're referring to, but the Signal Protocol generally uses AEAD constructions. That aside: the kind of padding is not the issue; every serious system that uses CBC uses PKCS7 padding. The issue is the lack of authenticated ciphertext, which is what enables the attack. The authenticated scheme composing CBC and HMAC in an EtM arrangement is not susceptible to padding oracle attacks. There are other error and behavior oracles for other padding schemes, and for different block cipher modes.
In this case it's just a fancy way of saying "random". What's important about a GCM nonce is that it never repeat, not that it's unpredictable (to me, a distinction between a "nonce" and an "IV"; a CBC IV must be unpredictable).
Because you only get 96 bits of nonce space with vanilla GCM, there's common advice to use a counter as the nonce.
Chinese apps don't need encryption but pretends to, the government had direct access to all clear-text data. If you can't comply your business would be fucked one way or another.
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.
Just to be clear, encryption to hide from broad government surveillance is one valid use for encryption (which WeChat doesn't have), but it is far from the only reason for encrypted communications. Common theives, abusive exes, or overbearing employers are a few others that immediately come to mind.
For one thing, Chinese government does have an incentive to enforce good encryption so that foreign adversaries cannot snoop in on important Chinese communications. Only the Chinese government has access via Tencent’s backend.
First off the Dutch are pretty important for a few reasons, their ports and cyber program being the first things that pop into my head. As for Wechat, why wouldn't Chinese officials use it? Even if they didn't use it for official work (which they do, to the best of my knowledge), just about everyone there uses it.
Cryptography has one function: to protect Chinese users from malicious Chinese ISPs. As for DNS over HTTPS, which they use in the majority of their apps to avoid hijacking by traffickers, ads, etc., the cryptography has one function: to protect Chinese users from bad Chinese ISPs and their lying DNS.
These findings are so unsurprising that the research is borderline boring.
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.
Most of the things people get dinged for in this kind of report are things that were already fixed in modern TLS.
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.
WeChat using a custom protocol like MMTLS instead of sticking with something solid like TLS 1.3 is a risky move. Rolling your own crypto almost always leads to trouble. Of course, there may be ulterior motives behind Tencent’s decision, and users have little power to change it. For an app with over a billion users, that’s pretty concerning.
The article says WeChat published a document in 2016 regarding MMTLS vs TLS 1.3. The finalized RFC for TLS 1.3 is from August 2018. There were a fair number of changes in the later drafts of TLS 1.3, and little support for it in 2016, so it wasn't a solid choice they could stick to when they needed it.
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.
I agree it's probably a mistake but I can also see another possibility:
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.
Show me the outcome and I'll show you the incentive.
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.
And even if it isn't screwed up by active malice... don't be surprised if it's screwed up by pure incompetence. South Korea's internet is still plagued by government-approved encryption standards, which, due to the deprecation of ActiveX, sometimes require installing institution-specific cryptography software to tunnel connections through a local HTTP server so it can be encrypted outside of the web browser - https://palant.info/2023/01/02/south-koreas-online-security-...
Not true, you can use something in an untrusting manner. Like assuming everything you send on the platform to be known to the government. Anyone in the USA who uses SMS should be operating like that, for example.
Hmm... if you assume that your government can read your messages but still use the service, then you trust your government to not hurt you based on that. So there is trust.
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.
My point is that trust is a nuanced concept. If you think that it's worth using, then you implicitly trust it enough to use it. Saying "I don't trust it at all but I still use it" is absurd IMHO.
I personally am not very interested in this research. WeChat is well known not to use end-to-end encryption. Considering that the app is unlikely to adopt end-to-end encryption (likely due to censorship being a business requirement, which was mentioned in the article and previously uncovered by this lab), 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. Parties that are interested in subverting this kind of encryption, such as governments, likely already collaborate Tencent to get decrypted messages from the source.
> 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.
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.
Where did you see that "anyone can read your chats" in this article? Indeed near the beginning of the article in the fourth bullet point the author states "we were unable to develop an attack to completely defeat WeChat’s encryption" right there. The only parties who are interested in expending more effort to break this kind of encryption are just governments, who can simply force Tencent to give up plaintext records.
- 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.
> 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
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.
Systems whose scrutiny/reputation is more subject to western "trust me bro". Authors had courtesy to recognize TLS drama in 2010s, and assumes it's... better/sufficient now because why, a bunch of US companies, many with teams of ex US intelligence on internal security teams is doing bulk of the scrutinizing.
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.
I don't see how the language barrier provides any security. If your threat model is foreign governments and you're rolling your own crypto you have to assume they have plenty of budget for translation. Technology is one of the main collection activities of any spy agency.
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.
Western spy agencies already overwhelmed by volume of PRC cyber activity per recent headlines, meanwhile FVEY also short of Chinese specialists, and institutions not generating enough language talent. It's less budget issue as bodies issue. Multiple adversarial parties who are still likely cooperating with intelligence - MSS isn't going to get a seat at the table/behind the scenes for western crypto standards.
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.
What do you say to observers who would see this analysis as a parallel to the huawei or Tiktok western argument, meaning, "don't let them spy on you, let us spy on you instead!!!"
Isn't this the opposite? It is warning that WeChat's security might be weak since it is using weird non-standard stuff which means everyone might be able to spy on WeChat users, not just China. If WeChat fixed this then only China would be able to spy on the users.
I wonder whether WeChat is one of the safest messaging apps because it has the strength to say no to western agencies.
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.
> I wonder whether WeChat is one of the safest messaging apps because it has the strength to say no to western agencies.
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).
Until next update will send your keys. Do you disassemble every update? I doubt it. In the end it's all about developer trust, because no popular messaging has thriving multi-client ecosystem after Jabber was abandoned. They all have "official" blessed client and some even fight third-party clients.
Not even talking about server side, things are just grim there.
> Until next update will send your keys. Do you disassemble every update?
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.
Signal does a far better job than most. They have open source clients. They sign their builds. The android build is reproducible (you can build it yourself and it will match exactly what they publish, see https://github.com/signalapp/Signal-Android/blob/main/reprod...). Presumably some people in the world do it.
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.
I have not been following the end-to-end encryption discussion in a while so please excuse my ignorance in asking...
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.
They could force them to add a backdoor in the Element build uploaded to the app store so they can use that backdoor to attack specific users. This is why we need reproducible builds and code which automatically check for discrepancies.
The Chinese government has direct access to the WeChat backend so it's unlikely that these weaknesses were government mandated. Probably just the result of overworked 996 developers:
>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)
https://github.com/996icu/996.ICU
> The Chinese government has direct access to the WeChat backend
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.
...why do you use it if there's a million superior services that do not do that and transfer your history correctly?
Network Effect is a bitch.
I'm going to guess that at least some of the people firen777 wants to message don't use those services.
Likely *can’t use those services
Fair enough... Unfortunately...
[dead]
Just my personal experience.
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.
Well there's (at least) two people involved in a chat. They could have just gotten it from the other person.
I read it as their entire chat history.
Yes. The Chinese government likely have "front door" access rather than having to rely on capturing network traffic and exploit some hidden weakness in a protocol.
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?
Most of those devs back in 2011 were rookies, and many still are now. It would've been lucky enough for them to have even heard of the word 'asymmetric encryption'. And you can still find many public APIs in the WeChat docs (in 2022) that uses hand-written AES stuff that, unfortunately, uses ECB.
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.
So they are just stupid, overworked and stuck with their own spaghetti?
China have their own crypto standard OSCCA, which uses the SM4 cipher, SM3 hash function etc instead of using the AES, ECDH, RSA algorithms everyone else does. The OSCCA standard are only approved for use in China.
Probably they think more control is still better.
meanwhile, the US gov + their buddies have access to global skype chats.
America ensures access to a whole lot more than just Skype: https://www.malwarebytes.com/blog/news/2021/12/heres-what-da...
I've heard even banks can get access to your WeChat history
Most likely, yeah. This also reminds me of the issues with KakaoTalk:
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!
WeChat is basically one of the tools the communist party uses to control the population. If something is on there it is most likely by design.
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"...
The point being made in the preceding comment is that the threat model for WeChat already overtly includes its operators being able to puncture its confidentiality. It doesn't make a lot of operational sense to introduce complicated cryptographic backdoors (such as the IV construction, which the authors say could potentially introduce an AES-GCM key/IV brute forcing attack) when you control the keys for all the connections in the first place.
Not only control keys, but control the software update mechanism (backdoor a la xz).
And the argument is pretty weak. It doesnt cost them much to introduce cryptographic backdoors. Once they have done this they have even more control. It is then also less effort, because you don't have to deal with a company (like WeChat) directly to spy on their customers.
Look at the weaknesses in this blog post; can you tell me which ones are suggestive of a broadly-useful backdoor that would be deployed to avoid having to deal directly with Tencent, which is already controlled by the CCP?
I had my account banned for absolutely no reason (I didn't even use it to talk to anyone and was simply learning the interface myself to explain it later to a friend who was traveling to China). You can't infer anything from that story. Their "security" automation is even more paranoid than Google's, that's probably all there's to it.
The issue of accounts being banned after a password change is quite common, especially outside of China. This isn't related to the content of the new password.
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.
“The government” isn’t a single entity. Agents within the bureaucracy have to within rules and policies. And the front door access methods have things like audit trails to prevent internal abuse.
There are many scenarios where the existence of an official investigation as evidenced by said audit logs is undesirable for a variety of reasons.
> Agents within the bureaucracy have to within rules and policies. And the front door access methods have things like audit trails to prevent internal abuse.
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/
> If something is on there it is most likely by design.
It's a common mistake to overestimate the 'bad guy'. The Chinese government, like all other large human institutions, certainly does plenty of dumb stuff.
Hanlon's Razor: never ascribe to malice that which can be adequately explained by incompetence or stupidity.
The server-side store a full plain text archive with government access is by design. the weak encryption is NOT by design. It's due to incompetent programmers.
>Generally, NIST recommends[1] not using a wholly deterministic derivation for IVs in AES-GCM since it is easy to accidentally re-use IVs.
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...
The GCM IV thing didn't ring true to me either; in fact, the whole reason we have XAES-type constructions is to enable fully nondeterministic IVs, which don't fit comfortably in the GCM IV space.
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.
There has to be some reverse channel to do an oracle. Timing? That might not be a thing for messaging. Signal apparently also uses CBC with the same type of padding. So the same shade could be thrown in that direction if someone really wanted to do so.
I would be happier if there were fewer vague assertions in these sorts of writeups...
I'm not sure what part of Signal you're referring to, but the Signal Protocol generally uses AEAD constructions. That aside: the kind of padding is not the issue; every serious system that uses CBC uses PKCS7 padding. The issue is the lack of authenticated ciphertext, which is what enables the attack. The authenticated scheme composing CBC and HMAC in an EtM arrangement is not susceptible to padding oracle attacks. There are other error and behavior oracles for other padding schemes, and for different block cipher modes.
> nondeterministic IVs
Can you explain what this means?
In this case it's just a fancy way of saying "random". What's important about a GCM nonce is that it never repeat, not that it's unpredictable (to me, a distinction between a "nonce" and an "IV"; a CBC IV must be unpredictable).
Because you only get 96 bits of nonce space with vanilla GCM, there's common advice to use a counter as the nonce.
Chinese apps don't need encryption but pretends to, the government had direct access to all clear-text data. If you can't comply your business would be fucked one way or another.
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.
Just to be clear, encryption to hide from broad government surveillance is one valid use for encryption (which WeChat doesn't have), but it is far from the only reason for encrypted communications. Common theives, abusive exes, or overbearing employers are a few others that immediately come to mind.
> Common theives, abusive exes, or overbearing employers
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
[dead]
For one thing, Chinese government does have an incentive to enforce good encryption so that foreign adversaries cannot snoop in on important Chinese communications. Only the Chinese government has access via Tencent’s backend.
The Dutch government is a joke they'll happily communicate via WhatsApp. But then the Netherlands is hardly a geopolitical player.
But surely Chinese officials don't use Wechat?
First off the Dutch are pretty important for a few reasons, their ports and cyber program being the first things that pop into my head. As for Wechat, why wouldn't Chinese officials use it? Even if they didn't use it for official work (which they do, to the best of my knowledge), just about everyone there uses it.
Cryptography has one function: to protect Chinese users from malicious Chinese ISPs. As for DNS over HTTPS, which they use in the majority of their apps to avoid hijacking by traffickers, ads, etc., the cryptography has one function: to protect Chinese users from bad Chinese ISPs and their lying DNS.
These findings are so unsurprising that the research is borderline boring.
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.
Most of the things people get dinged for in this kind of report are things that were already fixed in modern TLS.
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.
Oversight, yes mostly. The issue is that the stack is very complex, and who watches/pays the watchers?
WeChat using a custom protocol like MMTLS instead of sticking with something solid like TLS 1.3 is a risky move. Rolling your own crypto almost always leads to trouble. Of course, there may be ulterior motives behind Tencent’s decision, and users have little power to change it. For an app with over a billion users, that’s pretty concerning.
The article says WeChat published a document in 2016 regarding MMTLS vs TLS 1.3. The finalized RFC for TLS 1.3 is from August 2018. There were a fair number of changes in the later drafts of TLS 1.3, and little support for it in 2016, so it wasn't a solid choice they could stick to when they needed it.
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.
Is it concerning? It's not end-to-end secure to begin with.
It is insecure depending on one’s threat model. Though I agree end-to-end encryption would be the best practice.
> end-to-end encryption would be the best practice
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"
Can you articulate what that threat model would be?
You are only okay with the CCP and your recipient knowing your conversation.
That's kind of how I read it too, which makes some of the suppositions here (about the CCP inducing bad protocol design) odd.
I agree it's probably a mistake but I can also see another possibility:
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.
Show me the outcome and I'll show you the incentive.
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.
And even if it isn't screwed up by active malice... don't be surprised if it's screwed up by pure incompetence. South Korea's internet is still plagued by government-approved encryption standards, which, due to the deprecation of ActiveX, sometimes require installing institution-specific cryptography software to tunnel connections through a local HTTP server so it can be encrypted outside of the web browser - https://palant.info/2023/01/02/south-koreas-online-security-...
> I wouldn't trust them, but I WOULD use them, given no other choice to reach the users I'm after.
Which is no different from trusting them. The reality is that you have to trust something at some point.
Not true, you can use something in an untrusting manner. Like assuming everything you send on the platform to be known to the government. Anyone in the USA who uses SMS should be operating like that, for example.
Hmm... if you assume that your government can read your messages but still use the service, then you trust your government to not hurt you based on that. So there is trust.
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.
Is sending everything encrypted trusting, or not trusting, the communication channel.
My point is that trust is a nuanced concept. If you think that it's worth using, then you implicitly trust it enough to use it. Saying "I don't trust it at all but I still use it" is absurd IMHO.
I personally am not very interested in this research. WeChat is well known not to use end-to-end encryption. Considering that the app is unlikely to adopt end-to-end encryption (likely due to censorship being a business requirement, which was mentioned in the article and previously uncovered by this lab), 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. Parties that are interested in subverting this kind of encryption, such as governments, likely already collaborate Tencent to get decrypted messages from the source.
> 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.
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.
Where did you see that "anyone can read your chats" in this article? Indeed near the beginning of the article in the fourth bullet point the author states "we were unable to develop an attack to completely defeat WeChat’s encryption" right there. The only parties who are interested in expending more effort to break this kind of encryption are just governments, who can simply force Tencent to give up plaintext records.
Yep. Btw the threat model for me is this:
- 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.
Grab in SEA region could be said as one more example of such a "super app" too.
> 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
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.
Please realize, in China, you can't trust your "end" either. It's always infested with spyware with local root access.
Okay I shouldn't have used the word "bad" here. I should have used "flawed but not detrimental" just like what's described in the article.
> Where did you see that "anyone can read your chats" in this article?
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.
[dead]
[flagged]
By "western encryption" do you mean crypto systems that have been subjected to public scrutiny?
Systems whose scrutiny/reputation is more subject to western "trust me bro". Authors had courtesy to recognize TLS drama in 2010s, and assumes it's... better/sufficient now because why, a bunch of US companies, many with teams of ex US intelligence on internal security teams is doing bulk of the scrutinizing.
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.
I don't see how the language barrier provides any security. If your threat model is foreign governments and you're rolling your own crypto you have to assume they have plenty of budget for translation. Technology is one of the main collection activities of any spy agency.
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.
Western spy agencies already overwhelmed by volume of PRC cyber activity per recent headlines, meanwhile FVEY also short of Chinese specialists, and institutions not generating enough language talent. It's less budget issue as bodies issue. Multiple adversarial parties who are still likely cooperating with intelligence - MSS isn't going to get a seat at the table/behind the scenes for western crypto standards.
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.
Hello
What do you say to observers who would see this analysis as a parallel to the huawei or Tiktok western argument, meaning, "don't let them spy on you, let us spy on you instead!!!"
Isn't this the opposite? It is warning that WeChat's security might be weak since it is using weird non-standard stuff which means everyone might be able to spy on WeChat users, not just China. If WeChat fixed this then only China would be able to spy on the users.
Is there something you'd like those observers to hear?
I wonder whether WeChat is one of the safest messaging apps because it has the strength to say no to western agencies.
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.
> I wonder whether WeChat is one of the safest messaging apps because it has the strength to say no to western agencies.
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).
Until next update will send your keys. Do you disassemble every update? I doubt it. In the end it's all about developer trust, because no popular messaging has thriving multi-client ecosystem after Jabber was abandoned. They all have "official" blessed client and some even fight third-party clients.
Not even talking about server side, things are just grim there.
> Until next update will send your keys. Do you disassemble every update?
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.
Signal does a far better job than most. They have open source clients. They sign their builds. The android build is reproducible (you can build it yourself and it will match exactly what they publish, see https://github.com/signalapp/Signal-Android/blob/main/reprod...). Presumably some people in the world do it.
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.
I have not been following the end-to-end encryption discussion in a while so please excuse my ignorance in asking...
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.
They could force them to add a backdoor in the Element build uploaded to the app store so they can use that backdoor to attack specific users. This is why we need reproducible builds and code which automatically check for discrepancies.
FWIW, the current version of element (X) is published as a reproducible build on f-droid. https://f-droid.org/en/packages/io.element.android.x/
The attack on xz illustrates that even if the code is open source and the build is reproducible, well-designed attacks can still be executed.