This is a most excellent place for technology news and articles.
My guess is that they’re doing this now so they can say, in court, that their product is more secure than the alternative. Offering similar encryption in a walled garden might not be enough to avoid antitrust scrutiny in US courtrooms. Now they can lean into to arguing that their product is walled off for security reasons.
That said, at some point more stuff will need this protection. Maybe not tomorrow, but the clock is ticking.
At least some of their antics are actually resulting in positive change for their customers.
While the motivation is likely disingenuous as you say, the outcome sounds positive.
Quantum-safe or Beeper-safe?
Beeper didn’t work by cracking iCloud’s encryption. The user’s key was still needed to decrypt a message. Beeper and Apple couldn’t see the contents of an iCloud message, only the end users.
As I recall, Beeper’s secret sauce was around authenticating from a 3rd party client.
Yeah IIRC it was side channel
It's not "groudbreaking" when it's already widely used in Signal.
Fuck Apple, they're a monopolistic piece of shit.
Signal "only" does PQ key exchange. Apple claims to be doing PQ rekeying in addition to PQ key exchange.
Read the article before commenting perhaps.
Can you explain the difference and what attacks PQ rekeying prevents that PQ key exchanging doesn't? When "the article" is a an apple fan boi site regurgitating apple press releases in breathless fashion, you might want to take their claims with a grain of salt.
Short answer: key exchanging is only important in a future where not only do nation states have quantum computers that can break classical algorithms, but can also break quantum proof encryption algorithms a few times with a lot of effort, but not many times over and over (if they could break them easily then they'll just break every key rotation). i.e. a speculative future that may never exist and quite frankly even if it did, won't for decades given the current state of quantum computers.
A more informative take from somewhere other than an Apple press release:
The changes Apple is announcing put iMessage at parity with Signal, both in terms of PQC hardening and the key refresh through ratcheting. Apple, however, is taking things one step further by applying ratcheting not only to the quantum-vulnerable Elliptic-curve Diffie-Hellman algorithm but also to the PQ3 being added now. This improvement comes with some limitations, though. Because of the significant overhead in refreshing keys for PQC algorithms, the key updates can’t be made with the exchange of each message as they are with the Elliptic-curve Diffie-Hellman.
As University of Waterloo professor David Jao explained in an email:
The X3DH ratchet used in Signal depends heavily on ECDH and elliptic curve arithmetic. You need to be able to add public keys together, and add private keys together, in meaningful ways. Most post-quantum replacements for ECDH do not support the same arithmetic. This makes constructing post-quantum ratchets difficult and is part of the reason why no one has implemented it before. You can do it, but as mentioned in the Apple post, the overhead goes up from 32 bytes per ratchet to 2kB per ratchet. In the messaging context, the latter overhead is quite significant, being many times larger than the messages themselves. Apple mitigates this overhead by stepping up the ratchet every ~50 messages instead of every message. Of course, this design means that the security guarantees provided by the post-quantum ratchet are lessened: an adversary that compromises keys and transmissions could potentially gain access to up to your 50 most recent messages.
Since Apple is doing BOTH the normal X3DH/ECDH ratchet and the post-quantum PQ3 ratchet, the 50-message look back only applies to the PQ part. Each individual message is still protected by the ECDH ratchet with the 32-byte overhead. So you still have to break ECDH. Assuming quantum computers eventually get built, breaking ECDH will be easy, but that is not the case presently.
For now, ratcheting in Signal will be limited only to the X3DH part of the messaging app. In a statement, Signal President Meredith Whittaker wrote:
Before we deployed PQXDH in May, 2023, we carefully considered implementing a periodic amortized quantum rekeying process, similar to the one that Apple decided on for their PQ3 specification. We decided against it, not because it isn't a good first step, but because we wanted to find an approach that would enable quantum rekeying to occur as frequently as non-quantum re-keying does—instead of relegating it to ratcheting less often, as is the case with Apple's PQ3 approach. Such an approach is currently the realm of novel research, and something that will require solving extant problems in order to implement at Signal’s scale. We are currently working with the cryptographic research community to explore methods that could allow us to implement more frequent quantum rekeying.
Another difference between the two apps that privacy-minded people should remember is that, by default, iMessage backs up messages within iCloud with no E2EE. Advanced encryption will do nothing to protect users in this scenario. People should either turn off iCloud backups or turn on E2EE in iCloud. (Signal doesn't back up messages at all.)
But did you add RCS support yet?!?!
If the answer is no, YOUR PRIORITIES ARE FUCKING WRONG!
I won’t be surprised if that doesn’t show up until iOS 18; when they announced it in November 2023 the only timeline they gave was “later next year.” This encryption has presumably been in development for a while, whereas I think they announced RCS support only as they started, to try to get ahead of regulatory issues in the EU.
I’ll bet money that this project started long before Apple and Google agreed on their shared cross platform RCS strategy 4 months ago.
And as others have said, unlike PQ3, RCS will visibly impact the experience. “Green bubble” message quality will go way up. I’ll bet PM and marketing want to peg that to a full version number release. Those folks always want to hold back the juicy user-facing stuff for n.0 releases
I don't use Apple devices, so my preferences aren't particularly relevant, but...
I would rather have better E2EE than RCS. Really I don't care for RCS at all. The last thing I want is for carriers to have any control over my messaging. I want my chats to be available on all devices even if I drop my phone into a volcano. I want to just use the internet without weird carrier networking. RCS is nicer than RCS I guess, but lipstick on a pig. My carrier should just worry about connecting me to the internet, not wasting their time making deals with Google to host some weird phone-number connected chat app.
I would rather have better E2EE
and
I want my chats to be available on all devices even if I drop my phone into a volcano
are kinda conflicting goals. If the chats are easily available on a new device without you manually syncing the key, that means the key exists somewhere in the cloud outside of your control, which is the opposite of good E2EE.
You can still achieve both goals, but it would involve you exporting the key, storing it somewhere, and then importing it to a new device from where you stored it.
They aren't conflicting goals. Multi-device E2EE is available in protocols like Matrix and WhatsApp.
In the simplest case multi-device E2EE can be implemented as a group chat, and when you add a new device to your account you automatically add it to all of your rooms. So any protocol that supports mutli-user E2EE can support multi-device E2EE. Of course there are more efficient implementations.
it would involve you exporting the key, storing it somewhere, and then importing it to a new device from where you stored it.
Yes, you need to have a copy of the key, if the last copy is lost any E2EE solution will fail closed. If you have multiple devices this is probably already solved. (For example Matrix where when you log in with a new device it will ask you to verify from an existing device.)
But the point stands that if I am on vacation with a laptop and a phone and I lose my phone with proper multi-device I can continue to use my laptop seamlessly. (It already has a key)
You can also make "offline" backups and import to new devices. This may be less convenient but it can be easier to make offline backups than having globally distributed full computers. There are other solutions as well like escrow where a key is protected by a password or HSM devices. Although these are not as strong as never giving the key to a third-party.
As EU dropped their app from the list of gatekeepers, they have no need to adopt abandoned protocol laying around and pretend to be open like Google do.
So are they going to use Perfect Forward Secrecy with this protocol? Because that's their big problem.
the symmetric ratchet, protects older messages in a conversation to achieve forward secrecy. For every message, we derive a per-message encryption key from the current session key. The current session key itself is then further derived into a new session key, ratcheting the state forward. Each message key is deleted as soon as a corresponding message is decrypted, which prevents older harvested ciphertexts from being decrypted by an adversary who is able to compromise the device at a later time, and provides protection against replayed messages. This process uses 256-bit keys and intermediate values, and HKDF-SHA384 as a derivation function, which provides protection against both classical and quantum computers.
Fuck apple.
They gotta stop with the breaking of ground
