iMessage with PQ3 Cryptographic Protocol | Hacker News Reader

iMessage with PQ3 Cryptographic Protocol

security.apple.com

557 pointsgalad87267 comments

This is pretty fascinating. For easier reading, the Signal blog post [0] they link to is great.

Both Signal and Apple went with CRYSTALS-Kyber [1] as their post-quantum algorithm. If you're interested in the math, and maybe learned at some point about how classic public key cryptography is built on the idea that it's easy to multiply two primes, but hard to factor them, and how this (or other math problems) can be used as a one-way function to make encryption hard to break, the hard math problem that backs Kyber is the "learning-with-errors" [2] problem.

[0] https://signal.org/blog/pqxdh/

[1] https://pq-crystals.org/kyber/

[2] https://en.wikipedia.org/wiki/Learning_with_errors

Was the CRYSTALS-Kyber name intentionally, or accidentally, a reference to Kyber Crystals (I.e. The Lightsaber energy source?)

Absolutely a reference. Dilithium (from Star Trek) is name of their signature algorithm.

The trick to naming things is to first find a cool word/reference, and then 'reverse engineer' it as an acronym second:

* https://en.wikipedia.org/wiki/Backronym

Though you can easily take it too far; I think US legislators have been running out of reasonable backronyms :)

I'm amused by the Padmé reference as well.

I'm way out of my depth in terms of the math here.

But my 'software engineer brain' likes the ideal of using the prime factoring problem, because it's so simple to understand, and feels like some kind of universal primitive. "It's easy to multiply but hard to factor." It just seems so intuitive.

But I'm reading the 'learning with errors' wiki page and it's beyond my comprehension.

There's a weird fear in my mind that all these "post quantum algorithms" are so complicated, with such a large surface area, that they may hide flaws. While prime factoring, or even the elliptic key stuff, is so simple to comprehend.

that said, obviously the experts know what they're doing, and I'll use what they suggest. just saying that this thought has crossed my mind.

The explanation in this video is what made it click for me: https://www.youtube.com/watch?v=K026C5YaB3A

Same here: this video helped me finally understand the basics concepts underlying LWE

Thank you! This video was GREAT. I was having trouble putting it all together from the wikipedia page alone.

Well, one way to think about this is: how much abstract algebra are you keeping in your head to reassure yourself of the security of classical asymmetric cryptography? It's surprisingly deep. Some programmers are "comfortable" with it because they've been brought up being taught that "factoring" is just the way asymmetric cryptography works, but that has never really been the whole case.

Elliptic curve is not at all simple to comprehend! It's easy to implement, but the motivation for designing systems around them (the effectiveness of the index calculus on elliptic curve groups) and the discoveries made on attacking them (like the MOV attack that transforms ECDLP problems to FFDLP problems) are not at all simple.

Arguably, elliptic curve is an odder corner of mathematics than lattices.

100%. Another underappreciated point is that factoring connection is very misleading. That is, we don't know if factoring is equivalent to breaking RSA (in particular, the algorithms breaking low-exponent RSA (which one shouldn't use for a number of reasons) don't factor the modulus). It might be true that computing e-th roots (i.e. breaking RSA) is tractable while factoring is not.

Similarly, PKCS is complex but every part of PKCS is there because without it there is a concrete attack. Burt Kaliski (former chief scientist of RSA Labs) has an amazing talk which goes into detail about this: https://www.youtube.com/watch?v=sqsDKjPaJVg For example, why does RSA need randomized padding, besides the trivial IND-CPA violation? Because if you encrypt the same message to many recipients, the attacker can use Hastad's attack, which uses lattices in a deep way, to recover the message from non-randomized ciphertexts https://en.wikipedia.org/wiki/Coppersmith%27s_attack?useskin... Very much like an airline checklist in a way :-)

Another nugget in the talk: how RSA embedded a public key in their products and bootstrapped VeriSign! Can't recommend it highly enough.

The LWE problem is one level of abstraction away from the fundamental lattice problems it reduces to. It is somewhat analogous to the Diffie-Hellman problem that many constructions reduce to, which itself is related to the lower-level discrete logarithm problem.

The lattice equivalent of integer factorization is the shortest vector problem: you're given n vectors of length m, and you have to find the sum of integer multiples of those vectors that comes closest to (or a small factor away from the closest) the zero vector. Say you have the 4 vectors

    [ 3 92  4  2]
    [54  0 92 41]
    [19 91 61 48]
    [39 59 40 14].

The shortest vector that you can obtain from adding integer multiples of these vectors is [19 -8 -15 2], which you can obtain by 3*[39 59 40 14] + [19 91 61 48] - 2*[54 0 92 41] - 3*[ 3 92 4 2].

With only 4 vectors it is easy to find the solution here. But the hardness grows exponentially with the dimension, and the dimensions in cryptographically relevant lattices are in the hundreds to thousands.

I know that thinking, but learning more about RSA, I came to realize that there's a flipside of this.

People think "RSA is easy", because someone gave them a lecture of a simplified/wrong/insecure version of RSA. Pretty much all "simple introductions to RSA" you can find out there are wrong.

The truth is: RSA isn't that simple. If you want to have RSA, and want to have it secure, there's a whole bunch of things to consider. But RSA looks simple.

So lots of people go ahead and implement their RSA. And then you end up with, hey, I can break almost a third of the top 100 webpage's RSA implementations. (I'm not kidding, I did that -> https://robotattack.org/ .)

I think the fact that crystals-kyber is obviously not that simple may actually protect us. Because hopefully most peopple will end up using some hopefully well audited optimized free implementation, because they won't even have the idea that they could do this on their own.

I love that security by difficulty is the new security by obscurity, but actually secure.

Is it new? Security by difficulty _is_ security.

Yeah talking about difficulty, then you will love this: https://www.science.org/content/article/china-s-quantum-sate...

If we really wanna be security, then entailment is a good bet. I could imagine essential financial clearing, emergency infrastructure could use this level security. Don't know how feasible it is for consumer grade usage yet though.

People rolling their own crypto still makes my jaw drop.

I get people want something custom but the tradeoffs are just too great.

> There's a weird fear in my mind that all these "post quantum algorithms" are so complicated, with such a large surface area, that they may hide flaws.

That's correct (emphasis on "may", of course), and is why it's absolutely imperative to always use PQC/ECC hybrid cryptosystems rather than pure PQC. See eg [0] for a more detailed explanation.

0: https://blog.cr.yp.to/20240102-hybrid.html

There are essentially no mainstream systems that don't do this. That's why new systems deploy things like PQ3.

Do you mean:

> There are essentially no mainstream systems that don't [use PQC/ECC hybrid cryptosystems?].

If so, good. I'll admit my expectations are a bit biased from having to deal with projects that go out of their way to produce defective software (eg DRM, malicious abuse of undefined behaviour by compliers, cloudflare and other captcha-walls, etc) so I tend to assume the worst by default.

Yes. So far as I know, there's no mainstream system that has even proposed to use solely Kyber and not Kyber+ECC. It's been a built-in assumption since the earliest Chrome PQC experiments.

It's not at all clear that factoring is actually hard. I fully expect factoring to be broken classically within my lifetime. FWIW I am a practicing cryptographer.

Curiously, the "large surface area hiding flaws" is actually what happened with RSA. Examples are

1. (large) speedups in solving it in the 90s, 2. issues where if enough of your key leaks, it can all be recovered. This leakage can occur via certain side-channel attacks 3. the "easy RSA" people learn is hard to make secure, which perhaps took a decade of doing very wrong to get right. By this, I mean padding attacks on RSA.

As for understanding LWE, see for example the blog posts

https://mark-schultz.github.io/nist-standard-out/

I was reading the NIST comments and djb is not very happy with how they present things, and the other commenters seem to think he is a prick.

I want an encryption algorithm composed of 2 parts chained, such that both parts need to be broken for the whole thing to be broken.

And I'd like the US/The west to declare 1 part as secure, and I'd like Russia to declare the other part as secure.

I'm fairly confident that Russia and the US won't collude to push a known-weak algorithm.

They would not have to collude; there is no incentive for either to publicly endorse a secure algorithm. Both Russian and U.S. intelligence services want the ability to break into anything.

They would publicly endorse insecure algorithms, and then employ more secure algorithms in their own classified systems.

I think encryption quality is best evaluated by math and technical testing, not international political triangulation.

Alternatively we could use hash-based signature schemes which have been proven secure under certain assumptions about hash functions, such as SPHINCS, or ZKP based schemes along the lines of Picnic (Picnic in particular uses LowMC which is somewhat new). In that case a backup seems unnecessary.

https://kyberslash.cr.yp.to

Pretty great advertisement for Signal, as the sole cross-platform option in the PQC bucket. Does it seem likely they will match Apple here eventually?

In my experience, these markets can overlap but don’t necessarily always do so.

I message everyone via iMessage, and while I enjoy the feeling of security from the blue bubble it’s not a must-have for me. Signal on the other hand seems like a must-have for many people living under oppressive regimes or whose data is significantly more valuable than mine.

