Apple today announced a new post-quantum cryptographic protocol for iMessage called PQ3. Apple says this "groundbreaking" and...
Apple Announces 'Groundbreaking' New Security Protocol for iMessage::Apple today announced a new post-quantum cryptographic protocol for iMessage called PQ3. Apple says this "groundbreaking" and...
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.
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.
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.
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.)
Besides. They will be using this adjustment to spy on every gorramn thing you text, pic and call. That's the reason for this "change" to the software that won't respect the copyleft and lie to present its new and closed source their shit.
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 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.
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.
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.