It’s commonly claimed that software encryption, as used in APFS Encrypted format, incurs negligible overhead. The last time I looked at that was with Thunderbolt 3 SSDs connected to a Mac Studio M1 Max, when I found that varied according to the SSD. One of the three I tested then did show significant reductions in encrypted write speed, from 2.2 to 1.8 GB/s, but the fastest showed no change from its unencrypted write speed of 2.8 GB/s. This article reports new test results from a Mac mini M4 Pro with faster SSDs, one Thunderbolt 5 and the other USB4, and adds data for computing SHA256 hashes.

These are of particular interest, as not only are the unencrypted transfer speeds for both SSDs significantly higher than Thunderbolt 3, but the host has significantly faster CPU cores.

Two sets of measurements were made on each of the two SSDs:

• Stibium 1.2 running on macOS 15.5 Sequoia was used to measure read and write speeds over randomised sequences of a total of 53 GB in 160 files of 2 MB to 2 GB individual size.
• Stibium was used to measure the single file read speed of a 16.8 GB IPSW file, and Dintch was used to measure the time taken to stream the file in and compute its SHA256 digest, using CryptoKit.

Read and write speeds

Results of the first series of tests showed both SSDs performed as expected when using plain APFS, with read and write speeds of 5.3 GB/s for TB5, and 3.7 GB/s for USB4.

Small reductions in read speed were seen in both SSDs when using APFS Encrypted, to about 98% and 95% of their unencrypted read speed. Although there was a similar small reduction in write speed for USB4, to 97%, that seen in the Thunderbolt 5 SSD was greater, with a fall from 5.3 to 4.7 GB/s (89%). Both sets of tests were repeated for that SSD, allowing ample time for the SLC cache to be emptied after each set of write tests, and results remained essentially the same.

Although write speed to APFS Encrypted for this Thunderbolt 5 SSD remained well above that for USB4, encryption brought a reduction in speed of just over 10%, more than I had anticipated.

Hash computation

SHA256 and SHA512 digests are now used to check file data integrity. Both are computationally intensive, and I have previously reported that reading files of substantial size and computing their digests using CryptoKit proceeds at about 3 GB/s for files stored on the fast internal SSD of a Mac mini M4 Pro.

With the Thunderbolt 5 SSD, a plain file of 16.8 GB was read at 6.5 GB/s, and encrypted at 4.7 GB/s. SHA256 digest computation was performed at 2.6 GB/s from plain APFS, and 2.2 GB/s from APFS Encrypted, both well below that from the internal SSD, and less than half the speed of just reading the file.

Although the USB4 SSD was inevitably slower on the read tests, at 3.8 GB/s, encryption had little effect, at 3.7 GB/s. SHA256 digest computation was, if anything, faster than with Thunderbolt 5, at 2.8 GB/s plain, and 2.7 GB/s encrypted.

Conclusions

Although there may well be differences with other Thunderbolt 5 and USB4 SSDs, and more extensive results would be helpful:

• Whether plain or encrypted APFS, Thunderbolt 5 SSDs are substantially faster than USB4.
• Encryption can result in significantly lower write speeds on some Thunderbolt 5 SSDs.
• Otherwise, encryption has only small effects on read and write speeds.
• Computation of SHA256 digests is significantly slower than encryption, and ranges between 2.2-2.8 GB/s on larger files.
• This suggests that, even in faster M4 chips, CPU performance limits the speed of software encryption, and even more so for SHA256 digest computation.

Much of the data handled on and off our Macs and devices is protected by encryption. That has been designed to ensure encryption can’t be broken in a reasonable amount of time using current and future computing resources. Using conventional computers, for instance, it would take a great many years to break data encrypted using 256-bit AES, so in practice this has been considered to fully secure, for the past.

Threat

