Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WhatsApp end-to-end encrypted backups security assessment

research.nccgroup.com

Post reply on HN
Print view View original

111–120 of 121 posts

Re: WhatsApp end-to-end encrypted backups security assessment

#111

Post by baby »

lclarkmichalek wrote: post #107
rocqua wrote: post #83

Earlier quoted context omitted.

e2e encryption does nothing about ensuring deletion. Whatsapp can simply re-deliver the same encrypted blob.

That’s called a replay attack and is absolutely something e2e encryption protects against

There are actually three different things: replays, reloading a message, and delayed messages. Replays are impossible in the signal protocol, so that’s not what happened. Delayed messages is part of signal: you can receive message2 before message1. Reloaded message is probably what happened, it doesnt work at the signal level since “deleting a message” is not something signal specifies.

Re: WhatsApp end-to-end encrypted backups security assessment

#112

Post by vorpalhex »

Thorrez wrote: post #69
vorpalhex wrote: post #27

Earlier quoted context omitted.

Still hit the issue with large media that doesn't fit in memory and your gain is still minor (resist a compromised filesystem.. maybe.. if they didn't compromise the binary too)

How does that hit an issue with large media that doesn't fit in memory? The encrypted media is on flash. The key is in memory. The key is small.

I have 1gb of ram. I want to watch a 4gb video file that's encrypted, starting at 0:32 and I want to jump back to that timecode a few times.

You can't check chapter markers or frame counts because they are encrypted.You can't usually partially decrypt a file either.

Re: WhatsApp end-to-end encrypted backups security assessment

#113

Post by omegalulw »

vorpalhex wrote: post #14
ivanmontillam wrote: post #11

For the work I do, I also conducted a mini-experiment where I checked the WhatsApp security in regards to the media transmitted. In the cited documentation below ([0]), it claims that media will not be saved for either method 1 or 2 ("To stop media from all your individual chats and groups from being saved" and "To stop media from a particular individual chat or group from being saved"). I found out that the media is…

View once media is always susceptible to this problem. I can always put a capture card between my screen and the device or use a vm - or just take a picture using a second device. Likewise touching file storage makes sense, the media files have to sit somewhere. Any vaguely modern android phone has full disk encryption, so it's only apps with global filesystem access that present a threat.

> I can always put a capture card between my screen and the device or use a vm

Nope, look up HDCP. They could enforce that on desktop if they wanted to.

> or just take a picture using a second device.

Yes, but you will lose quality.

Re: WhatsApp end-to-end encrypted backups security assessment

#114

Post by grayhatter »

sneak wrote: post #103
grayhatter wrote: post #77

Earlier quoted context omitted.

Signal is not entitled to the value associated with being open source. Signal is merely pretending to be open, when in reality they are more community and user hostile than plenty of closed source or proprietary projects. Calling Signal open, is an insult to anyone actually building or supporting open source projects or protocols.

This is a false claim. All of Signal's software is released under open source licenses. The fact that you disagree with how they run their project and service is irrelevant to the fact that both the client and server are free software.

It's not a false claim. I stated an opinion. It's not even that controversial, it's a very common complaint about signal. The primary value in open source is it gives control over the code to the user. Signal releases their code, but actively prevents it's user from actually getting any benefit from it. A messenger that exists but you can't use to communicate with anyone has no value over a messenger that doesn't exist. A signal client that you can modify but then can't use to communicate with anyone else has the same issue. The protocol should be considered 'open source'. But for an encryption system, that's the bare minimum so it's not that impressive.

Re: WhatsApp end-to-end encrypted backups security assessment

#115

Post by grayhatter »

sneak wrote: post #105
izacus wrote: post #87

Earlier quoted context omitted.

> The Signal server source code(which isn't special and doesn't change that often) just had no public commits. So it was opensource... you just couldn't see the source running on the servers? Yeah, makes sense. Right.

Well seeing as you don't have access to the ME, no amount of application code being published will mean you can see the source running on the servers. This is a red herring. The client source code is the only thing that's really relevant in an e2e encryption model, anyway. Regardless, 100% of the production versions of the Signal server software have been published under free software licenses, so I'm not sure what y…

This is not true, You contain just as much if not more value from building the graph of people who communicate with each other then knowing the contents of their communication.

But I think what they're trying to say is because signal prevents any user from being able to use the signal app with servers they the user control. You're stuck with trusting the people running the servers because they say they won't do anything wrong. The whole reason you say the client is what matters is because it's something the user doesn't need to trust somebody else won't do something wrong. if I can build my own client and validate myself The security doesn't depend on blindly trusting somebody else because they say it's safe to do so.