I am one data point, but that’s what I’ve noticed in my bubble.

For me, Signal is so much better for my friend or work group chats. My friends are on a mix of devices and platforms, and Signal is a lot nicer for embedded media sharing. And the auto disappearing feature is a must!

Hmm… Does signal only really work when everyone uses it? Or can you include people who are just using regular SMS?

Only Signal users. The Android app used to work with SMS/MMS until a couple years ago.

I don't think any app besides iMessage can even get permission to read SMS on iOS, there are no alternative message apps I'm aware of like with android.

It used to have SMS support but they yanked it maybe a year or so ago. The big issue on the user end was, if someone deleted Signal and you used Signal for your SMS, it would keep sending them signal messages and not SMS. So you were left not realizing you were texting essentially a dead number.

...much like iMessage.

It didn't show the icon for the message status, same as any other signal message?

The regular SMS/MMS feature was removed and for good reason. Many people cried about it but it was the right call. Messages would not be E2EE and people could easily think all messages sent through Signal are safe when they weren't.

The main things holding back Signal usage in my case is practically nobody in my social circle using it and the desktop client not being as nice as that of Messages or Telegram, the latter being particularly relevant for myself and contacts who primarily message with their computers rather than their phones.

Using Linux iMessages doesn't even have a client...

Sounds like time to become an evangelist then. I had to do this in my group and other than security a major benefit is just that getting potatos instead of pictures has significantly declined.

Here's my advice: don't sell security as the foremost feature. Sell it as "iMessage, but for everyone." You got stickers, reactions, high quality videos and images. Then mention security, it is the cherry on top.

Every single person I converted to using Signal stopped using it when SMS support was removed.

HN tends to be a younger crowd whose peers cycled through a number of social-networking and messaging apps as popularity waxed and waned. But older generations don't see any compelling reason why they should bother splitting their conversations over multiple apps, when literally everyone with a mobile has texting. Being a drop-in replacement for texting, so they could have additional features without additional hassle was the only thing that convinced them to switch and now it is gone.

I've given up evangelizing Signal, and resigned to the idea that cross-platform RCS is the only thing that will bring encryption to the majority of my contacts.

Yeah I think this was a bad move for Signal, but I didn't see that happen to my group fortunately. In Signal's defense, my understanding is that this was really an Apple thing. That Apple only lets iMessage connect to SMS so the apps were differing significantly.

I also get the fatigue. Moxie said centralized because they needed to move faster. But Signal has always moved very slow, so it does feel off. But to be fair, it's not like most messenger apps do much.

They were talking about on Android. Signal supporting SMS was never a thing on iOS.

That's my point though. That it is harder to maintain a feature that not only doesn't exist on both development platforms, but can't work on one of them.

Signal is only like 42 people.[0] You gotta triage a lot of stuff. I wish the feature still existed, but I can totally understand why they did that. I'm pretty sure not all 42 people are programmers.

[0] https://projects.propublica.org/nonprofits/organizations/824...

> I also get the fatigue.

Agreed. I put most of the blame on Google for deciding to implement RCS as a feature of Messages, rather than an Android OS library/service that any developer could use like SMS.

> HN tends to be a younger crowd whose peers cycled through a number of social-networking and messaging apps as popularity waxed and waned. But older generations

What is your definition of younger and older? Anybody born in the 70s or later experienced an ongoing procession of instant messaging choices. I would tell you it is precisely that experience that informs my apathy towards the latest and greatest Hot Thing, and makes me appreciate boring old SMS (and by extension, iMessage) that I know will just work with anyone I meet.

Are you from the USA?

I don't like splitting my conversations over multiple apps when literally everyone with a mobile in Argentina has WhatsApp. SMS costs money and having it in the same app as a free messaging platform sounds risky :P

> I don't like splitting my conversations over multiple apps