For the last 50 years or so, researchers have been working on quantum computers that could radically change that. Instead of using normal binary bits with values of 0 and 1, those use qubits measured in terms of probability, making them non-deterministic. That changes the way they work, and some tough problems in the binary world can be speeded up so much that, given a suitable quantum computer, they could compute in far shorter times. This has already been applied to greatly reduce search times in big data, and has the potential to break most recent forms of encryption.

Progress in making suitably powerful quantum computers to be able to decrypt data encrypted using classical techniques has been slow, but we’re now reaching the stage where that’s likely to be feasible in the next year or three. Now is the time to start deploying more advanced forms of encryption to protect our data from the imminent future.

Data in transit

In February last year, Apple announced that iMessage was transitioning to the use of protocols that are quantum-secure, and those were introduced the following month in macOS 14.4, iOS and iPadOS 17.4 and watchOS 10.4. When macOS 26 Tahoe and its matching OSes are released in a couple of months, they bring further important steps towards fully secure encryption, in encrypted network connections using quantum-secure mechanisms in TLS 1.3.

Classical encryption is at its most vulnerable when encryption keys are exchanged over the Internet, and public key systems can be completely broken by quantum methods. Thus, Apple’s first changes are being made to protect data in transit, where it can be intercepted and stored for later decryption using a quantum computer. Securing iMessage is an important start, and the new features in Tahoe and its sisters extend similarly improved protection to other data transfers.

Apple’s operating systems provide support for encryption and related techniques in CryptoKit, making quantum-secure methods available to third-party apps as well. For OS 26, CryptoKit gains Module-Lattice based key encapsulation or ML-KEM, part of the FIPS 203 primary standard for general encryption. Signatures gain the Module-Lattice based digital signature algorithm or ML-DSA, part of FIPS 204.

Data in storage

Whereas public key cryptography systems can be completely broken by quantum attacks, the news for symmetric key schemes such as those used in FileVault and APFS encryption is considerably better. Although quantum computers will be able to break classical techniques more quickly, that should prove neither quick nor easy.

In Intel Macs with T2 chips and Apple silicon Macs, encryption keys are protected by the Secure Enclave, never leave it, and are never exposed to the main CPU. Attempts to gain access through the Secure Enclave are subject to robust defences: for example, the Secure Enclave Processor allows only 5 attempts to enter a Mac’s password before it increases the time interval enforced between entry attempts, and after 30 unsuccessful attempts no more are allowed at all, and the Mac has to be fully wiped and reset.

Trying to remove internal storage is designed to frustrate the attacker. Although internal storage is referred to as an SSD, the storage used isn’t complete in the sense that you couldn’t remove it and install it in another computer, and most of its disk controller functionality is performed by sections in the host chip, including its Secure Enclave. Even models like the Mac Studio that have socketed storage don’t make this easy: remove its special SSD module and it won’t work in another Studio unless it has been completely wiped and reset, destroying its keys and contents.

Apple’s strategy for the protection of encrypted internal storage is thus intended to block access at every level, so that post-quantum brute-force decryption would have little if any impact should it become available in a few years. The standard encryption method used, AES-256 in XTS mode, may need to be revised as quantum decryption becomes more feasible, and Apple is now recommending that doubling the key size should be sufficient to make encryption suitably resistant to forcing with a quantum computer.

Summary

• Future quantum computers will be able to break some classical encryption methods.
• Public key methods used to protect data in transit across the Internet are the most vulnerable to quantum attack.
• macOS 14.4 and iOS 17.4 have started progressively replacing iMessage protection to make it resistant to quantum attack.
• OS 26 will extend that protection to cover connections over TLS 1.3, where supported by servers.
• Protection already provided to stored data, such as FileVault, is considered to remain robust.
• Encryption of static data can be made more robust to quantum cryptography by doubling key size from 256 to 512 bits.

Resources

Quantum computing (Wikipedia)
Post-quantum cryptography (Wikipedia)
FIPS 203-206 (NIST standards)
Securing iMessage with PQ3 (Apple)
macOS Tahoe TLS 1.3 support (Apple)
Cathie Yun presentation Get ahead with quantum-secure cryptography, WWDC 2025 (via Apple Developer app etc.)
CryptoKit for developers (Apple)

