Public service announcement: Apple adds PQC support to CryptoKit

[Arne Padmos]

Hi all,

Apple just updated the CryptoKit documentation: https://developer.apple.com/documentation/cryptokit

The new version of CryptoKit introduces support for MLKEM768, MLKEM1024, and XWingMLKEM768X25519, as well as MLDSA65 and MLDSA87.

The related technical session should be available sometime later today at https://developer.apple.com/videos/play/wwdc2025/314/. However, the blurb indicates that Apple's TLS stack will introduce PQC support, so I'm hopeful that all major browsers will have hybrid ML-KEM support sometime this fall.

Regards,

Arne

[Arne Padmos]

Takeaways from the WWDC25 video on PQC:

- Apple PQC strategy is hybrids, both for encryption and signing, as well as moving to 256-bit keys

- Recommended high-level PQC CryptoKit API is use of HPKE with XWingMLKEM768X25519_SHA256_AES_GCM_256 cipher suite

- App development case study mentions end-to-end encryption multiple times, sample code uses PQ HPKE, but case study lacks coverage of integrity risks / spoofed payloads

- Hybrid PQC signatures are recommended but are left to the application to implement

- TLS with PQC support shipping in iOS 26, including in Safari and various frameworks (PQC enabled by default in URLSession and Network.framework)

- Commitment of back-end support – 'enabled on the client side and rolling out on the server side' – but no timelines given

- Call-out of CloudKit, Apple Push Notifications, and iCloud Private Relay system services enabling PQC in TLS

- Safari, Weather, and Maps called out as examples of apps handling sensitive user data for which TLS PQC support will be rolled out

- Secure Enclave support for ML-KEM and ML-DSA operations

- No specification yet of which TLS key exchange will be supported (but given the inclusion of XWingMLKEM768X25519_SHA256_AES_GCM_256 in CryptoKit, I'm guessing at least X25519MLKEM768)

- No mention of macOS, iPadOS, etc.

[Daniel Apon]

I imagine that there will be reasonable questions around the difference between "256-bit keys" and "MLKEM768," but regardless, sweet!

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/29e4cf4a-aaf9-4c3e-82d9-5adf137ed73cn%40list.nist.gov.

[Kris Kwiatkowski]

On 09/06/2025 23:18, Arne Padmos wrote:

- No specification yet of which TLS key exchange will be supported (but given the inclusion of XWingMLKEM768X25519_SHA256_AES_GCM_256 in CryptoKit, I'm guessing at least X25519MLKEM768)

I think it is here: https://support.apple.com/en-us/122756

[Arne Padmos]

On Tuesday, 10 June 2025 at 03:46:07 UTC+2 Daniel Apon wrote:

I imagine that there will be reasonable questions around the difference between "256-bit keys" and "MLKEM768," but regardless, sweet!

256-bit symmetric keys that is. Some relevant historical background to different symmetric and asymmetric security levels in CSNA that might also be at play here: "In fact we had wanted to use AES -128 and AES-192, but a quick survey of AES implementations (hardware centric, I believe) showed that there were very few implemented AES-192, whence the decision to go with AES-128 and AES-256 in Suite B, paired with P256 and P384. All of the crypt purists grumbled endlessly about the mismatch betwixt AES-256 and P384." from https://mailarchive.ietf.org/arch/msg/cfrg/lyP6VTm2h1asZSCNn7ogNywD5TU/

Note that the recently published ECCG Agreed Cryptographic Mechanisms version 2 available at https://certification.enisa.europa.eu/publications/eucc-guidelines-cryptography_en includes the following note: "In contexts where resistance against attacks leveraging quantum computers is required, it is recommended not to use block ciphers with key size smaller than 192 bits."

Given limited support for AES-192, a combination of hybrid ML-KEM-768 and AES-256 seems like a logical approach.

[Arne Padmos]

Indeed, thanks for sharing. To save people a click: TLS 1.3 on iOS 26, iPadOS 26, macOS Tahoe 26, and visionOS 26 will support X25519MLKEM768 and TLS_AES_256_GCM_SHA384, with X25519MLKEM768 key shares included in the ClientHello. No mention of whether other hybrids will be supported, but let's hope not so that for general-purpose TLS we can all converge on only having to support X25519MLKEM768.