Most people don't. The issue isn't what country I live in (fuck man, I got SMS, WhatsApp, Signal, Slack, KakaoTalk, and I've even forced some people to not contact me through some apps so I could reduce). You missed the actual content of the message about how there is a reasoning for this change beyond Signal. You got to be careful with blame because there are often things upstream that cause things downstream but the fingers are often pointed at what's downstream, not upstream. We can't resolve problems if we only focus on downstream. You have to consider both. I hate it too, because it is the mental version of using multiple apps. But that's the way things are and I want to actually reduce the problems, not run around with a box of bandaids.

> resigned to the idea that cross-platform RCS is the only thing that will bring encryption to the majority of my contacts

I thought RCS explicitly wasn’t E2EE?

The current standard isn't. Google uses non-standard E2EE, and they and Apple are working on getting it standardized.

If so, how will they meet China's demand that all mobile devices support RCS, presumably because it doesn't employ E2EE?

iOS already has different behaviours inside China compared to elsewhere, for example showing Taiwan's flag or the nine-dash line in the south sea in Maps app.

Based on how those work, the answer is likely: When a SIM from a mainland mobile company is in the device, E2EE is disabled.

"iMessage, except you can't sync message history between devices because Signal feels you're a fucking idiot who can't be trusted, and that Apple's hardware security (market-leading and resistant to near-nation-state-level attacks) is insufficient."

People's eyes glaze over and they go right back to using WhatsApp, which offers nearly everything Signal does, but also full sync. Most people don't care about the differences in privacy.

We're talking about the same company who wanted to scan all your files you uploaded, right?

Uploaded? You forgot what it was about. It was on-device scanning that was the problem.

The plan was to scan (on device) files that were going to be uploaded to iCloud.

Before anyone goes evangelizing Signal, make sure to tell your iOS friends that if they ever lose their phone they lose every message they ever sent on Signal with no way to restore them, and the same applies if they ever get an Android phone (latter also true of iMessage, but WhatsApp is totally cross-platform).

While I agree with your point and I think you're right, let's remember that part of the issue is Apple.

Might be worth reading this comment from the devs[0]. I wish the feature existed too, but I get it and don't think all blame is on them. For lost devices, well... is that a bug? Where would the backup come from? Signal is anti-cloud, as they should be.

BUT, I do think people store too much data. Pictures, messages, etc. I think we're getting very little value for maintaining all of this and that it is mostly laziness. Don't get me wrong, I do it too and I like it and it does come in handy time to time, but my life wouldn't significantly change were this not the case. It's something I'll be irked about when I hit the speed bump the first time but move on quickly (like quitting Facebook). 99.999% of the time it would just result in me asking someone about something months ago and it's never been anything important (because if it was, I'd have made that information redundant, and that's not a action because Signal, that's an action because the information is important and I do this wherever that type of info comes from.) Truth is that >>99.9% of that data is junk. It's only the nuggets we care about and I think it's a bit weird we treat it all the same.

[0] https://community.signalusers.org/t/ios-backup-keeping-messa...

Can't Signal export the local messages? Wire on iOS has local export.

The post addresses that a bit, but it is a few years old now. I'm not a app dev so I have no clue about these systems. But the claim is that Apple doesn't give you a lot of control and that sounds like a very Apple thing to me. I mean aren't they well known for "my way or the highway" attitude?

One thing that the post oddly omits but has been possible and reasonably easy to implement on iOS for ages is simply bundling up messages, keys, etc into an archive in internal app storage and then letting the user AirDrop it to a Mac or another iOS device. I might be missing something but this is the sort of thing a capable engineer can have working smoothly in somewhere between an evening and a few days.

If they want to extend this transfer ability to other platforms, they could do what some comic/manga reader and video player apps have done and bundle in a tiny web server that allows the user to download/upload files with a web browser protected by a username and password, which is started/stopped as needed. As a bonus they could offer this on Android too for wireless backup management.

There’s also nothing stopping them from building Signal clients such that they’re able to directly connect to each other over the local network and do whatever transfers are required that way.

Apple doesn’t prohibit of any of these. I wonder why they weren’t explored.

> bundling up messages, keys, etc into an archive in internal app storage and then letting the user AirDrop it to a Mac or another iOS device.

Wire E2EE messenger on iOS does something similar and allows the user to save the file to any storage provider.

> There’s also nothing stopping them from building Signal clients such that they’re able to directly connect to each other over the local network and do whatever transfers are required that way.

There's also nothing stopping you (or anyone else here) from adding such a feature. Either into the official, Molly, or one of the other forks.

You may also be interested in this feature request.

https://community.signalusers.org/t/signal-airdrop/37402

The thing about message history is that many of the times it’s been useful, I’ve had no way of knowing the messages had any importance in the moment. It’s only been months or years down the road that they’re needed, by which point the person I’d been conversing with has likely forgotten the message content and so asking them again isn’t helpful.

I actually think one of the best parts about signal is the disappearing messages feature

I used Telegram during a time when I lived a cross-border and cross-platform lifestyle.

Telegram, and really Telegram on desktop, was great. I am a stubborn old man at the age of 40, and I really prefer to type on a keyboard. It had a great UI, it always delivered messages, and syncing between devices was seemingly instant. iMessage, somehow, is still not perfect at syncing between devices, and while Signal is quite good at that, it's a pain to start using on a new device, as it doesn't bring along your message history. (For legitimate reasons, mind you.)

Yeah Telegram absolutely nails the desktop experience like few other chat apps do. The way they put all the functional bits into a library to make it easy to build high quality third-party clients helps, too; while the Qt client is quite good across platforms, users also have the option of a Swift-based client on Apple platforms, a WinUI/UWP client on Windows, GTK client for GTK-based Linux desktops, etc which takes it that extra mile. Heck there’s even CLI clients for users of that inclination.

Its security is questionable but it gets users by the boatload anyway because it doesn’t consider any platform an afterthought, they all get first-class treatment. Other cross platform messengers would do well to embrace a similar philosophy.

Sure. Different projects, different goals. At every instant where Telegram had a decision to make between better user experience or user security & privacy, Telegram opted to make a better experience. Signal took significant UX hits to make the privacy promises it makes. The two projects are essentially not comparable. Like, the sane thing to compare Telegram to at this point is Matrix.

Of course, but it’s not just UX that’s being traded off but also potential for mass adoption, and evangelism is likely not enough to close the gap.

Again: different projects, different goals. What Telegram is doing is inherently viral; the platform has an emphasis on bringing huge groups of people together, and the resulting design affordances, and that's a goal that basically works against privacy in the first place. Signal's original goal is to replace intimate messaging.

People who love the Telegram affordances wish that the platform would also suffice for intimate messages. Why have two platforms, two UX's, and (most importantly) two user bases? People who live Signal wish the other thing.

But you can't have both. They are incompatible design spaces. Telegram's security story is atrocious. It's best compared with Slack, not with Signal. If you're looking to compare a serious secure messenger with Telegram, look at Matrix, which has many of the same goals.

It is important that there be a messaging platform in common (if not universal) use that is fit for purpose for secure messaging when it really matters: when the compromise a message could cost lives or fortunes. Most "secure messaging" is LARPing; it doesn't matter if the "E2EE" in a pseudonymous 500-person chat room is secure. By all means, make it harder to dragnet that channel, modernize the protocols, whatever. But you can see right away how little security really matters to these groups, whether they're on Telegram (with no group security) or Matrix (which at least tries), because messaging app affordances are all people talk about with them.

Signal UX is AWFUL if you have a work PC, a home PC, a phone, and a tablet.

Getting messages to flow across all of them is impossible.

Getting messages to flow across lots of different platforms for a single account has been a source for a number of very bad security problems in other messengers. (Recent example: Matrix, Nebuchadnezzar). Different projects, different priorities.

Signal already has the ability to register multiple devices with the same account, though. The only thing they haven't done with this is support sync of past messages. That seems like it should be much simpler than supporting multiple devices in the first place, and I'm wondering if there's some non-obvious attack that they're simply not talking about or if it just hasn't reached the top of their priority list yet.

Why is it impossible?

I've had 0 issues syncing between my iPhone/iPad/Mac... and i use the app daily.

Don’t worry, whatsapp uses the signal protocol and everybody uses whatsapp nowadays

> "practically nobody in my social circle using it"

What i did is, the people i chat with 90% of the time are those in a very small circle around me - maybe 3 people (which i think is the case for most users?)

So, i just installed Signal on the phones of these 3 people;

Problem solved: now most of my messaging happens via an app that respects my privacy.

Signal is actually pretty good for the occasional "cross-iOS/Android" video chat. Can't use iOS Facetime, don't want to use $META, google/meet is OK, but isn't quite as straightforward as "@Signal => CALL_ME".

Anyone can use FaceTime now. Non Apple devices will just join via a browser.

Which is ridiculous

What? how does that work? If you call the cell number of an Android device on facetime, what happens on the android end?

You text them a link to join the call. The Android user can’t be the one to initiate.

Oh. Ok that's never going to work.

"Hey there please click on this link to talk to me"

=> Malware! Blocked.

It’s how many Zoom and Teams calls terminate. Not saying it’s a good idea, but it’s not especially unusual.

But you don't get zoom links via _SMS_ do you?

Almost all links I get via SMS are phishing. The rest is OTP, there is sometimes a link in the same SMS but I _never_ clicked a link in an SMS...

My point is, the inhibition to click a link inside an SMS is very high with lots of users, hence I can't imagine this working well.

Also, it's purely inconvenient. You're not having a conf call at a previously agreed time, you want to call someone, this means it's spontaneous or somewhat urgent...

Most people lead up to an invitation to a video call with text messages (e.g. "When are you free for a video call?") unless they're very familiar with the other party.

thats how almost all video comm platforms work..

> The Android user can’t be the one to initiate.

That sounds like a bad joke. "Everyone can use Facetime, except if you're on a certain platform you have to ask someone on the 'real' platform to initiate the call." That's... not a viable communication method.

Nobody is claiming that FaceTime is the singular universal communications method. Certainly not Apple.

I noticed an uptick in scams using iMessage. It's (almost) obvious that you are not talking to a real human. The scheme is pretty simple: lure you to iMessage, so you feel safe, then propose moving to another chat service that is easier to run bots on (telegram, whatsapp, etc) and start a regular programming.

Do you not send messages to any Android users? That is incredibly hard to imagine for me.

My friend group is very mixed and Signal is what we use.

I thought it was a great advertisement for Signal because Signal and their protocol is public and their software is free, open source and cross-platform.

In light of that Apple's message reads more like announcement that people who can afford iPhones will now have better security and privacy when they chat with themselves.

I am not sure if I understand things correctly, but what apple did seems like a lot of work for little benefit. Symmetric encryption is not threatened nearly as much by quantum computers. Using a PQ key exchange should make adequately safe until someone breaks symmetric encryption, which seems like a high odds bet. The author of age wrote some time ago why aes128 is good enough.

But I am a classical musician so for the love of god don't listen to me.

David Basin and his team have done really cool work in the past. I was lucky enough to see a talk by him about EMV Race, which are exploits in the EMV protocol used by credit cards. Their approach included modeling this protocol in Tamarin. Its website [0] shows demonstrative videos.

[0] https://emvrace.github.io/

Advanced encryption, until it comes time to text 70% of the phones in the world, in which case it defaults to a protocol released 32 years ago.

Yes but that would have meant giving up sales in exchange for actually backing up their words.

They aren’t even going to use the developed encrypted RCS protocol.

Apple, when it comes to their values, is all lip service.

I have intimate experience here with them both openly lying and purposefully deceiving their user base in this case.

What word? They never said they'd open iMessage. FaceTime is what they intended (or at least Jobs announced the intent) to open, and then that got caught up in a patent dispute.

No, they could have shipped a product on android, or they could have used secure RCS, or several other things.

FaceTime is not really true either. This was a convenient mistruth. There were several way to remedy that situation.

Also your misremembering iMessage there was no such issue.

It's not Apple's fault that the carriers/RCS/Google don't know how to make messaging work. RCS sucks, it pales in comparison to anything but SMS.

Google could have continued to support XMPP. If wishes were knishes doggies would eat.

You wrote:

> Yes but that would have meant giving up sales in exchange for actually backing up their words.

What word did they not back up with respect to iMessage? When did they ever say they'd open it up?

FaceTime is definitely true. I've used it.

I remember them saying releasing iMessage as an open standard.

Can you point to a source for that outside your memory?

They’re confusing it with FaceTime: https://youtu.be/JOxf9tEXEKQ

I figured that was the case. I just wanted one of these folks that keep claiming it to cough up some evidence. It's a tired thing. There are lots of things to criticize Apple (and most companies) for, at least pick something that isn't imaginary.

I guess. But I swear I remember it was about iMessage. oh well, my bad.

That was FaceTime, and it was because it was a peer-to-peer protocol. Then Apple was sued over a patent and had to implement a more normal design, where it pays for and runs the servers. Apple didn't want to run the servers for Android people to talk to each other.

> They aren’t even going to use the developed encrypted RCS protocol.

End-to-end RCS encryption is via proprietary Google extension and not even available to other Android RCS messaging apps.

It was made available to Apple.

Doesn't really help the argument that it is a proprietary Google technology. The fact that it had to be "made available" to Apple means that it isn't an open standard and requires trusting Google, which many of us don't.

Encrypted RCS should be a standard. When it is Google should adopt the standard, not its proprietary version. In the meantime I want Apple to implement standards, not proprietary Google technologies.

Citation?

Beeper was explicitly told it was not available to others when they wanted to implement Google's encrypted RCS on their Android client.

https://twitter.com/ericmigi/status/1557050351974420480

Under what terms, and with what promises?

If Google's strategy was anything other than "get Apple to adopt, then screw them", Google would have contributed the enhancements back to the standard.

> the developed encrypted RCS protocol

Google's proprietary closed source fork of RCS?

> Google's version of RCS... is definitely proprietary, by the way. If this is supposed to be a standard, there's no way for a third-party to use Google's RCS APIs right now. Some messaging apps, like Beeper, have asked Google about integrating RCS and were told there's no public RCS API and no plans to build one.

If you want to implement RCS, you'll need to run the messages through some kind of service, and who provides that server? It will probably be Google... So the pitch for Apple to adopt RCS isn't just this public-good nonsense about making texts with Android users better; it's also about running Apple's messages through Google servers. Google profits in both server fees and data acquisition.

https://arstechnica.com/gadgets/2022/08/new-google-site-begs...

> Yes but that would have meant giving up sales in exchange for actually backing up their words.

I saw that you moved the goalposts in your reply, but anyway: which words?

> They aren’t even going to use the developed encrypted RCS protocol.

The protocol that was designed by Google and in which Google’s infrastructure is crucial? It’s not Apple’s fault that RCS does not have mandatory end-to-end encryption.

> I have intimate experience here with them both openly lying and purposefully deceiving their user base in this case.

Do you mean that they lied to you personnally? You should write about that, it sounds much more interesting.

I worked on several integration attempts between Apple and Google.

They often presented specs that clearly showed security holes then simply would deny they were there or say “that’s secure”. It was a truly wild experience.

This sounds fascinating, you really should write about this.

I'm following up here just because of your comment. I've thought about this often but I've run into a few problems:

1) This tier of work is roundly invisible to almost everyone in the field. Many in the field are so confident in their knowledge of 'how things work.' that they simply can't accept the real 'in the room' realities of whats going on. Often engineers most of all, who are often deceived by their executives on the real goals. Are you and eng? Have you ever had that feeling of being gaslit by your VP? Yea you probably were, and you didn't know why.

2) Even at that level, I had a limited picture and a good extrapolation of what was going on in other rooms, but nothing I can say fully factually