From its first announcement of Apple silicon Macs on 22 June 2020, there has been speculation as to when support of Intel models will cease. Now Apple has given exceptionally clear details of its future intentions, and we have a clearer idea of what’s coming in macOS Tahoe, we can make plans at last. This article looks at the years ahead. In each case, major events are scheduled to occur with the annual transition of macOS to the next major version, normally in September-October.

2025

Final security update for macOS 13 Ventura, ending support for:

• iMac 18,1-3
• MacBook 10,1
• MacBook Pro 14,1-3.

If you’re still running Ventura on a Mac capable of Sonoma or later, now is the time to plan the upgrade.

2026

Final security update for macOS 14 Sonoma, ending support for:

• MacBook Air 8,1-2.

First release of an Arm-only version of macOS, 27. However, that and all its updates will continue to include full support for running Intel binaries using Rosetta 2 translation. macOS 27 will be the last major version that supports Rosetta 2 fully in Virtual Machines.

2027

Final security update for macOS 15 Sequoia, ending support for:

• iMac 19,1-2
• iMac Pro
• Mac mini 8,1
• MacBook Air 9,1
• MacBook Pro 15,1-4 16,3.

First release of macOS 28, with full Rosetta 2 support removed. Limited Intel binary support will continue for “older unmaintained gaming titles” only. As a result, virtual machines running macOS 28 will no longer be able to run most Intel binaries.

2028

Final security update for macOS 26 Tahoe, ending support for all remaining Intel models:

• iMac 20,1-2
• Mac Pro 7,1
• MacBook Pro 16,1-2 16,4.

T2 firmware updates are almost certain to cease with the end of support for macOS 26. Major third-party vendors are likely to stop providing Universal binaries, as they too drop support for macOS 26 and Intel models. Apple may decide to remove x86 support from Xcode 29, but hasn’t yet made any statement either way.

Benefits of upgrading macOS in Intel models

Although macOS Sequoia and Tahoe have brought some new features for Intel Macs, much of Apple’s emphasis now requires Arm systems. Major reasons for upgrading your Intel Mac to the most recent version of macOS it can run include:

• Third-party support. Major software vendors like Microsoft normally only support their products on versions of macOS still supported by Apple.
• Safari is only updated in supported versions of macOS.
• Bug fixes. Although new versions bring their own bugs, the chances of an existing bug being fixed in the current release of macOS are far greater than it being fixed in an older version.
• Security vulnerabilities. Only the current version of macOS gets a full set of fixes in each round of security updates, and the older two supported versions often lag the current one.
• Enhancements. Some new features are still provided for both platforms.
• Compatibility. If you already use Apple silicon Macs, or intend doing so, they are more compatible when running the same version of macOS. One topical example is Tahoe’s new ASIF disk image format.
• Quantum-secure encryption. Apple has already started to transition to cryptographic techniques designed to remain secure as and when quantum computers are used in the future to break older methods. This started with iMessage last year, and Apple has announced that macOS 26 Tahoe will support quantum-secure encryption in TLS. This is unlikely to be added retrospectively to older versions of macOS.

I hope you find that helpful in your planning, and wish you success in whatever you choose.

We rely on FileVault and APFS to protect our secrets by encrypting the volumes containing our documents and data. How they do that is a mystery to many, and raises important questions such as the role our passwords play, and how recovery keys work. This article attempts to demystify them.

Naïve encryption

A simple scheme to encrypt a disk or volume might be to take the user password, somehow turn it into a key suitable for the encryption method to be used, and employ that to encrypt and decrypt the data as it’s transferred between disk storage and memory.

There are lots of weaknesses and difficulties with that. Even using a ‘robust’ user password, it’s not going to be memorable, sufficiently long or hard to crack, and there’s no scope for recovery if that password is lost or forgotten.

