Anton | Jul 11, 2021


This week, an anonymous hacker attempted to reverse engineer Groups and find vulnerabilities in its E2E encryption

SP2njsPI2WmIAwM - this is his/her only known name - discovered many ways in which Groups' E2EE chats are theoretically vulnerable. 4.54 patches most of them. Only one suggestion SP2njsPI2WmIAwM made (certificate pinning) has been ignored for now

Groups could be vulnerable to "Man-in-the-Middle" attacks

A very expensive attack vector can be what is called a "Man-in-the-Middle" attack (MITM).

The steps required to achieve this can vary, but the following are an example:
•Somehow obtain an SSL certificate signed by a trusted authority to impersonate the real server
•Crack your app's protocol and inner workings
•Convince the victim to go to a physical location where they control the network (for example, they would need to compromise your ISP or convince you to use their wifi). They then need to artificially redirect all your requests to their server instead of Groups. Some of your requests could be forwarded to the real Groups server, while others could be tinkered with to break into your conversations
•Initiate a conversation with you pretending to be one of your contacts. Once you have accepted this conversation, it would appear that you really are talking to your friend, and you wouldn't be able to tell that you're in fact talking to a MITM

Needless to say, doing the above is really costly. I have decided to implement a way to prevent such a scenario while using Groups' E2EE chats, but don't forget that nothing is 100% secure these days, so you are still trusting Groups with your security.

New method to prevent MITM attacks

4.54 includes a new option under Chat Settings: "Verified Keys". The mechanism is really simple: you physically scan your friend's QR code and let them scan yours.



Once you've done this, your local (hopefully secure) device will remember which real keys your contact does in fact have, and will alert you whenever you have a conversation with someone holding the same user but a different key

You will need to do this from every device you and your contact use to chat with Groups after you have both initiated a conversation you know is real. Starting a new conversation by manually deleting your current "secure" one or by adding a new device to your or your contact's user will require getting together and scanning your QR codes again

Most people won't have to worry about going to these lengths to secure their comms, but those few that really do worry about it now have this option

New RSA Key Length

4.54 upgrades RSA Key Lengths from 2048 to 3072 bits. This isn't a requirement until 2023 but I am doing this ahead of time to make sure we are on the safe side.

This means nothing for your current conversations but it does mean that you won't be able to start a new conversation with someone on different key lengths. So after you update to 4.54 you will need to wait for your contacts to also update to establish a conversation. Until they do, you will see a warning dialog each time you attempt to create a new conversation with them as in below:



Users on old (2048) key lengths will experience something similar with a slightly different warning message when they try to start a new conversation with a user who has upgraded to 3072 bits

Symmetric Encryption changed from AES-CBC to XChaCha20-Poly1305
The latest and greatest symmetric encryption algorithm is now in use: XChaCha20-Poly1305. OK, I am sure someone will have a different opinion, given how varied opinions can be when it comes to encryption. But hey, XChaCha20-Poly1305 is pretty good

New limit on email-based user searches

SP2njsPI2WmIAwM was concerned about user emails being discoverable, so a limit of 50 email-based searches/day has been introduced in 4.54. Email addresses can't be seen unless contacts share the same private, password-protected group. But SP2njsPI2WmIAwM suggested that they could be discoverable if an attacker somehow was able to obtain a client's authentication credentials and used this to brute-force the API into returning results for millions of "starts with" queries. So the new limit should prevent this

IV / AAD data wasn't truly random

A mistake in the code prevented creating key authenticated data with secure random generators (it used time-based random generators instead). This has been fixed
"Replay Attacks" were possible

"Replay attacks", or attacks were a sender withholds or intercepts a message to send it at a later date, were possible prior to 4.54

XChaCha20-Poly1305's AAD data is now in use to make sure this is no longer possible. An alert is shown to the user whenever a "replay attack" is detected