3) No one wants to know. People love the just-so stories of these companies and really genuinely seem to get hurt/be in denial when they are faced with the reality that they are made up of ultra-selfish, shark like people with very little invested in the consumer, the company, or really anyone else. It's a game played to win for personal satisfaction. I've found that most people, simply cannot accept this.

RCS was not designed by Google. Google has (so far) embraced it after repeatedly self-sabotaging their own chat efforts. RCS is a carrier standard that the carriers had trouble deploying.

> RCS was not designed by Google.

Encrypted RCS was. And it is proprietary.

Why does 70% of world phones matter here? There are phones in the world that do not support any encryption when sending messages or doing calls.

SMS/RCS

The top 7 phones sold last year were all iPhones.

https://www.macrumors.com/2024/02/21/iphones-top-7-best-sell...

Too bad the other vendors don’t bother keeping up.

There is a flaw with your thinking. Any given year there are only 5-6 iPhones to choose from, where there are plenty of Android phones. This leads to "top phone sold" being iPhones because it is 5 phones against hundreds of Android phones that people get to choose from.

You should instead look at Market share. https://www.statista.com/statistics/272698/global-market-sha...

Actually my point was companies-responsible-for-encryption development. You could argue it’s Google vs Apple on this front, but it could also be Apple vs Samsung, or Apple vs any of the other top tier android implementations.

So you can either say Apple is reserving this development for a subset of the market, or Google is withholding it from a massive portion of the market share.

Samsung is not the reason why iMessages can't be sent to Android users or to Windows devices. Samsung does not decide which platforms Apple will and won't support.

Coordination with even Google would not be necessary for Apple to offer encrypted conversations with users on other devices. There's no rule saying they need to use an open standard or a Google standard or be cross-compatible with another app. It's not that Apple is trying desperately to get iMessage onto other phones and failing because Google and Samsung just won't let them do it.

Of course, Google has its own problems[0]. But the inability to use the Messages app to communicate securely with Android users[1], is solely 100% Apple's decision. Apple does not need to ask permission or coordinate with any other company to increase that security, they would just need to throw a messaging app up on the app store.

Heck, they wouldn't need to support iMessage on Android. They could throw a messaging app up that had no encryption other than that it worked over HTTPS and data instead of SMS when messaging iOS users, changed nothing about the capabilities or features that they supported for non-iMessage users, and even only doing that -- if Android users could download it and set it as their default SMS client on Android then iPhone security would be better.

----

As a comparison here, if Signal dropped support for iOS tomorrow, would you blame Apple for not building support for Signal into iOS? No, that would be absurd to suggest. No one would claim that Apple had some obligation to support the Signal protocol or make Signal compatible with iMessage, or to build an open protocol -- we would all correctly point out that Signal decides where to make its app available. The same is true of Apple. The fact that you literally can't make many Messages conversations secure without completely abandoning the app and using a separate 3rd-party service for those conversations -- it is purely and entirely the result of a decision that Apple has made.

----

[0]: And in fact their proprietary encryption standard is no better than Apple's and they're pulling the exact same crap as Apple is for the same flimsy reasons.

[1]: Note that I don't say non-Apple users, you can have an iMessages account through other devices and you still won't be able to use it with an Android phone number.

> you should instead look at Market share.

Unless your goal is to make money on the platform, then you should look at wallet share, not market share.

The goal isn't to make money or calculate wallet share. The goal is to send encrypted messages to contacts.

You should look at the percentage of smartphone owners. It does not matter in the slightest how many dollars they have in their pockets. The question is: is the average user going to have a significant number of Android contacts, with which Messages requires plain-text communication to contact.

And the answer for most people is: undoubtedly yes. I would say that most people who are using Messages as their primary messenger for all of their contacts are sending unencrypted messages on the regular.

Completely fair, I had shifted topics from phone owners, to platform relevance to makers on HN.

Your point stands.

> Any given year there are only 5-6 iPhones to choose from, where there are plenty of Android phones.

There is such a thing as 'too much' choice:

* https://en.wikipedia.org/wiki/Overchoice

* https://en.wikipedia.org/wiki/Decision_fatigue

* https://www.behavioraleconomics.com/resources/mini-encyclope...

* https://thedecisionlab.com/biases/choice-overload-bias

Yes but point here is that in the end there are more Android phones in the world than iPhones. So 'best selling phone' is not relevant in context of this thread.

that's only 16% of total market.

But 50% of revenue share (and has been as high as 110% of profit share):

https://www.counterpointresearch.com/insights/iphone-hits-re...

That's not the point if you're talking about who you can have an encrypted conversation with, but it matters if you want to know if you can afford building an encryption tool to serve phone buyers.

