Apple Announces Post-Quantum Encryption Algorithms for iMessage

Apple announced PQ3, its post-quantum encryption standard based on the Kyber secure key-encapsulation protocol, one of the post-quantum algorithms selected by NIST in 2022.

There’s a lot of detail in the Apple blog post, and more in Douglas Stabila’s security analysis.

I am of two minds about this. On the one hand, it’s probably premature to switch to any particular post-quantum algorithms. The mathematics of cryptanalysis for these lattice and other systems is still rapidly evolving, and we’re likely to break more of them—and learn a lot in the process—over the coming few years. But if you’re going to make the switch, this is an excellent choice. And Apple’s ability to do this so efficiently speaks well about its algorithmic agility, which is probably more important than its particular cryptographic design. And it is probably about the right time to worry about, and defend against, attackers who are storing encrypted messages in hopes of breaking them later on future quantum computers.

Posted on February 26, 2024 at 7:04 AM16 Comments

Comments

Clive Robinson February 26, 2024 10:11 AM

@ Bruce,

“The mathematics of cryptanalysis for these lattice and other systems is still rapidly evolving, and we’re likely to break more of them —and learn a lot in the process— over the coming few years.”

My advice as the use of hybrid algorithms is for some reason frowned upon is to do “two step” encryption.

1, Use a well found symmetric algorithm for message “content” in an E2EE arrangement (end user to end user encryption).

2, Use the Post QC stuff for message “transmission” (comms point to comms point / line encryption).

That way your “traffic” neither stands out or requires changes to Comms systems you end up having to use for “economic” etc not “real security” reasons.

Perry Fellwock February 26, 2024 10:58 AM

Another bright and shiny thing for Apple to publicly dangle, because security features are a wonderful branding opportunity.

Because Apple stands up to the big bad government (unless they have the good sense to submit requests for subversion discreetly).

https://www.theamericanconservative.com/the-bogus-big-brother-big-tech-brawl-over-backdoors/

“Apple was perfectly happy to help them so long as the FBI quietly submitted the request under seal. Only after the request went public did Tim Cook adopt a more antagonistic posture”

Bcs February 26, 2024 11:44 AM

It would seem to me a good “early adoption” strategy when you don’t know what algorithms you will be able to trust would be to deploy a system that is secure as long as either the old standards are secure or any of the new candidates are. E.g. use quantum resistant symmetric encryption for the payload and then transfer the key using secret sharing with each share transferred with a different algorithm.

Stuart P February 26, 2024 11:45 AM

My advice as the use of hybrid algorithms is for some reason frowned upon

Frowned upon by NIST, perhaps, a decision which seems to have suspiciously little support among cryptographers. Most implementers are making more reasonable decisions. Apple, for example, listed this requirement for PQ3: “Use a hybrid design to combine new post-quantum algorithms with current Elliptic Curve algorithms, ensuring that PQ3 can can never be less safe than the existing classical protocol.”

Of course, if NIST do try to push non-hybrid implementations of quantum-resistant crypto—perhaps via certification programs—those mis-steps will likely be with us for decades, much as we’re still finding vestiges of the 1990s “crypto war” (like last year’s TETRA break, and all the bad crypto in GSM and its successors).

aksu February 26, 2024 11:57 AM

As commented above, it would be a good idea to support/deploy hybrid systems, such as two-step encryption, at this early point.

Also, Douglas Stebila’s [not Stabila, there is a typo in Bruce’s post] analysis was funded by Apple. This may or may not be a problem.

Vesselin Bontchev February 26, 2024 1:38 PM

Betcha the new post-quantum code is packed with bugs that turn private conversations into an open book for memory corruption exploit artists.

But hey, at least you’re protected from adversaries wielding imaginary computers.

Clive Robinson February 26, 2024 1:57 PM

@ Stuart P,

Re : Legacy problems.

Whilst I’m with the cryptographic community that “hybrids are cautious” there is a flip side.

If new systems can do either pre, post, or both QC encryption you have the thorny problems of “fall back attacks” via a “Man in The Middle” attack.

In the past we’ve seen systems forced back from AES256 to little more than “plaintext” (40 bit export DES) by MITM attacks abusing the negotiation process back to the lowest common denominator which is usually the weakest of the weak.

Whilst “Software upgrades” are not to difficult on PC’s and laptops users have way less ability on Smart Devices, and effectively none at all on embedded devices. With embedded being those that are the ones with the longest service life, such as utility meters and implanted electronics.