FileVault base encryption

In Macs with T2 or Apple silicon chips when FileVault is disabled, everything in the Data volume stored on their internal SSD is still encrypted, but without any user password. This is performed in the Secure Enclave, which both handles the keys and performs the encryption/decryption. That ensures the keys used never leave the Secure Enclave, so are as well-protected as possible.

Generating the key used to encrypt the volume, the Volume Encryption Key or VEK, requires two huge numbers, a hardware key unique to that Mac, and the xART key generated by the Secure Enclave as a random number. The former ties the encryption to that Mac, and the latter ensures that an intruder can’t repeat generation of the same VEK even if it does know the hardware key. When you use Erase All Content and Settings (EACAS), the VEK is securely erased, rendering the encrypted data inaccessible, and there’s no means to either recover or recreate it.

This scheme lets the Mac automatically unlock decryption, but doesn’t put that in the control of the user, who therefore needs to enable FileVault to get full protection.

FileVault full encryption

Rather than trying to incorporate a user password or other key into the VEK, like many other encryption systems FileVault does this by encrypting the VEK using a Key Encryption Key or KEK, a process known as wrapping.

When you enter your FileVault password, that’s passed to the Secure Enclave, where it’s combined with the hardware key to generate the KEK, and that’s then used together with hardware and xART keys to decrypt or unwrap the VEK used for decryption/encryption.

This has several important benefits. As the KEK can be changed without producing a new VEK, the user password can be changed without the contents of the protected volume having to be fully decrypted and encrypted again. It’s also possible to generate multiple KEKs to support the use of recovery keys that can be used to unlock the VEK when the user’s password is lost or forgotten. Institutional keys can be created to unlock multiple KEKs and VEKs where an organisation might need access to protected storage in multiple Macs.

APFS encryption

True FileVault requires all keys to be stored in the Secure Enclave, and never released outside it. Intel Macs without T2 chips, and other protected volumes such as those on external storage can’t use that, and in the case of removable storage need an alternative that stays on the disk. For that, APFS uses the AES Key Wrap Specification in RFC 3394, using a secret such as a password to maintain confidentiality of every key.

APFS also uses separate VEKs and KEKs, so enabling the use of multiple KEKs for a single VEK, and the potential to change a KEK without having to decrypt and re-encrypt the whole volume, as in FileVault. In APFS, VEKs and KEKs are stored in and accessed from Keybags associated with both containers and volumes. The Container Keybag contains wrapped VEKs for each encrypted volume within that container, together with the location of each encrypted volume’s keybag. The Volume Keybag contains one or more wrapped KEKs for that volume, and an optional passphrase hint. These are shown in the diagram below.

Apple’s documentation refers to several secrets that can be used to wrap a KEK, including a user password, an individual recovery key, an institutional recovery key, and an unspecified mechanism implemented through iCloud. Currently, for normal software encryption in APFS, only two of those appear accessible: a user password is supported in both Disk Utility and diskutil‘s apfs verb, while diskutil also supports use of an institutional recovery key through its -recoverykeychain options. Individual and iCloud recovery keys only appear available when using FileVault, in this case implemented in software, either on Intel Macs without a T2 chip, or on all Macs when encrypting an external volume.

Because keybags are stored on the disk containing the encrypted volume, if the disk is connected to another Mac, when macOS tries to mount that volume, the user will be prompted to enter its password, and can then gain access to its contents. When FileVault is used to protect a Data volume on the internal SSD of a T2 or Apple silicon Mac, that volume can only be unlocked through the Secure Enclave of that Mac, and it isn’t possible to unlock it from another Mac (that’s also true when FileVault hasn’t been enabled on that volume).

In the next few months, many of us will replace our Macs, and pass on our old ones to relatives, purchasers, or for recycling. This article explains how best to prepare your Mac so that you don’t unintentionally give away anything sensitive to its next owner, or lose anything in the process.

Back up and sign out