They have already announced they will add support for RCS this year (https://9to5mac.com/2023/11/16/apple-rcs-coming-to-iphone/), so not exactly a protocol released 32 years ago. It’s probably coming in iOS 18

Still unencrypted though, because the RCS standard does not include encryption.

RCS is unencrypted unless you use Google's closed garden Google Messages' extensions.

Apple is apparently working with GSMA to add encryption to the standard though. (They probably wouldn't add RCS otherwise.)

They would if a regulator made them. They're adding it because China requires it.

This is getting downvoted, but it really does feel like a variant of the wrench problem: https://xkcd.com/538/

It's already incredibly hard to get people to use secure messaging systems. Downgrading to SMS isn't necessarily wrong (it's become harder to get people to use Signal now that it's dropped support for SMS), but it's a huge hole and effectively means that many customers will never have a significant number of their conversations encrypted.

That's a boring security hole, sure. But at some point you have to think about UX as being a part of security, and a messaging system that isn't cross-platform is hard to call secure, because good luck trying to get your contacts to all use it. People get upset about this, but the reality is it does not matter what encryption scheme a messenger is using if it's impossible for you to get your contacts to use it. The same way that it does not matter how secure your 2FA system is if you can't get people to turn it on.

I felt like on net Signal's support for SMS was a boon for security more than a hindrance because it made it easier for me to get people to sign up for Signal. In contrast, Signal's take was that having a secure and insecure service bundled up into the same messenger would on average make people more lax about security and would make it harder for them to make strong security guarantees. They viewed SMS support essentially as a security vulnerability.

I do wish Signal had kept SMS and tried harder on the UX, I honestly feel somewhat strongly that removing support made secure messaging harder -- but while we can debate the security downsides and the onboarding downsides, I also have grown to kind of see their point? And iMessage falls very squarely into that problem, except with Signal I can at least tell my contacts how to get it.

I don't know, it feels petty but like... if you have secure encryption but it doesn't get turned on for a bunch of messages, then that does seem like it has a security impact. I don't think that's a complicated or controversial thing to say, it's no different from calling out that some chat services require E2EE to be opt-in instead of opt-out. Good security requires thinking about that kind of stuff.

It's the wrench problem. You're not going to get spied on by a quantum computer. You're going to get spied on because there's a decent chance that ~50% of your contacts or more aren't on iPhone and you'll be talking to them in plain text. And realistically for most users, switching to a cross-platform E2EE messenger that allows them to use one consistent service for all of their encrypted conversations is going to be meaningfully more secure even if it doesn't have quantum-resistant encryption. The most important problem for any secure messenger to solve is how to get people to use it. Sometimes that means compromising on other security standards, sometimes it means being harsher about security standards that would otherwise be optional. Sometimes it means caring about availability and onboarding, and not sending the majority of messages in an easily intercepted plain-text format.

> It's the wrench problem. You're not going to get spied on by a quantum computer.

I'll take that one step further; it's the trusting trust problem. In the words of Ken Thomson, "To what extent should one trust a statement that a program is free of Trojan horses?"

You're not going to be spied on by a quantum computer because intelligence agencies already use classical computing for that. Some governments write Apple or Google a strongly worded email, others install a backdoor using iMessage. There's no need to crack your encryption because you're not going up against quantum adversaries; those people all have better options than bruteforcing Apple's lock. Sufficiently-motivated actors skip the wrench and pay Bob or Alice for your password.

There's no perfect solution to this issue. Apple would sooner die than lower the drawbridge to iMessage, and Google can't be bothered to write an altruistic RFC to save their life. Now we get the worst of both worlds; divided and surveilled.

Barely anyone uses sms nowadays. People use WhatsApp, FB Messenger and co (outside of the USA).

I think people who downvoted you did so after reading just your first sentence and not the entire comment. Outside of USA, I don't think anybody uses SMS for anything other than the occasional OTP or bank message.

In India, nobody used anything other than WhatsApp till a few years ago. Now, teenagers use Instagram's chat feature and WhatsApp, and middle-aged adults use FB Messenger and WhatsApp.

I do not use Meta apps. I use just SMS/iMessage and Signal. So most of the time it is SMS, since this is outside of USA and not many people use Signal.

But even I send 'green bubble' from iPhone to iPhone sometimes. If there is no good internet coverage.

Did anyone figure out how MITM attacks are handled? How does the key transparency work and does it replace public key fingerprints?

Replace this question with “how competent is the Apple security team”

This (and Signal's solution as well) does not protect against active MITM attackers with quantum computers. They would need to incorporate post-quantum signatures into it as well.

The reason why it is missing (but seemingly planned in the future) is because it is not as critical as this change. This change prevents attackers from recording conversations now and decrypting them when (in the next ?? years/decades) they get access to an actually powerful quantum computer. On the other hand, you can do MITM only after you factorized RSA key (or solved discrete log).

The additional reason I presume is that this typically requires a change to the whole public key infrastructure (certificates, OCSP, etc.) which is a lot of additional work.

I'm a bit puzzled. Suppose you do single Kyber key exchange, and you then hash the shared secret with a domain separator to get a fingerprint, wouldn't that mean you now have a shared secret that you can verify wasn't under MITM.

You then can build post quantum future secrecy / key rotation on top of that, by mixing in new key material and it remains secure from MITM, as long as the internal state of the endpoint isn't compromised. The endpoint compromise is outside networked TCB threat model, as such compromise could also be used to exfiltrate long term post-quantum identity keys for undetectable MITM).

Key exchange (whether it's a PQ scheme or more classical DH) does not prevent active-MITM on its own, you need authentication too.

Yeah that's what the fingerprint is for, you compare it to authenticate the key exchange.

Would syncing to iCloud would compromise E2E encryption?

Fair question, and it actually depends on how iMessage is being backed up to iCloud (sorta). By default, iMessage is included in your iCloud device backup, which when Advanced Data Protection is disabled, is NOT E2E encrypted. That said, if Messages in iCloud is enabled, which instead syncs your messages to iCloud, They are always E2E encrypted, regardless of if ADP is enabled [1]. Even more confusingly, if ADP is off, the keys for Messages in iCloud are still stored in your iCloud backup [2]. So essentially, the only way to use iMessage E2E encrypted is with Advanced Data Protection enabled, regardless of if you're using Messages in iCloud or not.

[1] https://support.apple.com/en-us/102651

[2] https://support.apple.com/guide/security/security-of-icloud-...

> the only way to use iMessage E2E encrypted is with Advanced Data Protection enabled

If iMessage backup relies on ADP encryption, will ADP move to PQ3 Cryptographic Protocol?

It is data at rest which is different from the exchange of messages themselves.

I believe the backups are protected via AES.

Can't a MITM tell when a PQC rekeying is happening due to the larger size, and just not deliver it?

Is this country dependent?

No. This will be rolled out to everyone in iOS 17.4, iPadOS 17.4, macOS 14.4, and watchOS 10.4, and is already in the corresponding developer preview and beta releases[1].

[1] https://security.apple.com/blog/imessage-pq3/

China included?

Asking the real questions here. iMessage is currently not banned in china, beit because of non adoption by the general population, or because the CCP has a way to identify like they had (have?) with airdrop is yet unknown.

Will the code be available?

The only question that I have, will it break my old devices, so they would be forced out of the iMessages ecosystem? I believe that would happen. I don’t use it heavily, but that’s one of the reasons I keep an iPhone these days. The other reason is FaceTime support, so I could easily connect with those with iPhones. I do use not very modern iPhones (the very first SE currently), as that’s what I need my iPhones for: to make a call (via FaceTime most times) and to send a message (via iMessage, sometimes). If Apple breaks that for me, I’m either forced to buy a newer iPhone (which I’m not sure I want, considering I’m all in Linux and Android). Or they force me to rethink my priorities and just leave this. I can live with that, it’s just less convenient.

Does anyone know if this is still vulnerable to the iCloud Backups problem? The only solution to that right now is for you and your contact to turn on Advanced Data Protection. Curious if that’s still required.

That's still required.

I don't anticipate this changing either - because, let's face it, losing all of your Photos and Messages is, to most people, a bigger deal than perfect security.

I'm experienced with Apple products - but there was one time that I actually got stuck in an E2EE loop and was forced to reset all E2EE data on iCloud. I don't know what I did wrong - but if someone in tech, like myself, can get stuck in an E2EE lockout, I can't imagine other people.*

*This was not Advanced Data Protection. This was stuff that was E2EE for all accounts - like passwords and health information. As such there's no recovery contact.

I thought the fix was trivial - all I need to do is go to settings > my face >> icloud >>> show all >>>> messages and make sure the toggle is off?

doesn't that stop iCloud syncing, at least on my end? I understand I can't control what happens on the other end of the conversation but that is all I need to do on my end, right?

Correct. I was referring to the OP asking if Apple would ever fix E2EE not protecting, by default, Photos and Messages and so forth.

E2EE refers to transporting protocols and not data at rest, so the phrasing here is wrong.

If you choose to have some of your data in iCloud, it is transported and stored encrypted. However, one of the keys is escrowed in a HSM cluster for an audited recovery process.

This is how you go request access be restored via technical support with Apple. This is also how surviving family members can get access to photos and the like (requiring a court order, at least in the US). Since they have the key, government entities can request access within the extent of their respective local laws.

If you turn on the Advanced Data Protection feature, Apple no longer has that key escrowed, cannot help with account recovery, and can no longer give out a key they don't have.

You either have to enable E2EE or disable both Messages in iCloud and device backups. Otherwise the device backups contain a copy of your messages.

The "Messages in iCloud" sync is end to end, so you can enable it and disable iCloud backup, or manually backup on your computer: https://support.apple.com/en-us/102651

Yeah, it is end to end encrypted, but the keys are part of your device's iCloud backup. So unless you turn on end to end encryption for that backup or disable it, Apple can access the keys required to decrypt the iMessage in iCloud messages.

I believe the reason iMessages aren't protected with iCloud Backup is because they're stored decrypted in the SQLite database iMessage uses, chat.db.

iMessage’s practical lack of e2ee isn’t a matter of “perfect security”. It’s simply not e2ee because the keys are escrowed to the middle service. It’s not even a little bit secure. The encryption has been fully backdoored by sharing the endpoint keys off of the device.

Apple turns over customer data on over 70,000 customers per year without a warrant under FISA/702 (prism) and NSLs. The number gets bigger every year. This isn’t a theoretical threat. The number is even bigger if you include all the search warrants, too.

EDIT: Even if you enable their optional e2ee for backups (which nobody does), iMessage the platform is still vulnerable because the conversations you have with others are insecure because the other end of the conversation is escrowing their keys to Apple via non-e2ee backups. If you enable ADP iMessage only becomes secure for the case where you are only iMessaging yourself.

It’s simply not private or secure. You can’t be “slightly encrypted” or “mostly private”.

Unless you enable Advanced Data Protection, which escrows the keys solely on your device. This is hardly a secret or a scandal.

As far as I know, iMessage keys are not escrowed to any middle service. What are you basing that belief on?

Apple’s own HT202303. It is quite clear on the matter, even going so far as to point out that the keys are rotated when you turn off iCloud Backup.

Read the parts about Messages in iCloud, the service used to sync messages between devices. Those keys are included in the non-e2ee iCloud Backup. Both are enabled by default.

HT202303 refers to storing the keys for the Messages in iCloud feature.

>The only solution to that right now is for you and your contact to turn on Advanced Data Protection

or don't use icloud backup. Also, confusingly "messages in icloud" is end to end encrypted, and enabling it disables messages for being included in icloud backup.

Nothing is secure that goes to a server. Period.

Apple turned over iMessage conversations between journalists and senators at Trumps request. They encrypt but give away the keys in many jurisdictions.

>Apple turned over iMessage conversations between journalists and senators at Trumps request.

source?

> "messages in icloud" is end to end encrypted, and enabling it disables messages for being included in icloud backup.

This is misleading at best. Careful reading of Apple's disclosures reveals that the "messages in iCloud" encryption keys are still included in iCloud backups, giving Apple the capability to decrypt your messages on demand for law enforcement or for any other reason of their choosing. The messages may not be in your "iCloud backups", but that's just because they are stored on Apple's "Messages in iCloud" servers instead. Apple still has them and the keys to decrypt them.

https://support.apple.com/guide/security/security-of-icloud-...

> When iCloud Backup is turned on, the backup includes a copy of the Messages in iCloud encryption key so Apple can help the user recover their messages even if they have lost access to iCloud Keychain and their trusted devices.

Just a bit lower on the same page:

> When iCloud Backup is turned on, everything inside it is end-to-end encrypted, including the Messages in iCloud encryption key.

Meaning that Apple does not actually have access to that key, because it is encrypted before being saved to their servers.

This is misleading, again. The paragraph you quoted only applies with optional "Advanced Data Protection". Advanced Data Protection is off by default. In the default state Apple does have access to the Messages in iCloud keys in iCloud Backup, as I said.

Yep.

Table is here: https://support.apple.com/en-us/102651

If everyone you iMessage with has iCloud Backup still enabled (and I guarantee you 100% that they do because it is the default), then you turning yours off does nothing, as all of your conversations remain readable by Apple via the escrowed keys of the other endpoints.

iMessage is not e2ee.

It does not appear to be the default.

Wanna bet? Perhaps I should make a video.

You absolutely should, I've been wondering if there was a video somewhere showing the defaults during setup.

>Does anyone know if this is still vulnerable to the iCloud Backups problem? The only solution to that right now is for you and your contact to turn on Advanced Data Protection.

This is such a strange two sentences as a "problem". E2EE security, as it says in the name, is about the protection of dara transmission between two trusted end points. That's it. What the trusted end points themselves choose to do with that data before and after is completely out of scope, and has nothing whatsoever to do with the data transmission aspect. This is true of everything ever. No communication service stops people from backing up with encryption or not, local or remote, or from copy/pasting or for that matter taking photos of the screen ("analog hole"). If you want to "protect" the data from the trusted owners themselves now we're in the realm of DRM.

In this case what you wrote is "do non-e2ee remote backups still occur if users do not enable e2ee remote backups or backup locally?" to which the answer is yes. I definitely do blame Apple for not having APIs for backing up to arbitrary network servers when it comes to iDevices, but it's still orthogonal. And remember iMessage is on the Mac as well where people may be backing up anywhere.

> No communication service stops people from backing up with encryption or not, local or remote, or from copy/pasting or for that matter taking photos of the screen ("analog hole").

At least for the first part on backing up without copy pasting or using the “analog hole”, Signal expressly prohibits and doesn’t allow any kind of backup — encrypted or not — on iOS/iPadOS/macOS.

This lack of backups makes Signal less appealing to anyone who isn't a security/privacy enthusiast/nut. 99+% of people want their messages to work and not lose them when their phone is broken.

No I do not agree with you. Majority of people never read their message history, want their messages to self-detruct and don't want to get into a situation like when a new partner reads chat history with all previous partners.

Majority of people do not record their conversations and do not need this.

And most messaging applications are designed countrary to what people need - they preserve history specially for that curious new partner. Or maybe for a marketing department to analyze user's interests.

I’m very, very skeptical that any of us can accurately assert that a majority of people want this specific behavior from their messaging apps.

>> No I do not agree with you. Majority of people never read their message history, want their messages to self-detruct

Citation needed.

This has happened to me multiple times: convince non-technical person to download Signal, they delete app or get a new phone, they call me asking why they can’t see all their messages, they are very upset to learn they are all gone. Either I’m extremely unlucky or average users do want this.

>Signal expressly prohibits and doesn’t allow any kind of backup — encrypted or not — on iOS/iPadOS/macOS.

I do not think you are correct, or perhaps alternatively this is a distinction without meaning. iDevices do indeed lock down against owner control unless the device is jailbroken. But Signal for Mac only requires 10.15 or later. Even if they wanted to, old Intel Macs simply do not offer the hardware guarantees to protect against the owner getting access to their own data if they want to, though even current ones will still let you turn off SIP etc if you wish. I don't even need to look to guarantee that if someone wants access to their own Signal data on the Mac (or Windows, or Linux which can be run with any 64-bit distributions supporting APT), or any of these virtualized (and thus on the BSDs which aren't formally supported [0]), they can get it. And again, this is somewhat a distinction without meaning. Like, how does someone read their messages on Signal for Desktop after setting it up and it's syncing going forward? They login to the system, and there is a saved key and that makes it work. If they then choose to backup said system or VM without encryption now what?

I have heard that on iOS Signal has always been somewhat evil in attempting to steal people's data away from them, which is part of the reason I avoided it. But fortunately we don't yet live in a world where the same games can be pulled on regular computers. And hopefully eventually legislation will make it illegal on all computers, including handhelds, too.

----

0: 64-bit distributions supporting APT

GP here, with a late reply. Signal allows chats to be backed up and restored on Android. It does not support (and has said it won’t provide the feature) on iOS and related platforms that I mentioned. You can go through Signal’s help pages to confirm this yourself. If you use Signal on an Apple device and that device is either lost or broken, you’ll lose all your Signal messages when you setup a device again. That’s not necessarily the case with Android. Whatever you’ve written isn’t useful in this context.

Signal perhaps does not allow you to export your message history through the front door, however decrypting and exporting your message history is relatively low effort.

You messages are stored in encrypted SQLite3 database. The Signal encryption key is in

    ~/Library/Application\ Support/Signal/config.json

in plain text. If you have SQLCipher (https://github.com/sqlcipher/sqlcipher) compiled you can decrypt your Signal database:

Navigate to

    ~/Library/Application\ Support/Signal/sql/

and type

    sqlcipher db.sqlite
    sqlite> PRAGMA key = "x'<your_key_here>'";
    sqlite> .schema

and query away.

Of course there is a Python package to automate all of this here:

https://github.com/carderne/signal-export

This exports your message history as markdown and HTML files for your convenience and it will do incremental exports as well.

For iOS the same holds true, considering iOS has had a jail break most of its existence.

So, in retrospect your Signal messages are only as secure as computers of the people you talk to and of course your own device.

I would go a step further and assert that there is no such thing as secure communication.

GP here. Signal allows chats to be backed up on Android. It’s a built in feature.

It's not strange in the slightest. Apple deserves criticism until they fix this. They're going around claiming "end-to-end" and people don't understand that they are constantly handing over people's decrypted messages to law enforcement. It's misleading at best; I call it fraud. It's not as though Apple is merely failing to prevent a third party from breaking their end-to-end encryption here. Apple does it itself! iMessage and iCloud are not separate companies operating independently. The right hand knows what the left is doing!

This is not a UX issue or an engineering issue. Apple already built end-to-end encryption for sensitive data types that is still recoverable from backups even if you lose all your devices and forget your iCloud account password. They do it the same way Google does, and they already use it by default for important stuff you don't want to lose like passwords stored in Keychain and health data and a bunch of other stuff too. Literally all they need to do is store the iMessage encryption keys in this system by default. They continuously choose not to, and the reason is reported by Reuters to be a secret compromise agreement with the FBI. https://web.archive.org/web/20200121123026/https://www.reute...

>It's not strange in the slightest.

It very much is strange.

>Apple deserves criticism until they fix this.

There's nothing to fix, or rather they already "fixed" it by offering an E2EE iCloud backup option to go along with local backups. As I said I think backups should simply be fully under owner control, but as it stands there is absolutely no need to backup without full key control should people wish. And even before that there was no need to use iCloud Backup. I never have. But that has tradeoffs, and it's perfectly reasonable people may choose to make different ones.

>They're going around claiming "end-to-end"

Correctly. By your twisted definition, there is no such thing as E2EE for any transport in existence because the ends might then do something you don't approve of with the data they own. HTTPS? Not E2EE. SSH? Not E2EE. WireGuard? Not E2EE. Which is completely ludicrous and a total perversion of the specific, important role E2EE plays.

>They already built end-to-end encryption for sensitive data types that is still recoverable from backups even if you lose all your devices and forget your iCloud account password

No, if you use their full E2EE options, any of them, and you lose all your devices, your password, and recovery key (including any backups you've chosen to make on your own), you are hosed for any of the data that is E2EE protected. Like, by definition? Because otherwise it wouldn't be E2EE! The fallback when ADP is not turned on and someone is using iCloud Backups is that Apple does have the keys, that's the point.

There is literally no way around this, it's just definitional. If Apple has, somewhere in the stack, the keys then it can be compelled (or choose) to share them or share access to the data, but they can also help the owner recover if all else is lost. If the owner has exclusive access to all keys then the owner has exclusive responsibility. You can certainly have the opinion that Apple should make that latter the default of only choice. I certainly have the opinion they should offer more choice period. But that's still all orthogonal to the transport mechanism. You can have ultra locked down encrypted devices, and then go to a plain vanilla HTTP website or use telnet for administration and any MITM can see what you're doing. There could be a rootkit on your system that's grabbing everything right out of memory. That doesn't mean random MITMs can see what you're doing either if the transport is E2EE. All of these are important components of the overall security picture, but they're all different ones.

>is reported by Reuters to be a secret compromise agreement with the FBI

Read your own articles you link. That's a 2020 piece on Apple dropping old plans for owner key control of all private iCloud data. But specifically following the outcry there two years later Apple introduced "advanced data protection" that does precisely what that article is complaining they didn't earlier [0]. It got lots of coverage at the time. They explicitly cover how data is stored afterwards [1]. So people can turn that on. The Reuters piece is obsolete.

----

0: https://www.apple.com/newsroom/2022/12/apple-advances-user-s...

1: https://support.apple.com/en-us/102651

> There's nothing to fix

The default. They need to fix the default.

> By your twisted definition, there is no such thing as E2EE for any transport in existence

What a ridiculous misunderstanding of my position. iMessage and iCloud are inseparable parts of the whole of iOS, all from the same company, and their default configuration is not end-to-end encrypted. My position is that it is fraudulent to treat them as if they were separate to claim "end-to-end" encryption in only part when it's broken by the other part by default. Plenty of other systems are legitimately made of multiple parts by different companies and can claim end-to-end individually when their defaults are appropriate, even if they aren't when combined together by users in non-default configurations. There is no contradiction here, it's quite unambiguous.

> No, if you use their full E2EE options, any of them, and you lose all your devices, your password, and recovery key (including any backups you've chosen to make on your own), you are hosed for any of the data that is E2EE protected.

This is false. Apple and Google both now have a system that uses your phone passcode (distinct from your account password and practically impossible to forget as it is so short and you practice entering it literally every day) as the key to unlock your encrypted backups. They use secure elements in the datacenter to protect the weak passcode from brute force attacks, even from themselves.

> The Reuters piece is obsolete.

The Reuters piece is as relevant as ever until Apple changes the default for iOS so that Apple can't read the vast majority of all iMessages.

>The default. They need to fix the default.

No, they do not. That you don't give a shit about people losing data is a value tradeoff you believe in, but you've got a lot of work to argue it's an objective universal.

>What a ridiculous misunderstanding of my position.

It's amazing how you can say this with a virtual straight face, then immediately go on to directly argue that yep, that's your position.

>iMessage and iCloud are inseparable parts of the whole of iOS

They literally are not. Local syncing of iDevices predates iCloud backups even existing as a feature. You do not need to use iCloud Backups or data syncing. I never have. But if this logic applies, then it applies to everything! You can sync Safari browsing history, state etc too. Apps can sync data as well. So that must mean HTTPS is somehow no longer E2EE either. Unless you turn it off. Then magically it becomes E2EE? Be consistent.

>and their default configuration

This is a goalpost shift and stupid.

>My position is that it is fraudulent to treat them as if they were separate to claim "end-to-end" encryption in only part when it's broken by the other part by default

Because somehow you don't understand what E2EE even is. E2EE in communications solves one, specific and very important problem, which is data in flight. iMessage, HTTPS, or whatever else being E2EE, is a meaningful and significant difference then SMS or HTTP. It changes which potential actors can access that data, and how. End point security is an entire different problem with different sets of tradeoffs.

You're just objectively wrong and muddling an important distinction. Also, if you actually think it's "fraudulent" then by all means, sue them for false advertising, or contact your local authorities in charge of that. Good luck!

>This is false

Nope, it's correct, but there's a bit of a pattern here.

>Apple and Google both now have a system that uses your phone passcode (distinct from your account password and practically impossible to forget as it is so short and you practice entering it literally every day)

My phone password is 21 characters long and I almost never enter it because of Face ID. I'm starting to wonder if you actually own and use iDevices at all or if you're just regurgitating stuff you've read on the web? Even for people just using PINs, the vast super majority make heavy use of biometrics to the extent that Apple forces people to unlock once every few weeks just to try to help make sure they remember. But people forget anyway. Older people or those with other forms of memory loss forget a lot of simple stuff, including their own phone numbers, all the time. People have accidents. One of my cousins just got hit by a car while riding his bike and suffered a bad concussion followed by a long period of amnesia. At Apple's scale they absolutely need to, and should, care about such things.

You just said it was wrong that if someone loses their passwords (and PINs are just a kind of password, "something you know"), they are hosed on the data because... uh... people don't forget! Wild.

>The Reuters piece is as relevant as ever

Nope, it was specifically about there not being an option, at all.

> You do not need to use iCloud Backups

You do if you want cloud backups (as most people do), because Apple prohibits you from doing it any other way. You can't uninstall the iCloud backup software, you can't replace it, and you can't buy an iOS device without it. It's literally inseparable from iOS by Apple's design, and iMessage is too in exactly the same way.

> So that must mean HTTPS is somehow no longer E2EE either

Safari doesn't backup the contents of your HTTPS connections to Apple, nor even the URLs for the vast majority (only top level page navigations are stored in history). The analogous situation would be if Safari would relay all the content of every HTTPS connection to Apple servers along with the keys to decrypt it. Maybe you would defend such a system as "end-to-end encrypted", but you would be in a very small minority.

> My phone password is

... completely irrelevant. Who cares? You're not seriously arguing that 21 character phone unlock passcodes are typical? We're talking about defaults here.

> I almost never enter it because of Face ID

I was wrong. I thought that you had to enter the passcode at least once daily, but it's actually at least once weekly. However my point stands. It's extremely unlikely for the vast majority of people to forget their passcode, which is distinct from their account password, which is almost invariably very short, and which they practice entering at least weekly.

As for the edge cases you mention, every system has edge cases. The non-E2EE account recovery case has edge cases too. It requires navigating Apple's support process and proving your identity via whatever means they request which not everyone will be able to do successfully. Also it's vulnerable to social engineering attacks on the support reps. No system is perfect. If the forgetting issues were so bad, then Apple wouldn't by default encrypt Keychain passwords with true E2EE. Losing those is actually super inconvenient too, but Apple has no problem with E2EE there. That's because law enforcement cares more about reading your messages than logging into your Reddit account (or they can just go to Reddit directly).

> PINs are just a kind of password

A very special kind of password which is by design much easier to remember and practiced more often. They are very different in practice, don't pretend there's no relevant difference.

> I'm starting to wonder if you actually own and use iDevices at all

I owned and loved the OG iPhone and many other generations too. Although my current phone is Android, I still use iPhones and iPads casually from time to time.

Look, I could continue all day, but long experience has taught me that it's pointless to argue with someone so clearly stuck in the reality distortion field. I believe I've made my points clearly for any other reader of this thread. I won't be responding further.

This is how Constantinople fell to the Ottomans: they had very high hard to penetrate walls, but forgot to lock one gate. *

Replace the walls with highly secure encryption e2e algorithm, and the gate with easily accessible backup, and you'll see why things like this are not out of scope.

* - this story is disputed by some historians

Your argument about iMessage on Mac’s holds water, but the iPhone is sold as an appliance and there is no concept of a file system presented to the user. They sell the messaging platform as “encrypted” and the word “encrypted” is plastered all over iCloud marketing and documentation. You really can’t blame the user for assuming the appliance is secure by default. When you first set up an iPhone it just asks you if you want to back up to iCloud. It doesn’t use the word “insecure” nor “unencrypted” anywhere on that screen.

in what way is iCloud backup 'insecure' or 'unencrypted'?

Aha, you are proving my point about how misleading Apple’s communications are about this!

By default, iCloud backups are “secured” by a key that Apple stores and controls. This means that both Apple and anyone who can compel or hack Apple can still access your data.

Here’s the official documentation: https://support.apple.com/en-us/102651

The only backup provider allowed is also the communication service provider, which defeats the point of E2EE because the keys are also stores transparently (ie, not even encrypted with the device passcode).

That is the problem. Apple's business decision to ban other backup providers like Backblaze etc is making their privacy efforts meaningless.

Why is it a problem? Because governments and powerful entities need only contact Apple (the communication provider) to know the contents of the message. And I as a user have no way of knowing if others in the chat have advanced protection enabled, as I am only protected if every participant in the conversation has the correct settings, which are not the default settings.

So while this might meet some technical definition of E2EE, it does not meet the common-sense definition of E2EE where the communication provider has zero visibility into content.

That will always be the case with Apple. Their default behavior is to cater to a user that will shoot themselves in the foot anytime they have the opportunity. I applaud them for giving users the option to be secure, but I don't blame them in the least for making you turn on the thing that can make grandma lose all of her message history.

Isn't all this post quantum stuff a little premature? The standards haven't settled. We don't even know if there is a possible quantum threat to cryptography yet. The more we work on the problem the less likely it seems. Last I heard we were 1 or 2 orders of magnitude away from physical noise performance that would make such a threat possible.

Edit, added: Harvest now, decrypt later applies to any encrypted data. There is nothing special about the quantum threat. This all only makes sense if we can predict what the actual threat is ... and so far we can't. This reminds me of Pascal's Wager[1]

[1] https://en.wikipedia.org/wiki/Pascal%27s_wager

You'd be right except that anything encrypted now can be stored and cracked later.

I remember as part of the snowden leaks there was documentation about this kind of delayed phase collection.

Basically store as much signals data as you can and try to crack it later if there's a weakness discovered with the protocol or computing power starts being capable of wholesale attack.

You might remember that hashes are significantly easier to crack with "rainbow tables", and so we added cryptographic "salts" to online password storage. We discovered that about 15 years ago and started salting all our passwords, but for a large window of time all of those old leaked databases were suddenly extremely easy to crack.

Now, Imagine the NSA is 10 years ahead of us (and you might be close with that estimation), so even if they can't crack RSA right now they're much closer than we are, and even we get there we will likely have a large window of time before we fix it properly. (not that we're talking RSA here, but you get my point).

https://www.forbes.com/sites/andygreenberg/2013/06/20/leaked...

RSA isn't anywhere near 10 years away from being attackable with a classical computer. (More like eons.)

It's not a matter of time, it's just a matter of quantum computers existing.

That Forbes article is about a loophole involving encryption that could allow the NSA to collect and store data that they might not otherwise be able to. Now that everything is encrypted, that loophole might cover everything.

Nothing in the article implies that the NSA can magically collect all the encrypted data in the world and keep it for many years.

One reason to move sooner rather than later is to mitigate the threat of previously stored data. There may be a government entity simply storing all imessage traffic in the hopes of one day decrypting it when/if a breakthrough happens. If you transition sooner, you increase the age of the latest data that could be decrypted, thusly hopefully making it safer.

this is capitalism. why would they care unless the decryption happens this fiscal quarter?

Like the article says, it's protection from harvest-now-break-later.

Apple users and communications are today a state-secret affair as shown by the impact of NSO/Pegasus.

So even if Google,IBM,et al _might_ have approached feasibility in the open there is still a significant risk in state-level adversaries having poured enough funding to still be ahead, plus they will benefit from all open research in the hidden with extra funding to take more leaps.

So no, it's not premature if there is hidden or open leaps just 10 years in the future.

> Edit, added: Harvest now, decrypt later applies to any encrypted data. There is nothing special about the quantum threat. This all only makes sense if we can predict what the actual threat is ... and so far we can't.

But we know Shor's algorithm, and we've started building prototype quantum computers. Isn't that enough to build something that counters them? Worst case, we deploy new ciphers and realize that the threat was empty 50 years from now. What's the downside?

> Last I heard we were 1 or 2 orders of magnitude away from physical noise performance that would make such a threat possible.

The entities with the most to gain from such an advancement are not exactly known for publicizing their achievements.

From the article:

>> Although quantum computers with this capability don’t exist yet, extremely well-resourced attackers can already prepare for their possible arrival by taking advantage of the steep decrease in modern data storage costs. The premise is simple: such attackers can collect large amounts of today’s encrypted data and file it all away for future reference. Even though they can’t decrypt any of this data today, they can retain it until they acquire a quantum computer that can decrypt it in the future, an attack scenario known as Harvest Now, Decrypt Later.

We have reason to believe that conventionally encrypted data isn't threatened within the next 50 years by anything other than quantum computing, which is what's special about the quantum threat.

I wonder if Apple will use this as an excuses to not comply when it comes to providing cross platform messaging in the EU.

The EU already decided that under the DMA, iMessage is too small to qualify for the interoperability requirement. Apple is however adding (unencrypted) RCS support to comply with Chinese government law, which requires that all 5G phones support RCS.

You don’t need (unencrypted) in this. RCS is not encrypted. It never has been.

Google has a proprietary extension that puts encrypted blobs into RCS messages, but that would be no different from apple shoving iMessage blobs into RCS and calling it RCS.

Apple already has cross platform messaging in the EU. SMS!

Besides, the EU doesn't care about iMessage.

>When iMessage launched in 2011, it was the first widely available messaging app to provide end-to-end encryption by default,...

Until very recently, iMessage provided no way to verify that you and your correspondent were not both connected to the server, rather than each other. So guaranteed end-to end encryption wasn't possible. Even now, with a recent version of iOS, they allow the users to blithely exchange messages without any identity verification. The identity numbers used to do this are hidden behind menus. So not really E2EE in any practical sense.

Same thing with Signal and most other messengers. Can you link to some documentation that shows iMessage even has the identity numbers?

https://support.apple.com/en-us/HT213465#verify

Wonderful, thank you so much! Good to see Apple fix their app finally.

Would be great if we could uninstall iMessage completely out of iPhone for security reasons or make it opt in by default. Unfortunately it's not possible and it will be a gateway for security issues and malware in the following years to come. Post quantum cryptography is nice but that's one of the smallest problems with iMessage.

iMessage can be disabled in Settings > Messages

You can very easily disable iMessage completely

How?

Settings -> Messages -> Toggle iMessage off

Wouldn't SMS be more insecure?

For message security, absolutely. For endpoint security (iMessage as exploit surface), not so much.

Just gonna add here. Do not switch from iMessage to SMS no matter what. Only switch to something like Signal if you need the cross-platform support etc.

I don't intend to dispute your stance here, but I am interested in understanding a bit more about it. Do you mind giving an example and what the alternative(s) are?

Search for "Pegasus, NSO, spyware, imessage" or https://archive.is/4fl6o

One quote from the article: “Your iPhone, and a billion other Apple devices out-of-the-box, automatically run famously insecure software to preview iMessages, whether you trust the sender or not,” said security researcher Bill Marczak, a fellow at Citizen Lab, a research institute based at the University of Toronto’s Munk School of Global Affairs & Public Policy. “Any Computer Security 101 student could spot the flaw here.”

Have any zero-day vulnerabilities been found that work on devices in Lockdown Mode?

You can entirely disable iMessage (and FaceTime, and Siri, etc) via provisioning profiles on a managed device. Use Apple Configurator 2 to do so.

(A very important privacy setting with no corresponding toggle in the UI that can only be set via a configuration profile is the option to not auto sync your list of recently emailed people to iCloud (“Disable recents syncing”). This leaks your email contact history and social graph to Apple if you have iCloud turned on, even if you aren’t using an Apple email account and aren’t using iCloud Contacts. AFAIK there’s no way to disable it other than via configuration profile.)

This is what I do.

interesting!

You can enable lockdown mode to decrease the attack surface.

https://support.apple.com/en-us/105120

Just as a reminder making crack-proof encryption standard everywhere is a trade off. It’s often discussed and presented in forums like this as the only and just choice (and I believe net it is), but in doing so WILL lead to bad outcomes. Terrible crimes, unsolvable murders, large scale terrorism, emboldened enemies attacking a country, more successful coups, etc. It would be nice as a community to acknowledge nothing comes for free and every technology is a double edged sword. I wish more of these double edge swords could be debated by the public it affects, although it’s out of the scope of comprehension and thoughtfulness by most. And yet we all make the choices that will affect generations…

Yeah, that’s what the NSA has said forever - but it turns out that all encryption has that human factor.

Imagine I’m planning something malicious. If I literally do anything other than talk about it, there’s going to be evidence, and that evidence won’t be encrypted.

Plus, crack-proof encryption existed at least back to Roman times - simply because making a secure code was fairly easy and we didn’t have codebreakers. We managed.

people commit crimes with: cars, money, public transit, restaurants, food, bathrooms, roads, … why don’t we get rid of all that?

we don’t remove all rights to privacy for people in their homes because criminals use homes too. tech should be no different

Those “bad outcomes” already existed pre encryption. If anything, it’ll be more of the same.

Widely used unbreakable encryption has been available in chat apps for at least a decade and hasn't led us down that slippery slope yet. PQ3 is just future proofing what we already have.

For a minute I thought you were only talking about non-state actors performing those terrible things, then remembered history is full of nations doing all those things.

It’s all of the above. That’s my point. Good, bad, ok if you’re on their side, some never have a side to be on.

(1) crimes happen, and have happened forever

(2) historically people simply did not create a huge written record (texts etc) detailing their crimes, so there’s no change in available information

(3) even before any of this tech police are not good a solving crimes, and generally rely on errors by criminals

(4) and finally. Your argument is definitionally the slippery slope and is the reason the 4th and 5th amendments exist in the US. Your argument is trivially extended to literally everything: why shouldn’t all communication be routed through government servers to find evidence of crimes? Why shouldn’t all device locations be available to police at all times? Why shouldn’t you have video and audio recorders in every home (most child abuse, the quintessential horror) is committed by family members in the home.

Having actual privacy does not result in crime, and mandating that privacy should be illegal in only a single case is clearly nonsense. Either you have a right to privacy or you don’t.

https://www.eureporter.co/world/human-rights-category/europe...

Yes, giving people privacy means giving everyone privacy, whether they're doing good things or bad. Pointing cameras into everyone's window would also prevent some crimes, and we shouldn't do that either.

I don't think "This has tradeoffs but those tradeoffs are absolutely worth it" is a level of nuance that's possible in the face of the level of scaremongering against E2EE.

Reply on news.ycombinator.com