Here's a hard problem that I would like the world's highest paid people to solve:
Give us an app where everything, including metadata, is end-to-end encrypted and works at "web scale". No one other than the people in the conversation can know who is talking to who and when. Then figure out a way to pay the bills to run the infrastructure and pay the people working on the app and also make a profit. (A novel idea: Maybe charge people to use the app?)
The everything encrypted is a hard one, but should be doable so long as the incentives are right. For example, the money needs to be paid by the users for the product, and to keep it fully encrypted. It needs to be clear that not only is there no incentive to sell data or mine for ads, but doing so is a disincentive because it would actually lead to customer loss.
If I could raise enough money to replace my dayjob, I would totally do this. I'm guessing it's not doable, but I put together a quick Google Form to gauge interest. If anyone would be interested, please submit the form[1]
Anonymity isn't necessary. e.g. Briar isn't anonymous (you still need to trust your contacts), but it's essentially impossible for third-parties to track who is talking to who and when.
Signal doesn't allow creating multiple identities for different contexts (without using multiple phones).
And depending on your personal risk profile (e.g. journalists protecting their sources), phone numbers are extremely difficult to acquire anonymously in many countries. In most EU countries, you need to show photo ID to register prepaid SIM cards these days.
You don’t need to acquire a phone number from the country you’re in. Any phone number works on Signal. There’s no long distance.
In EU countries you can easily and anonymously get a US number via the internet that works fine on Signal. There is no requirement that the SIM card in your phone be the number you use to register on Signal, or that the number even be a GSM number.
My Signal number is a Google Voice number, for example. Anyone with access to a US GSM number can create these; many are for sale for anonymous payment methods.
It’s easy to use Signal anonymously in any country that has mostly uncensored internet.
> In EU countries you can easily and anonymously get a US number that works fine on Signal.
How? And even if that's feasible (for many people I'd argue it's too big a hurdle) it still only gets you pseudonymity.
There are some interesting encrypted messaging ideas floating around that allow you to have per-contact or even per-conversation keys or multiple identities for different contexts; Signal is just not doing much in that regard.
If I would have to be anonymous then I won’t even bother with any phone number. In fact I won’t even bother with Signal or WhatsApp. I’ll find an app or service that is e2ee and doesn’t require a phone number at all.
Because what’s even the general use case of using Signal and WhatsApp (in their current forms)?
Because then it would just be weird talking to friends and family. And with those few people you want to be totally anonymous with? Those apps and services which are already anonymous.
Will be awesome if Signal adds that feature? Yes. But even then I would still ise dedicated anonymous apps.
Even harder problem is getting the average user to care about things like end-to-end encryption. Let alone getting them to pay for it. Thats why services like Signal are not in the majority.
Give it a decade or two. The increasing amount of things we store digitally and the risk of exposure or losing them rises day by day, with it the amount of people who were credit scammed, crypto stolen, bully sharing explicit images etc, not speaking of scandals like Meta had. Not long ago people didn't care about their home being energy efficient either.
Who wants this? All the effort and few thousand users paying 20 USD / year doesn't make much profit. The world is happy with the encryption WhatsApp provides and would have been happy even if that wasn't there.
It seems really straightforward to suggest that the better way to solve this is with standard protocols and self-hosting, but I do realise that's quite hand wavy and often not very accessible.
SMTP is an example of this succeeding, as problematic as that protocol is.
It's not possible to have a "web scale" that end-to-end encrypts metadata, because part of the metadata is understanding the recipient.
If the network or server has no idea where to deliver an encrypted message, then the only way to guarantee delivery is to send all the messages to all the users to unpack to see which ones are relevant to them, which fails "web scale"
You wouldn't send via your inbox. And anyone would be able to download any inbox, the data would just be useless without the key.
There might be problems with the proposed model, but they aren't the problems you suggested.
(As an individual, you wouldn't want to download just your own inbox. But to obfuscate, you can download a random subset of inboxes that often-enough includes your own.)
And that's not something I want to have to do: download random inboxes on a limited phone data plan. As a polled service, how many times do you have a poll a minute? If I'm instant messaging, I could be pulling multiple times a seconds. How many more inboxes would I have to poll at the same time to obfuscate my actual inbox?
And if you want to be anonymous you can't filter by the last message you've received, so every time you pull your inbox, you're getting the last X time in messages. So if I have multiple active group chats, that would really start to add up.
Videos and images like every other messaging service would have to be anonymized the same way. Even 10x noise polling for a 10MB video would be too much data on phones and probably not enough to anonymous. How about obfuscating the sender? Would a sender be uploading 10x trash, not just text but also video, messages in every inbox?
Good point. Though you can probably use 'blocks' (think like hard-disk blocks) instead of complete mail boxes. You download random blocks that also contain blocks from your mailbox.
You can't just download random blocks until you get your data though, you might never download some blocks. So you need some kind of index of blocks. And your client can't generate that because the server stores all the data. So it's a server-sided index.
If you only download the index for specific users, that's no different than an inbox: if you pull the index for an inbox and don't pull all the associated blocks (including videos), that's obviously not your box.
The other alternative is downloading the entire index for every single block, which sounds even worse than just downloading random complete inboxes with videos. Especially if the blocks are going to be filled with trash inboxes filled with trash data to obfuscate the sender. Even my own blocks would get trash data including videos that I have to download to pretend it's real.
Freenet, as a distributed data store, just makes the issue worse. Now I'm expected to host images and videos that other people send. Also a distributed data store doesn't free you from downloading random inboxes either. Someone just needs to to be running enough instances to be able to track and identify you if you're only downloading your inbox.
That's why Tor makes you bounce between multiple nodes, to decrease the chance you get only nodes that belong to a tracker. Actually not sure why I didn't think of Tor as something that already fulfills all those anonymous requirements. It's also an example of the drawbacks of being completely anonymous, that network is extremely slow and will definitely not scale to anything mainstream.
Some Bitcoin SPV clients have tried solving an almost equivalent problem, but the obvious approach does not work for various subtle reasons: https://eprint.iacr.org/2014/763.pdf
Oh, it's definitely not easy to get this right properly. I just wanted to point out that things aren't as clear-cut impossible as the comment suggested.
Briar gets most of the way. And Cwtch gets all the way (except maybe the pay the people working on it).
Any sort of project that actively tries to minimize data collection will not be profitable. At least not in this current economic system. They will have to be non-profit (Signal, etc), or run by volunteers (Cwtch, Briar).
I'd love something like the Matrix [0] data model (JSON messages aggregated in an eventually-consistent chatroom CRDT) transmitted over something like simplex for metadata resistance.
The #1 thing that sounds impossible is how do tie a payment to an account anonymously? Unless you only take anonymous payments, you end up putting a credit card number on every account.
>No one other than the people in the conversation can know who is talking to who and when.
This also means the infrastructure cannot block messages. Or tell the difference between spam and legit messages. Effectively you can DDoS a client with messages.
> This also means the infrastructure cannot block messages. Or tell the difference between spam and legit messages. Effectively you can DDoS a client with messages.
Not necessarily. Eg as a simple model, assume that you 'send' a message by publishing it to something like a usenet group (and perhaps that group charges you a fraction of a cent for doing so).
There's no denial-of-service for a client that receives a lot of messages, distributed or otherwise, but still outsider don't see who is sending what to whom.
> Veilid is a peer-to-peer network and application framework released by the Cult of the Dead Cow on August 11, 2023, at DEF CON 31. Described by its authors as "like Tor, but for apps", it is written in Rust, and runs on Linux, macOS, Windows, Android, iOS, and in-browser WASM. VeilidChat is a secure messaging application built on Veilid.
> Veilid is an open-source, peer-to-peer, mobile-first, networked application framework.
> The framework is conceptually similar to IPFS and Tor, but faster and designed from the ground-up to provide all services over a privately routed network.
> The framework enables development of fully-distributed applications without a 'blockchain' or a 'transactional layer' at their base.
> The framework can be included as part of user-facing applications or run as a 'headless node' for power users who wish to help build the network.
> VeilidChat is a chat application written for the Veilid distributed application platform. It has a familiar and simple interface and is designed for private, and secure person-to-person communications.
This is doable and has been done. Briar is an example. The Tor network is used for transport and there is no central server. Even the clients don't know who is talking to who, everything is done in terms of the crytographic identity number. That means that even the users don't for sure know who they are talking to; as part of the introduction to someone you have to give the name you will know them by.
The Briar way of doing things actually solves an important E2EE usability issue. Since the cryptographic identity is the only identity, it is much harder for the user to end up using the system without a verified identity.
I just read the white paper, and I haven't seen anything about search, which would require some kind of homomorphic encryption, but I think that's pretty much an unsolved problem: for example, to be able to search message content in Proton Mail, you need to enable the creation of a local search index — it's not done server-side, which means all the messages have to be downloaded locally to be indexed.
> Message contents are authentically and securely transmitted between your devices and those of the people you’re talking to. This is, perhaps, the primary goal of E2EE, and is where much E2EE research and design work is targeted, such as the Signal protocol we use in our products (such as WhatsApp, Messenger, and Instagram Direct), or the IETF’s Messaging Layer Security protocol, which we helped to design and was recently standardized.
I imagine somewhere in the planning stages is complying with DSA by adopting MLS and allowing interoperability between WhatsApp and FB/Insta Messenger and other services.
Or reproducible builds to prove that the app I downloaded from the Apple walled garden matches the one I built myself from this known-good source code.
This assumes you trust eg Apple (to a certain degree, eg to have their hardware provide legitimate hashes, but eg not to just run a messaging services), but you want to avoid also having to trust Meta.
More generically: you might trust that a company can do the Right Thing now (or at most points in time), but you avoid having to trust that they always do the right thing at all points in time.
See how Apple famously could refuse to give law enforcement access to people's phones, because Apple deliberately designed their systems in such a way to remove that ability from their future selves.
Similarly, a company that doesn't keep any logs, can't be forced in the future to divulge those logs.
They can be forced to start keeping logs, and then be forced to divulge those. But doesn't work retro-actively and is still one extra hoop for the forcing party to jump through. And perhaps you can even set up matters such that adding this vulnerability can't easily be done in private.
Ah, yes, I was mixing up iMessage and Messenger here (too much messaging encryption news these days!) – for the case of trusting your OS and hardware vendor, but not a third-party messenger's vendor, reproducible builds would indeed be advantageous.
It's a real shame the app store does not allow for reproducible builds.
That’s a good point, but in theory only one researcher needs to confirm that an executable from a jailbroken app contains a build that’s consistent (or inconsistent!) with the published source code. We don’t all need to do it.
In theory they can force apple to serve a backdoored version to a particular region/person, which means one confirmation from a random security researcher isn't enough.
I think practically the best thing you can have is independent audits. Ideally multiple of them, over time. This is the same for open source and proprietary stuff. Otherwise, even if the code is not malicious and not backdoored, there's still no guarantee that it's not accidentally buggy.
That doesn't prevent a malicious update from coming around and just sending the entire database wherever, but nothing stops that from say, Element, if you're not actively vetting the updates. The best you can really do is hope that nobody compromises it (or that if somebody does, it gets caught as early as possible). Thankfully it seems like outright compromises to this degree are rare (as far as we know) whether the software is open source are closed source.
Basically imo it's a mixed bag. I don't see any obvious way to push the status quo vastly far forward because there's no way to really prove, especially to non-technical users who aren't cryptographers and programmers, that the software is 1. secure 2. doing what it says.
Pretty much all security is trust based. Any product you pick you trust the vendor not to fuck up or be corrupted.
You can argue then lets just use open source. Ok but is it that much of a security guarantee? Open source products are of limited functionality. It is great for web servers and frameworks, stuff developers care about. When it comes to feature rich client applications the track record is not nearly as good. Also who is going to pay the server costs?
If there are no security audits by disinterested third parties, then it can clearly not be trusted. If they want trust and can provide it, they likely would have done this. Have they?
As someone who runs an enterprise WordPress host, Facebook aren’t that surprising - loads of large organisations use WordPress either within their marketing department, or as their “second CMS” (AEM is very often the primary). We’re still seeing adoption growing too.The ones that might surprise you are banks and other financial institutions :)
Ultimately, WordPress is as secure as any other piece of software, but the ecosystem is so large and varied that there’s a low bar for many add-on plugins. A lot of enterprises build their own plugins for that reason, rather than using the full power of the ecosystem.
(Disclaimer: I’m also a member of the WordPress security team, but not speaking on behalf of them.)
Daily active users are going to grow on both platforms.
Let's consider you have Instagram users on one-side, and Facebook users on one-side.
As long as you have at least one contact using only Facebook (like your parents), then you have to be active on both platforms in order to talk to your contacts.
If the two platforms would be unified, then you would be active only on Instagram for example.
There’s probably an anti-competition angle here: with end-to-end encryption, you need a trusted central authority to distribute the public keys, which would make interoperability across different messaging services more difficult (impossible?), something that regulators have been trying to make happen.
If I owned the largest messaging networks, I would enable end-to-end encryption by default too.
Note that most E2E encryption services still let the service read your messages. Apple, Facebook, etc. can still read your messages.
This is because encryption needs keys, but when you talk to your friend over these services, under no point did you personally exchange any keys. This means that you’ve decided to let the service generate and keep the keys for you.
It’s like getting a deposit box at the bank but instead of keeping your key, you give your key to the bank to keep.
What would stop the bank from opening your box would be its own ethics policy and the quality and depth of their internal processes. They are not physically prevented from bypassing them however.
It’s still a W with these rudimentary E2E chat implementations because your ISP and government might find it a lot more difficult to read but it’s not quite exactly super strong security.
The keys could be generate on the devices and never leave them.
Of course, if the software is not open source, that's hard to police. But abstracting away the key generation from the user doesn't mean that the services can read your messages.
I know the argument is somewhat moot because they're all closed source. But with WhatsApp and Apple shipping key transparency, this isn't necessarily true anymore. You can verify that the keys that were given to your contacts are the keys that were generated on your device without needing to meet in person.
Apple says that iMessage uses asymmetric encryption, the private key of which is stored only on device. You can choose to believe they're lying, I guess, but what they are describing is indeed possible.
Until now, Apple hasn't offered any way of actually comparing what keys you are writing to, though. In other words, there was nothing technically stopping Apple (or somebody with the power to compel them) from adding additional recipient keys to your account that your or your contacts would not be aware of.
This is about to change with contact key verification and transparency, though.
You can compare verification codes on WhatsApp and (starting ~next week) iMessage [1]. And both are in the process of establishing a mechanism similar to Certificate Transparency for x509 certificates [1][2].
Read the whitepapers, the client side generates the keys and only transmits the public keys to the server. E2EE is truly end to end (as in client to client). Meta has no access to the content of your messages, same has been true for WhatsApp
They keys are still generated and kept using software they wrote.
Second, they also control who they trade the keys between.
This is contrasted to some chat apps (which are painful asf to use) where you have to manually exchange keys, meaning you have to engage with the party you want to talk to and so you can confirm who you are really encrypting messages for. It’s physically impossible to be given the wrong person’s key because you personally had to get them.
> They keys are still generated and kept using software they wrote.
This is a prerequisite for forward secrecy, which is arguably much more relevant.
> It’s physically impossible to be given the wrong person’s key because you personally had to get them.
Does that matter at all if the (in your threat model non-trustworthy) software just exfiltrates all messages?
If you don't trust your encryption software, it's game over (unless it encrypts everything fully deterministically and you regularly audit its outputs).
Well these apps don’t even let you verify the keys even if you wanted to, so you can’t even tell if it’s being man-in-the-middle’d.
Some people said they are finally adding key transparency features to let you do that, but it should have been there since the start. Something a lot of people already use called SSH literally has had that since forever. It’s like basic 101 cryptography if you design an encrypted protocol that isn’t using a trusted third party for key verification (like certificate authorities in TLS/SSL).
If you implement ANY encrypted protocol, key verification is extremely important. If you aren’t verifying keys are possessed only by your recipient, you cannot verify who can read your message.
WhatsApp has always allowed key verification (at least since they've supported encryption), as far as I remember.
> It’s like basic 101 cryptography if you design an encrypted protocol that isn’t using a trusted third party for key verification (like certificate authorities in TLS/SSL).
SSH/TOFU is one model, PKI is another. Both have their respective merits, especially when combining PKI with certificate transparency.
I don't think this is actually true. As far as I understand it, Apple is generating an asymmetric key on client and not sending the private key in an unencrypted form at all. I am a bit fuzzy on the specific details for iCloud but IIRC they basically have your devices verify each-other and then the key exchange process happens between them. Authentication uses SRP challenges instead of traditional password authentication, which means the password itself can be used with a KDF for keychain recovery, since Apple never sees it (not in hashed for, not over TLS, not during signup, etc.)
Even with that, there are still two concerns:
- Compromised clients: either malicious updates or buggy code.
- Security design issues: for example, if iCloud can just surreptitiously add keys to your account, it can trivially make the security moot. (I am aware this is currently an issue, though apparently it is finally going to be resolved somehow.) At least this one is tamper-evident though.
I hope I'm not misrepresenting reality here. Either way, software with reasonably strong E2EE guarantees that still has decent user experience is more possible than it ever has been. The last remaining problem is account recovery, and Apple has a bit of a leg up on this one since a lot of Apple users will have multiple devices that they can use as a backup, even if they lose a device and forget their password simultaneously.
It doesn’t really matter how Apple is doing because the rules of cryptography are set in stone.
- To ensure that you message is unreadable, you must correctly encrypt the data symmetrically or asymmetrically with a key. Well we can assume Apple or Meta can do this properly.
- Second, as the sender or recipient, you MUST verify the authenticity of the key, whether you are using asymmetric or symmetric encryption.
In TLS/SSL, key verification is handled by third parties called certificate authorities.
In SSH, key verification is handled by comparing the key signature that the SSH client displays.
Most of these services right now do not do either (trusted third party or display of a key), therefore it cannot be verified overall.
(That said, some people said they are doing what SSH is doing soon.)
I’m happy Apple is doing those things to exchange your own key between your own devices. This is already way better than most services. However, that problem is orthogonal to the problem of key exchange between you and a recipient.
TOFU (Trust on First Use, e.g. what SSH is doing) is already the defacto standard. The only difference is that the warning is less annoying in Signal/iMessage (soon)/etc. Matrix and Signal also offer out-of-band verification, but since compromising TOFU requires actively compromising a user before the key exchange (and it's tamper-evident) it's not really a very big concern for a vast majority of communication.
Progress that is highly welcome, to be sure. But what about Trust?
In a world of continuous data breaches, exfiltrations, malicious Three-Letter Agencies, incompetent and decades-behind-the-curve legislators, trust is a paramount factor. Trust that a given communication system's first allegiance is to the interlocutors(A), trust that my data won't be subjected to surveillance capitalism, trust that it won't be stripped mined for reflecting advertising right back at me for useless shit I don't want, trust that I can speak my mind without needing to continuously look over my shoulder with one eye pealed for powercenter goons sicked on me by partisan logic.
If you want me to trust your system, show me the complete source code, show me the disinterested third-party security reviews, show me what can happen at the ends, show me that it's not compromised by secrecy laws, along the full chain of custody.
A problem for our age, one step at a time ..
A) See? Even this assumption is a cardinal mistake!
Edit: Trust, but verify. Trust needs to be earned.
>If you want me to trust your system, show me the complete source code
Sounds like you set yourself up to never trust anything.
I mean, do you fly on airplanes without having inspected the flight code? Or do you put your money in a bank without having inspected the accounting code?
I don't think it's necessary for everyone to fully review the complete source code themselves. But having it available for applications at a serious enough scale, would allow the community at large to proof the vendor's claims about secure encryption. And at Facebook scale I would be satisfied that I'd hear about it if the encryption turned out to be a lie.
These examples do not work. If a plane fails, everyone would know it immediately. If money disappears from my account, at least I would know it immediately. The problem with privacy is that if it's broken, I wouldn't know it. So we have to spend all our life in blind trust, and it's insufferable
Airlines and banks do have to have to prove compliance with formal standards via audit to operate. These audits often require revealing some code to regulators under NDA. So our trust in them stands on sturdy ground compared to the offerings from the big tech companies.
I don't need to see the code for it to fail my audit though:
- Phone number attached to real identity is required
Even if you did, how would you know that the airline or bank is running a binary generated from that code? Would you also need to check the compiler? How do you know which compiler was used?
I finally took off my pink-tinted glasses when I noticed they restored old deleted messages once they released the new Messenger, the one we have today which replaced old facebook chat feature.
Probably it was for my "convenience" but what I know /s.
Meta gets a lot of flak for privacy, but at the same time, they end to end encrypt the majority of communication happening globally (Whatsapp+Messenger), at cost to the company, with no obligation to do so.
If by "cost" you mean Meta being in the business of siphoning user behaviour, Meta controls the E in E2E a.k.a the apps, so it's a matter of trusting them to not do covert on-device analysis + result exfiltration.
No company is obligated to do anything. Such lack of obligation is not sufficient reason to praise companies that do the bare minimum to keep user data safe. Sure they aren't obligated but how on earth does that matter?
If E2EE is “the bare minimum”, how are there so many successful and thriving companies who don’t do it? And why are you even on HN, which doesn’t do it?
This is at the same time as they've announced they're getting rid of encrypting their outgoing messages with PGP! (If you add your public key of course!)
I was always very impressed by this-- every service that sends emails should support this. Even banks don't!
This is because hackers were using this to lock people out of their own accounts. They would add a PGP key and then the user could no longer read any emails from FB to recover their account. There are maybe alternative solutions, but it's not a bad reason to remove it IMO.
If they can set the PGP key they can also change the email. If the account recovery team allows access to recently removed emails as part of the recovery process then it should also allow contacting those addresses without a recently added PGP key.
Logically adding a PGP key is equivalent to changing the email, the previous person can't access the messages anymore. If the recovery process handles these cases differently it is a flaw in the process.
I am curious why it was very difficult for messenger to implement E2EE by default. iMessage has been doing it* (with a giant asterisk because there are flaws in the way Apple markets its E2E on iMessage but in general it has something there). The implementation they're describing on the blog seems very similar to iMessage (keys stored on a server so that syncing is possible
Asides from iMessage, they pretty much have most of this working for WhatsApp from the perspective of the user. The challenges they've mentioned seem like they've mostly been solved in WhatsApp? I could be totally naive here though.
Enabling E2EE has historically required usability tradeoffs (no multi-device, no backups, chat transcripts are stored on device only, etc). It took them this long to make it seamless.
I knew a guy that used deep packet inspection in a service[1]. He told me that back in ~2016, when using WhatsApp, the text was encrypted but nothing else was. If you sent a picture, it was in clear text.
I don't know if this is still true, but because of this, I have serious doubts about anything security related coming out of FB.
[1] Being intentionally vague here as to not dox him.
WhatsApp was/is heavily scrutinized, and it's fairly easy to sniff your own network traffic. It's unlikely that "some guy" and no one else discovered that WhatsApp was not encrypting content.
Their history approach is interesting, supporting key rotations as well.
However, metadata is still un-encrypted, same as on whatsapp. Meta knows who you talk to, and when - this is juicy enough for both ad-targeting, and government surveillance.
Also I believe they create an id on device for the media and can identify (known) images are going back and forth. Don't know why they couldn't use this for targeting even though "the data is encrypted"
Exactly. This is pure marketing. "Normal" people do not know the difference and there is greater chance that they stay in Meta apps instead of switching.
I would say that people have currently major misunderstanding between what is more important.
Let's imagine a situation where all the messages from Meta's platforms are leaked.
On other scenario message content is plaintext, but senders, receivers, timestamps and locations are encrypted (on top of app usage behaviour).
On the other scenario, all the contents are encrypted, but the metadata is public.
We would know to whom everyone, in anytime, in any location, in which interval has talked to.
As a thought experiment, I’m interested in people listing metadata that fits the legal definition and teasing out types that the public would probably not think is metadata.
I’ll start first off the top of my head:
- The (real) identity of you and every person you talk to
- The time of the messages
- The location they were sent from
- The specific device used to send them
- A sentiment analysis: were the messages positive? Negative? Depressed? Anxious? Sarcastic?
- A description of the pictures that were sent (for example by an on-device AI model)
I can never get excited about E2EE encryption... It's not because it isn't important, it's because while I've lived I've had 2 phones die in my hands, 2 family members have lost phones (one of which is sitting at the bottom of an ocean and is clearly unrecoverable), and phones are consumables that change every few years.
I see there's some effort here on history sharing. Does that effort allow recovery of a chat history after an unrecoverable death of a primary phone? That's (honestly) the only usability thing I care about when it comes to E2EE.
The solution to this is to encrypt the cloud backup with a key derived from a password that the user remembers and can enter into a new phone. The password has to be strong because the cloud provider has the encrypted data and has unlimited time to do a brute force attack. Unfortunately strong passwords are hard to remember and users hate them.
But there is a trick to prevent brute forcing of a weak and easy to remember password like your four digit phone unlock PIN. The trick is to have a secure element chip in the datacenter, with storage encrypted by a private key that can't be extracted from the chip. The chip stores an encryption key that unlocks your backup, but it can't be extracted from the chip unless you present it with the right weak password. The chip's firmware rate limits and caps the number of attempts to unlock the backup, and if too many attempts are made it ultimately erases the key and your backup is permanently lost. So you're protected against brute forcing even with a weak four digit unlock code. If you know the unlock code from your old phone and enter it into your new phone, the secure element validates it and releases the key so you can restore the backup.
Obviously you have to trust the manufacturer of the secure element for this to work, but it's probably a good compromise for most users because losing your backups when your phone dies is quite bad. I know Google's Android backup uses this method and I believe iCloud does as well. It seems like Messenger supports this too but you have to choose your own PIN because Messenger doesn't have access to your main phone unlock code.
> The trick is to have a secure element chip in the datacenter, with storage encrypted by a private key that can't be extracted from the chip.
Ah yes, a HSM. Thus transferring the foundational "trust me bro" from Apple to someone like Thales Group.
Let's hope the HSM supports secret backup well enough to protect against server failure, and yet not so well as to allow the unlock attempt limiter to be bypassed.
> Let's hope the HSM supports secret backup well enough
Secrets backup for HSMs from a certain vendor—that you may or may not have named in your comment—I've worked with is actually the easy part. You just make copies of it and all the key data and check it into a git repo, because all of that data is protected by an HSM secret. Distributing that HSM secret among several HSMs for redundancy is also pretty easy.
The hard part is all the administration around it, specifically around custody of the smart cards that contain chunks of the HSM secret: where are they protected, where are the backups of the cards, who has access to them, coordinating sufficient card custodians to meet quorum, etc. You need to meet quorum to provision HSMs with the same secret.
The real "trust me" part of this is arguably less that the vendor backdoored the HSMs, and more that Apple pays the vendor support contracts (that hardware eventually fails) and maintains the knowledge continuity for the teams responsible for administering these HSMs as people join or leave those teams over time.
For what it's worth, this is pretty much why you don't see HSMs used often at less mature companies.
Personally, I am not attached to chat history and am totally fine with losing it. I've never backed up any chat history, and to be honest I feel weird about having 10 years old chats on my messenger account.
I might screenshot some important messages, but that's about it.
I am with you. Put aside lost phone, I still have all my older phones. Every time I start with a new phone, I use WhatsApp from scratch without restoring history/etc. I don’t back it up at all. Has not been a problem.
I backup my (encrypted) Signal conversations and sync them to some computers with Syncthing. I think it covers the "phone is at the bottom of the ocean" case.
To be fair I haven't done any disaster recovery yet, so it might not work that well...
That's not something you can ask of a casual user though. Not saying I'm one but I can already not recommend Signal to random friends and family that are not tech savy for reasons like this one.
Good for Meta and their user base! It's great to see Big Tech follow suit. We've been doing this for a decade already as only end-to-end encryption can truly protect data.
Plus, it's going to help with fighting bills like the Online Safety Bill and Chat Control when huge corporations join us; so bottom line: great news!
What Big Tech really wants is metadata. Metadata and which images are sent isn't encrypted. So this is E2EE minus what Meta wants to see. If one cares about privacy, one cares about metadata. Access to metadata equals poor privacy and is fluff encryption at best.
Absolutely right, and for that reason most tech-savvy people will still not trust Meta with their data. But that they start encrypting end-to-end is a good thing, regardless.
Possibly good for meta (if they were forced to do this by law, this means they did not want to do this them selves, which by definition makes it "not good for Meta").
Certainly not good for their user base, as (as many pointed out) it's not safe if the clients are all closed source. This promotes a false sense of security, which is worse than an understood lack of security.
So practically it means just logging in to a different device is not enough to get history, you have another logging in mechanism for that? (recovery code)
398 comments
[ 4.4 ms ] story [ 281 ms ] threadGive us an app where everything, including metadata, is end-to-end encrypted and works at "web scale". No one other than the people in the conversation can know who is talking to who and when. Then figure out a way to pay the bills to run the infrastructure and pay the people working on the app and also make a profit. (A novel idea: Maybe charge people to use the app?)
If I could raise enough money to replace my dayjob, I would totally do this. I'm guessing it's not doable, but I put together a quick Google Form to gauge interest. If anyone would be interested, please submit the form[1]
[1] https://docs.google.com/forms/d/e/1FAIpQLSe1sl5MI1Mxna6RBTXB...
> Maybe charge people to use the app?
Who will pay for a service that's offered for free by at least 3 major messaging apps?
This is what I do.
Signal doesn't allow creating multiple identities for different contexts (without using multiple phones).
And depending on your personal risk profile (e.g. journalists protecting their sources), phone numbers are extremely difficult to acquire anonymously in many countries. In most EU countries, you need to show photo ID to register prepaid SIM cards these days.
In EU countries you can easily and anonymously get a US number via the internet that works fine on Signal. There is no requirement that the SIM card in your phone be the number you use to register on Signal, or that the number even be a GSM number.
My Signal number is a Google Voice number, for example. Anyone with access to a US GSM number can create these; many are for sale for anonymous payment methods.
It’s easy to use Signal anonymously in any country that has mostly uncensored internet.
How? And even if that's feasible (for many people I'd argue it's too big a hurdle) it still only gets you pseudonymity.
There are some interesting encrypted messaging ideas floating around that allow you to have per-contact or even per-conversation keys or multiple identities for different contexts; Signal is just not doing much in that regard.
You’d need multiple phones and a phone number per context to be actually anonymous. That’s just not practicable for many people, I’d say.
Because what’s even the general use case of using Signal and WhatsApp (in their current forms)?
Because then it would just be weird talking to friends and family. And with those few people you want to be totally anonymous with? Those apps and services which are already anonymous.
Will be awesome if Signal adds that feature? Yes. But even then I would still ise dedicated anonymous apps.
https://waku.org/
https://github.com/waku-org/nwaku
SMTP is an example of this succeeding, as problematic as that protocol is.
If the network or server has no idea where to deliver an encrypted message, then the only way to guarantee delivery is to send all the messages to all the users to unpack to see which ones are relevant to them, which fails "web scale"
There might be problems with the proposed model, but they aren't the problems you suggested.
(As an individual, you wouldn't want to download just your own inbox. But to obfuscate, you can download a random subset of inboxes that often-enough includes your own.)
And if you want to be anonymous you can't filter by the last message you've received, so every time you pull your inbox, you're getting the last X time in messages. So if I have multiple active group chats, that would really start to add up.
Videos and images like every other messaging service would have to be anonymized the same way. Even 10x noise polling for a 10MB video would be too much data on phones and probably not enough to anonymous. How about obfuscating the sender? Would a sender be uploading 10x trash, not just text but also video, messages in every inbox?
If you only download the index for specific users, that's no different than an inbox: if you pull the index for an inbox and don't pull all the associated blocks (including videos), that's obviously not your box.
The other alternative is downloading the entire index for every single block, which sounds even worse than just downloading random complete inboxes with videos. Especially if the blocks are going to be filled with trash inboxes filled with trash data to obfuscate the sender. Even my own blocks would get trash data including videos that I have to download to pretend it's real.
Ie any block could be useful for multiple inboxes and messages. See also how freenet used to do it. https://en.wikipedia.org/wiki/Freenet
That's why Tor makes you bounce between multiple nodes, to decrease the chance you get only nodes that belong to a tracker. Actually not sure why I didn't think of Tor as something that already fulfills all those anonymous requirements. It's also an example of the drawbacks of being completely anonymous, that network is extremely slow and will definitely not scale to anything mainstream.
Some Bitcoin SPV clients have tried solving an almost equivalent problem, but the obvious approach does not work for various subtle reasons: https://eprint.iacr.org/2014/763.pdf
Check out alt.cryptography (I think) if you can.
* there’s lots of free competition, including Signal, which is free and decent.
* you’d probably need to open source it if you want to convince anyone it was trustworthy
* what if you want to message somebody that doesn’t want to pay?
Of course maybe a huge company could work this out… but it seems fundamentally very hard
Any sort of project that actively tries to minimize data collection will not be profitable. At least not in this current economic system. They will have to be non-profit (Signal, etc), or run by volunteers (Cwtch, Briar).
[0] https://matrix.org [1] https://simplex.chat/
>No one other than the people in the conversation can know who is talking to who and when.
This also means the infrastructure cannot block messages. Or tell the difference between spam and legit messages. Effectively you can DDoS a client with messages.
Not necessarily. Eg as a simple model, assume that you 'send' a message by publishing it to something like a usenet group (and perhaps that group charges you a fraction of a cent for doing so).
There's no denial-of-service for a client that receives a lot of messages, distributed or otherwise, but still outsider don't see who is sending what to whom.
https://en.wikipedia.org/wiki/Veilid
> Veilid is an open-source, peer-to-peer, mobile-first, networked application framework.
> The framework is conceptually similar to IPFS and Tor, but faster and designed from the ground-up to provide all services over a privately routed network.
> The framework enables development of fully-distributed applications without a 'blockchain' or a 'transactional layer' at their base.
> The framework can be included as part of user-facing applications or run as a 'headless node' for power users who wish to help build the network.
https://veilid.com/
https://gitlab.com/veilid/veilid
https://veilid.com/discord
https://youtube.com/watch?v=Kb1lKscAMDQ
> VeilidChat is a chat application written for the Veilid distributed application platform. It has a familiar and simple interface and is designed for private, and secure person-to-person communications.
https://veilid.com/chat/
https://gitlab.com/veilid/veilidchat
Previously:
Veilid is an open-source, P2P, mobile-first, networked application framework
180 points 4 months ago 71 comments
https://news.ycombinator.com/item?id=37118124
Cult of the Dead Cow wants to save internet privacy with new encryption protocol
141 points 4 months ago 79 comments
https://news.ycombinator.com/item?id=37018404
https://gizmodo.com/cult-of-the-dead-cow-launches-veilid-enc...
https://github.com/simplex-chat/simplex-chat
https://github.com/oxen-io/session-android
The Briar way of doing things actually solves an important E2EE usability issue. Since the cryptographic identity is the only identity, it is much harder for the user to end up using the system without a verified identity.
Will Messenger eventually use IETF MLS?
Edit: nvm just read the last paragraph of the post
The gold standard is and probably always will be analyzing the binary itself, with disassemblers, debuggers, etc.
You could also just have the ability for your phone to reliably tell you the hash of the executable, without giving you the executable itself.
More generically: you might trust that a company can do the Right Thing now (or at most points in time), but you avoid having to trust that they always do the right thing at all points in time.
See how Apple famously could refuse to give law enforcement access to people's phones, because Apple deliberately designed their systems in such a way to remove that ability from their future selves.
Similarly, a company that doesn't keep any logs, can't be forced in the future to divulge those logs.
They can be forced to start keeping logs, and then be forced to divulge those. But doesn't work retro-actively and is still one extra hoop for the forcing party to jump through. And perhaps you can even set up matters such that adding this vulnerability can't easily be done in private.
It's a real shame the app store does not allow for reproducible builds.
That doesn't prevent a malicious update from coming around and just sending the entire database wherever, but nothing stops that from say, Element, if you're not actively vetting the updates. The best you can really do is hope that nobody compromises it (or that if somebody does, it gets caught as early as possible). Thankfully it seems like outright compromises to this degree are rare (as far as we know) whether the software is open source are closed source.
Basically imo it's a mixed bag. I don't see any obvious way to push the status quo vastly far forward because there's no way to really prove, especially to non-technical users who aren't cryptographers and programmers, that the software is 1. secure 2. doing what it says.
A passing grade is a block of garbled encrypted mess for which they have no unlock key.
You can argue then lets just use open source. Ok but is it that much of a security guarantee? Open source products are of limited functionality. It is great for web servers and frameworks, stuff developers care about. When it comes to feature rich client applications the track record is not nearly as good. Also who is going to pay the server costs?
I also stumbled over that; only the link from the other whitepaper is broken, the one on the parent page works.
Ultimately, WordPress is as secure as any other piece of software, but the ecosystem is so large and varied that there’s a low bar for many add-on plugins. A lot of enterprises build their own plugins for that reason, rather than using the full power of the ecosystem.
(Disclaimer: I’m also a member of the WordPress security team, but not speaking on behalf of them.)
[1]: https://news.ycombinator.com/item?id=38528306
Let's consider you have Instagram users on one-side, and Facebook users on one-side.
As long as you have at least one contact using only Facebook (like your parents), then you have to be active on both platforms in order to talk to your contacts.
If the two platforms would be unified, then you would be active only on Instagram for example.
I wonder what changed. Maybe testing showed that people actually prefer them to be separate?
If I owned the largest messaging networks, I would enable end-to-end encryption by default too.
This is because encryption needs keys, but when you talk to your friend over these services, under no point did you personally exchange any keys. This means that you’ve decided to let the service generate and keep the keys for you.
It’s like getting a deposit box at the bank but instead of keeping your key, you give your key to the bank to keep.
What would stop the bank from opening your box would be its own ethics policy and the quality and depth of their internal processes. They are not physically prevented from bypassing them however.
It’s still a W with these rudimentary E2E chat implementations because your ISP and government might find it a lot more difficult to read but it’s not quite exactly super strong security.
Of course, if the software is not open source, that's hard to police. But abstracting away the key generation from the user doesn't mean that the services can read your messages.
https://support.apple.com/guide/security/imessage-security-o...
This is about to change with contact key verification and transparency, though.
A BIG part of successful encryption is key exchange.
A successful SSL/TLS man-in-the-middle attack exchanges false asymmetric keys.
[1] https://security.apple.com/blog/imessage-contact-key-verific...
[2] https://engineering.fb.com/2023/04/13/security/whatsapp-key-...
They keys are still generated and kept using software they wrote.
Second, they also control who they trade the keys between.
This is contrasted to some chat apps (which are painful asf to use) where you have to manually exchange keys, meaning you have to engage with the party you want to talk to and so you can confirm who you are really encrypting messages for. It’s physically impossible to be given the wrong person’s key because you personally had to get them.
This is a prerequisite for forward secrecy, which is arguably much more relevant.
> It’s physically impossible to be given the wrong person’s key because you personally had to get them.
Does that matter at all if the (in your threat model non-trustworthy) software just exfiltrates all messages?
If you don't trust your encryption software, it's game over (unless it encrypts everything fully deterministically and you regularly audit its outputs).
Some people said they are finally adding key transparency features to let you do that, but it should have been there since the start. Something a lot of people already use called SSH literally has had that since forever. It’s like basic 101 cryptography if you design an encrypted protocol that isn’t using a trusted third party for key verification (like certificate authorities in TLS/SSL).
If you implement ANY encrypted protocol, key verification is extremely important. If you aren’t verifying keys are possessed only by your recipient, you cannot verify who can read your message.
> It’s like basic 101 cryptography if you design an encrypted protocol that isn’t using a trusted third party for key verification (like certificate authorities in TLS/SSL).
SSH/TOFU is one model, PKI is another. Both have their respective merits, especially when combining PKI with certificate transparency.
Even with that, there are still two concerns:
- Compromised clients: either malicious updates or buggy code.
- Security design issues: for example, if iCloud can just surreptitiously add keys to your account, it can trivially make the security moot. (I am aware this is currently an issue, though apparently it is finally going to be resolved somehow.) At least this one is tamper-evident though.
I hope I'm not misrepresenting reality here. Either way, software with reasonably strong E2EE guarantees that still has decent user experience is more possible than it ever has been. The last remaining problem is account recovery, and Apple has a bit of a leg up on this one since a lot of Apple users will have multiple devices that they can use as a backup, even if they lose a device and forget their password simultaneously.
- To ensure that you message is unreadable, you must correctly encrypt the data symmetrically or asymmetrically with a key. Well we can assume Apple or Meta can do this properly.
- Second, as the sender or recipient, you MUST verify the authenticity of the key, whether you are using asymmetric or symmetric encryption.
In TLS/SSL, key verification is handled by third parties called certificate authorities.
In SSH, key verification is handled by comparing the key signature that the SSH client displays.
Most of these services right now do not do either (trusted third party or display of a key), therefore it cannot be verified overall. (That said, some people said they are doing what SSH is doing soon.)
I’m happy Apple is doing those things to exchange your own key between your own devices. This is already way better than most services. However, that problem is orthogonal to the problem of key exchange between you and a recipient.
Messaging: https://engineering.fb.com/wp-content/uploads/2023/12/Messen...
Labyrinth E2EE storage: https://engineering.fb.com/wp-content/uploads/2023/12/TheLab...
---
Comments by:
Jon Millican https://twitter.com/JonMillican/status/1732582565884702982
Matt Green https://twitter.com/matthew_d_green/status/17325670516070893...
Alec Muffet https://alecmuffett.com/article/108588
[0]: https://news.ycombinator.com/item?id=38551993
That approach puts a lot of trust in the HSM vendor, though.
In a world of continuous data breaches, exfiltrations, malicious Three-Letter Agencies, incompetent and decades-behind-the-curve legislators, trust is a paramount factor. Trust that a given communication system's first allegiance is to the interlocutors(A), trust that my data won't be subjected to surveillance capitalism, trust that it won't be stripped mined for reflecting advertising right back at me for useless shit I don't want, trust that I can speak my mind without needing to continuously look over my shoulder with one eye pealed for powercenter goons sicked on me by partisan logic.
If you want me to trust your system, show me the complete source code, show me the disinterested third-party security reviews, show me what can happen at the ends, show me that it's not compromised by secrecy laws, along the full chain of custody.
A problem for our age, one step at a time ..
A) See? Even this assumption is a cardinal mistake!
Edit: Trust, but verify. Trust needs to be earned.
I think this is a bit extreme and not really plausible for something like messenger at its scale.
Sounds like you set yourself up to never trust anything.
I mean, do you fly on airplanes without having inspected the flight code? Or do you put your money in a bank without having inspected the accounting code?
I don't need to see the code for it to fail my audit though:
- Phone number attached to real identity is required
- Metadata is not e2e
- Contact list is not e2e
I finally took off my pink-tinted glasses when I noticed they restored old deleted messages once they released the new Messenger, the one we have today which replaced old facebook chat feature.
Probably it was for my "convenience" but what I know /s.
If by "cost" you mean Meta being in the business of siphoning user behaviour, Meta controls the E in E2E a.k.a the apps, so it's a matter of trusting them to not do covert on-device analysis + result exfiltration.
Many cybersecurity engineers passionate about this stuff have worked for Meta. They, too, would have blown the whistle at some point.
Not saying they do it, again it's about trust in the context of:
- Meta (the company, not the employees) having a bad track record
- Meta's business model being what it is (building profiles and selling tooling around that), creating tension with privacy matters
I was always very impressed by this-- every service that sends emails should support this. Even banks don't!
If they can set the PGP key they can also change the email. If the account recovery team allows access to recently removed emails as part of the recovery process then it should also allow contacting those addresses without a recently added PGP key.
Logically adding a PGP key is equivalent to changing the email, the previous person can't access the messages anymore. If the recovery process handles these cases differently it is a flaw in the process.
Asides from iMessage, they pretty much have most of this working for WhatsApp from the perspective of the user. The challenges they've mentioned seem like they've mostly been solved in WhatsApp? I could be totally naive here though.
I don't know if this is still true, but because of this, I have serious doubts about anything security related coming out of FB.
[1] Being intentionally vague here as to not dox him.
However, metadata is still un-encrypted, same as on whatsapp. Meta knows who you talk to, and when - this is juicy enough for both ad-targeting, and government surveillance.
Metadata is still data!
Let's imagine a situation where all the messages from Meta's platforms are leaked. On other scenario message content is plaintext, but senders, receivers, timestamps and locations are encrypted (on top of app usage behaviour).
On the other scenario, all the contents are encrypted, but the metadata is public.
We would know to whom everyone, in anytime, in any location, in which interval has talked to.
Which is more dangerous or damaging?
I’ll start first off the top of my head:
- The (real) identity of you and every person you talk to
- The time of the messages
- The location they were sent from
- The specific device used to send them
- A sentiment analysis: were the messages positive? Negative? Depressed? Anxious? Sarcastic?
- A description of the pictures that were sent (for example by an on-device AI model)
- A transcript of any voice memos/videos
Read receipts.
User is typing indicators.
And if you’re sending media they have on record that means they can look up the exact same media and still have it qualified as metadata
I see there's some effort here on history sharing. Does that effort allow recovery of a chat history after an unrecoverable death of a primary phone? That's (honestly) the only usability thing I care about when it comes to E2EE.
Page 33 and 34.
But there is a trick to prevent brute forcing of a weak and easy to remember password like your four digit phone unlock PIN. The trick is to have a secure element chip in the datacenter, with storage encrypted by a private key that can't be extracted from the chip. The chip stores an encryption key that unlocks your backup, but it can't be extracted from the chip unless you present it with the right weak password. The chip's firmware rate limits and caps the number of attempts to unlock the backup, and if too many attempts are made it ultimately erases the key and your backup is permanently lost. So you're protected against brute forcing even with a weak four digit unlock code. If you know the unlock code from your old phone and enter it into your new phone, the secure element validates it and releases the key so you can restore the backup.
Obviously you have to trust the manufacturer of the secure element for this to work, but it's probably a good compromise for most users because losing your backups when your phone dies is quite bad. I know Google's Android backup uses this method and I believe iCloud does as well. It seems like Messenger supports this too but you have to choose your own PIN because Messenger doesn't have access to your main phone unlock code.
Ah yes, a HSM. Thus transferring the foundational "trust me bro" from Apple to someone like Thales Group.
Let's hope the HSM supports secret backup well enough to protect against server failure, and yet not so well as to allow the unlock attempt limiter to be bypassed.
Secrets backup for HSMs from a certain vendor—that you may or may not have named in your comment—I've worked with is actually the easy part. You just make copies of it and all the key data and check it into a git repo, because all of that data is protected by an HSM secret. Distributing that HSM secret among several HSMs for redundancy is also pretty easy.
The hard part is all the administration around it, specifically around custody of the smart cards that contain chunks of the HSM secret: where are they protected, where are the backups of the cards, who has access to them, coordinating sufficient card custodians to meet quorum, etc. You need to meet quorum to provision HSMs with the same secret.
The real "trust me" part of this is arguably less that the vendor backdoored the HSMs, and more that Apple pays the vendor support contracts (that hardware eventually fails) and maintains the knowledge continuity for the teams responsible for administering these HSMs as people join or leave those teams over time.
For what it's worth, this is pretty much why you don't see HSMs used often at less mature companies.
I might screenshot some important messages, but that's about it.
To be fair I haven't done any disaster recovery yet, so it might not work that well...
Source: https://support.signal.org/hc/en-us/articles/360007059752-Ba...
Plus, it's going to help with fighting bills like the Online Safety Bill and Chat Control when huge corporations join us; so bottom line: great news!
Certainly not good for their user base, as (as many pointed out) it's not safe if the clients are all closed source. This promotes a false sense of security, which is worse than an understood lack of security.
If any mobile phone that logs in can query and read the history, why cannot the server? What's the trick?
Page 33 and 34.