A well designed encrypted protocol doesn't depend on blind trust in some service. The main signal app requires blind trust in the servers they control.

Re: WhatsApp end-to-end encrypted backups security assessment

#116

Post by aneutron »

Okay, my remarks on the product (the e2e encrypted backups):

> Weak 512 bits RSA key signing key

That's unprofessional at best, negligent at worse. I understand that it's quite a bit more calculations at more key lengths, but still, 512 is simply looking for trouble.

> It enforces a maximum number of user login attempts, in order to prevent brute-force of a user PIN/passphrase; after ten unsuccessful attempts to log into an account, the account is locked and the backup data is irremediably lost.

That's essentially a denial of service waiting to happen. So if another actor can access my account (e.g. has access to the telephone operator), they can destroy my backup. I would understand a delay between retries (maybe a week ?), but just throwing out the backup is just bad.

Re: WhatsApp end-to-end encrypted backups security assessment

#117

Post by wglb »

encryptluks2 wrote: post #34

I can tell you first hand, anytime a company pays a third party to do a security assessment, the result is purely what the company wants you to see. Independent does not mean that it wasn't influenced, just that it wasn't done by the company itself.

For reputable firms, this is absolutely false.

There are firms that do what you say--they write a report that says how totally wonderful it was to work with you and how wonderful it is that you quickly fixed all the informationals they found, and what a genius you were to work with them. And they happily make these reports public.

Reputable firms will write savagely brutal reports when warranted.

Re: WhatsApp end-to-end encrypted backups security assessment

#118

Post by novok »

grayhatter wrote: post #115
sneak wrote: post #105

Earlier quoted context omitted.

Well seeing as you don't have access to the ME, no amount of application code being published will mean you can see the source running on the servers. This is a red herring. The client source code is the only thing that's really relevant in an e2e encryption model, anyway. Regardless, 100% of the production versions of the Signal server software have been published under free software licenses, so I'm not sure what y…

This is not true, You contain just as much if not more value from building the graph of people who communicate with each other then knowing the contents of their communication. But I think what they're trying to say is because signal prevents any user from being able to use the signal app with servers they the user control. You're stuck with trusting the people running the servers because they say they won't do anyth…

Currently you can get the metadata graph and contents of conversations for most messenger usage today.

Now with signal and other E2EE messengers, you can just get the metadata graph, maybe. Not using the standard set of servers makes you stand out in a different way metadata wise, and more vulnerable, because you don't have as much labor available to secure your personal network, which is what your hinting at. It's partly why tor is a public network, because they want more noise in metadata analysis, and why you want to use VPN providers, so it's not just "you" that is aggregating your traffic.

The 3rd era will do both in a usable way, but usable ones don't really exist yet. All you have is research messengers.

One step at a time. Perfect is the enemy of good, or something better.

Re: WhatsApp end-to-end encrypted backups security assessment

#119

Post by texasbigdata »

Toutouxc wrote: post #104
texasbigdata wrote: post #93

Earlier quoted context omitted.

Sorry, what’s a tombstone? Like add a field that says “deleted”?

Yes, it's a concept used e.g. in hash tables that use open addressing [0], where you can't delete value X because the final address of value Y may depend on whether X was present when it was being inserted. So instead of deleting X and leaving behind an empty address we change X to a tombstone that stays there forever and says "something was here and if you're looking for Y, Z or anything else, keep on looking". [0]…

Thank you

Re: WhatsApp end-to-end encrypted backups security assessment

#120

Post by Thorrez »

vorpalhex wrote: post #112
Thorrez wrote: post #69

Earlier quoted context omitted.

How does that hit an issue with large media that doesn't fit in memory? The encrypted media is on flash. The key is in memory. The key is small.

I have 1gb of ram. I want to watch a 4gb video file that's encrypted, starting at 0:32 and I want to jump back to that timecode a few times. You can't check chapter markers or frame counts because they are encrypted.You can't usually partially decrypt a file either.

If use use AES-CTR you can decrypt any arbitrary 16-byte block of data from the file as long as you know its offset from the beginning. You don't need to know any other data of the file. As long as you don't need to insert or shift parts of the file without re-encrypting, this works fine. And you have to be OK with the file being padded at the end to a multiple of 16 bytes long.

Every time you want to read some data off flash, you read it then immediately decrypt it. Any time you want to write data to flash, you decrypt it first. Checking chapter markers or frame counts will be the same as before as long as you decrypt those bytes immediately after reading them from flash.

Post reply on HN