The last thing you want is some joker fritzing with your “de-fib” and making you break dance / body pop around the place.

Likewise you don’t want someone having the ability to tell your AC or Heating to turn on or off in high summer or deep winter or just changing the Units used readings sent back for billing.

I know some politicians want the rights of ownership in your home taken away from you as they are paid to think that way. But honestly there is no way I’m having any kind of smart meter in my home spying on what I do which is what Smart Meters can do.

Stuart P February 26, 2024 2:19 PM

If new systems can do either pre, post, or both QC encryption you have the thorny problems of “fall back attacks”

I don’t believe anyone respectable is suggesting such a thing. If you’ve got a combination of “traditional” and quantum-resistant algorithms, and the keys are truly independent (the failure to ensure this being the main way in which such a combination can “go wrong” and reduce overall security), why would you ever remove the older algorithm? Elliptic curve systems, in particular, are extremely cheap in terms of data size and computation time.

I’m also not seeing how this is a “flip side”. Any time new crypto is added, fallback attacks could be possible. But if we don’t add the crypto, that’s basically a fallback attack that’s happening 100% of the time.

lurker February 27, 2024 3:47 AM

@echo
“The pre-internet age also had much more interesting spy novels too.”

Secret inks and code books were Sir Francis Walsingham’s toys too, but wasn’t he a high Tory?

Clive Robinson February 27, 2024 7:06 AM

@ Stuart P,

Re : Suggested or not.

“I don’t believe anyone respectable is suggesting such a thing.”

Well leaving aside you notion of respectable or not, there are a couple of points to consider,

1, Such a failing and thus attack vector has happened several times in the past (it’s one reason why MiTM is talked about quite a bit).

2, For some reason the ICTindustry and Software development in particular appear to be incapable of learning from past mistakes, even those made within easy memory of less than a decade (“If you don’t learn from your history you are condemned to relive it in ever increasing ways”).

Both of these are factually verifiable and to be honest I really don’t see any changes happening any time soon in the second point.

So the alleged Chinese curse of,

“May you live in interesting times”

Appears to apply.

Now if you regard that reasoning as “reasonable or not” is upto you, but it is a very real potential vulnerability that certain types of hybrid system suffer from.

As for,

“and the keys are truly independent”

Oh dear, have you not noticed the fad for automated key management systems?

Because users are not capable of doing it correctly as evidenced in papers like,

“Why Johnny Can’t Encrypt”

and it’s multiple updates over time.

All such “Key Management”(KeyMan) systems are “fully deterministic” thus by very definition are not nor can not be “truly independent”.

They are at the end of the day based on the “assumed notion” that there are actually “One Way Functions” that don’t have “short cuts” or “breaks” neither has been proved. Thus what has been proved is Shannon’s “unicity distance” comes into play.

As a rough rule of thumb, it’s going to be less than,

“Three times the changeable bits of state minus two bits.”

Which can be actually quite short in many automated KeyMat “Key Generation”(KeyGen) systems. Because all to often “Magic Pixie Dust Thinking” comes in and developers use hashes to fake actual state entropy increase[1].

It’s actually very hard to get a really large number of state bits to change in an unpredictable fashion yet be usable in KeyMan KeyGen deterministic systems.

I can go through why this if you want but it would take quite a few column inches. However our host @Bruce has written about it in –if memory serves correctly– at least three papers and two books that talk about the design of secure TRNGs in computers.

[1] You see “Magic Pixie Dust Thinking” all over the place where OWFs based hashes get used. Think of their use as like a simple substitution cipher. If the range of inputs is 4bits, it does not matter that the hash output is 256bits in size because you will only ever get 2^4 or 16 different outputs. Even if you use some pre substitution cipher mode, it’s going to be a deterministic process thus unless well considered be limited in range or fairly easily determined as it will be based on the equivalent of an incrementing counter and substitution cipher more than likely with the equivalent of a fixed increment of one. It’s why the number of changeable bits of state for each iteration has to be actually large not faux / pseudo large from the OWF in a known hash function.

Bill February 27, 2024 8:32 AM

And it is probably about the right time to worry about, and defend against, attackers who are storing encrypted messages in hopes of breaking them later on future quantum computers.

One way to protect against this scenario is to simply generate far more data than can possibly be stored. Pad all of your messages with tons of random data before encrypting. This could at least prevent foreign adversaries from storing the vast majority of encrypted communications, at best only storing the communications of specific devices of targeted individuals.

Clive Robinson February 27, 2024 9:52 AM