Your first steps should ensure that your Mac doesn’t take with it anything that you might miss. That means making at least one full backup, and ensuring you have stored additional copies of important documents in archives.

One store you might forget are its keychains, that could contain old passwords that you might need to recover in the future. While you’re most likely keeping current passwords in the keychain shared in iCloud, older ones might remain, particularly in your old Mac’s login keychain. That should be in its backup, but keeping another copy is wise, and will include any security certificates you might not have used recently.

Next come third-party apps and subscriptions that need to be signed out or transferred. Check carefully through the Applications folder to ensure that you haven’t forgotten any that are still valid. Among those is the need to deauthorise your old Mac for Apple media, something you should do using one of its media apps such as Music or TV, or iTunes if it’s running an older version of macOS.

If it’s an Intel Mac and its firmware password has been enabled, start it up in Recovery and disable that before going any further.

T2 and Apple silicon

If it’s an Intel Mac with a T2 chip, or an Apple silicon Mac, your task is almost complete, as all that’s required now is to Erase All Content and Settings (EACAS).

There is one important exception to this, if you added any more containers or volumes to its internal storage. They aren’t protected by FileVault and the Secure Enclave, so need to be erased separately before using EACAS. This is most secure if those extra volumes or containers were also encrypted, but as you’re about to use EACAS, that should make it well nigh impossible for anyone to piece together the remains of your extra volumes on its SSD.

Start EACAS from System Settings > General > Transfer or Reset > Erase All Content and Settings…. In older versions of macOS that still use System Preferences, open them and it’s offered as a command in the app menu there. Once that’s done, all that remains is to remove that Mac from your account in the Apple Account pane on another Mac or device.

EACAS handles all the signing out that’s required, and disables Find My Mac and Activation Lock for you. But most importantly it ensures that no one can access the contents of its Data volume, by destroying the encryption keys used to encrypt that volume. Without those keys, it’s practically impossible for anyone to break that encryption and recover any of the protected data.

If your old Mac is going for recycling, you might like to open it up and physically destroy its internal storage, just to be safe.

Intel Macs without T2

EACAS is only available in Macs with T2 or Apple silicon chips. If your Mac doesn’t have either of those you’ll need to perform each step manually, going through

1. disable Find My Mac and Activation Lock
2. sign out of iCloud
3. sign out of iMessage
4. reset NVRAM
5. unpair all Bluetooth devices
6. erase the Mac and, if you’re passing it on to someone else, install macOS
7. remove that Mac from your account in Apple ID settings.

The biggest challenge is how to erase its storage securely. If it’s going for recycling, you can open it up and physically disrupt its storage, but when you’re passing that Mac on you obviously can’t do that.

If its internal storage is a hard disk, or Fusion Drive, the traditional solution is to perform a Secure Erase using Disk Utility. However, Apple has removed that from Sequoia, so you’ll need to create an external bootable disk with Sonoma or earlier to enable you to do that.

Secure Erase neither works nor is it wise when trying to clean an internal SSD, though. The most practical solution is to turn FileVault on, leave the Mac to complete encrypting the whole of its Data volume, then start it up from an external bootable disk and erase the internal SSD from there.

.AppleSetupDone

In the past, some have recommended deleting the .AppleSetupDone file in /var/db/, which then caused the Setup Assistant to launch when that Mac was next started up, to create a new local user. For a Mac that’s going to be used by someone else, this has never been a wise move, and Apple has stopped that from working in macOS Sonoma 14.0 and later. It’s far better to use EACAS to reset that Mac, then Setup Assistant will run when it next starts up.

Checklist

• Back up
• Make additional copies of important documents, keychain(s)
• Sign out from or transfer third-party apps
• Deauthorise for Apple media
• Disable firmware password (Intel)
• Delete any extra containers or volumes if they’ve been created on internal storage.
• Erase All Content and Settings (T2, Apple silicon), or manual list above
• Remove from Apple Account
• Physically destroy internal storage (if recycling).