@ Bill, ALL,

“One way to protect against this scenario is to simply generate far more data than can possibly be stored.”

No it’s not, it’s an old idea of “swamping” and it does not work and has not since before the Internet existed.

The first thing for you to consider is how do you generate such large volumes of traffic without falling into “repetitions”, “patterns” and similar that can be filtered or compressed because they lack actual entropy because they have been generated deterministically.

People thought years ago that steganography could be used to do similar, but algorithms were fairly quickly developed to spot it easily. You are in effect talking about doing stego on a grand scale, but those algorithms generally don’t care about “scale”.

Also look at “Traffic Analysis” and how it works very effectively without having to find KeyMat because it works on patterns in meta-data.

Then get to understand what meta-meta-data is and how it can be used. Put over simply the easiest example is “evidence that evidence is missing”. That is meta-data is the shadows data casts and their form says much about the objects that cast them. With meta-meta-data being the absence of shadows where you would expect shadows to exist.

An example from the physical world is spotting camouflage by what is not there. If you put a tank somewhere and put scrim net etc over it, though the tank is not visible it’s shadow tells a story, as do physical tracks on/in the ground from the tank and others servicing it. That is meta-data that can be analysed and the tank identified as a target.

Now consider instead the tank is parked up next to a building and then covered with scrim net etc and care is taken to stop shadows forming and to eradicate tracks.

Well the thing about camouflage d objects is they still show up. If it looks like a tree or bush from above then it will have been there for sone time and will have effected the natural vegetation around it. It’s difficult if not impossible to get this right most of the time because it’s an absence of something that is the cause and this in turn causes another predictable absence. That is neta-meta-data that can be analysed to say something is wrong in that area and it should be scrutinized to find out what or why something is missing. But quickly again the general size of the area will reveal a potentially tank sized object is camouflaged.

Way way to many people don’t understand the power of meta-meta-data analysis.

Like traffic analysis did not leak into the public domain untill four decades after it was invented and has taken another four decades to become recognised as useful out side of Mil-Intel circles and become meta-data analysis. Meta-meta-data analysis was in use back at the time of the Falklands War, but four decades later is still effectively not in the public domain yet, so few actually know of it, lets hope it does not become another four decades before it becomes sufficiently recognised to be used outside of Mil-Intel etc.

Forest or the trees February 27, 2024 7:04 PM

And Apple’s ability to do this so efficiently speaks well about its algorithmic agility, which is probably more important than its particular cryptographic design.

This might be true even if only because Apple owns more distributed computers than Microsoft

echo February 28, 2024 10:52 AM

Way way to many people don’t understand the power of meta-meta-data analysis.

Like traffic analysis did not leak into the public domain untill four decades after it was invented and has taken another four decades to become recognised as useful out side of Mil-Intel circles and become meta-data analysis. Meta-meta-data analysis was in use back at the time of the Falklands War, but four decades later is still effectively not in the public domain yet, so few actually know of it, lets hope it does not become another four decades before it becomes sufficiently recognised to be used outside of Mil-Intel etc.

I get it and have never even read it in a book. I nobble you with it all the time. It’s fun!

BTW thanks for stealing my ideas to write a topic about using tools interchangeably from military and civil domains, and not give me an attagirl when I first mentioned it. I don’t need one but it would be nice and make you less grumpy.

Judith Butler’s work isn’t used much outside of the FLINTA domain. (I can jargon too!) Let’s hope we don’t have to wait another 30 years…

Clive Robinson February 28, 2024 5:44 PM

@ echo,

“BTW thanks for stealing my ideas to write a topic about using tools interchangeably from military and civil domains, and not give me an attagirl when I first mentioned it.”

More falsehoods in your mind yet again

You were not around on this blog when I was discussing it with Nick P, @Thoth, @Wael, @RobertT, @Figureitout and others.

This is like your claim I “stole Perun” from you when I simply said I’d watched his latest video that had dropped and recommended it…

How do you think I know,

“Meta-meta-data analysis was in use back at the time of the Falklands War”

Or what some may call the inside track on,

“traffic analysis did not leak into the public domain untill four decades after it was invented and has taken another four decades to become recognised as useful out side of Mil-Intel circles and become meta-data analysis.”

I was explaining both to lawyers when dealing with the misfeasance of Clive Corry at OfCom and how amongst other things he made “false instruments” and introduced them as evidence…

Things you have certainly never mentioned technically or in domain usage or even in parsing.

All people have to do is go back on this blog and see it for what it is.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.