[BUG] macOS 26.4 keychain (blobVersion=0x200) cannot be decrypted offline

[lyndonpm]

It seems it failed on version 26.4. When I called

kc, err := keychainbreaker.Open(openOpts...)
kc.Unlock(keychainbreaker.WithPassword(*password))

it returned the error: keychainbreaker: wrong key or password: invalid padding value 186: keychainbreaker: wrong key or password. Has anyone else encountered this?

---

[Update 2026-04-22 — maintainer @moonD4rk reverse-engineering notes]: Root cause identified. macOS 26.4 re-keyed the login keychain to blobVersion=0x200; the user password is now pre-processed by the Secure Enclave before reaching PBKDF2, which makes offline brute force infeasible. Recovery is still possible on the originating machine via a one-time masterKey capture, after which the existing --key flag fully decrypts everything offline. Full analysis in the comment below.

[Update 2026-07-11 — how to recover full data on macOS 26.4+] On the machine that created the keychain (with SIP temporarily disabled), capture the 24-byte master key with an lldb breakpoint on securityd's CSSM_DeriveKey, then decrypt everything offline with keychainbreaker dump --key=<hex> (or WithKey(<hex>) in the library). Step-by-step lldb commands are in the README: Recover the master key on macOS 26.4+ (v2). Method contributed by @gmazzola (details).

[moonD4rk]

@lyndonpm

Thanks for reporting this. We've added a --verbose flag in v0.2.5 to help diagnose this kind of issue. The verbose output contains only structural
metadata (no passwords, keys, or account names), so it's safe to share publicly.

$ go install github.com/moond4rk/keychainbreaker/cmd/keychainbreaker@latest

Could you please run the following and paste the output here?

$ keychainbreaker version
keychainbreaker 0.2.5
  commit: 3e211c3421fab03c8df16b75f3e89f555a5bee7b
  built:  2026-04-02T06:18:04Z

keychainbreaker dump with password

keychainbreaker dump -v

This will show us the keychain file structure, encryption parameters, and which stage of the unlock process is failing. For example:

Keychain: /Users/user/Library/Keychains/login.keychain-db
[INFO]  parsed header            signature=kych, version=65536
[DEBUG] parsed schema            tableCount=12
[DEBUG] parsed table             name=SchemaInfo, id=0x00000000, records=12
[DEBUG] parsed table             name=SchemaIndexes, id=0x00000001, records=90
[DEBUG] parsed table             name=SchemaAttributes, id=0x00000002, records=164
[DEBUG] parsed table             name=SchemaParsingModule, id=0x00000003, records=0
[DEBUG] parsed table             name=PublicKey, id=0x0000000F, records=0
[DEBUG] parsed table             name=PrivateKey, id=0x00000010, records=2
[DEBUG] parsed table             name=SymmetricKey, id=0x00000011, records=157
[DEBUG] parsed table             name=GenericPassword, id=0x80000000, records=141
[DEBUG] parsed table             name=InternetPassword, id=0x80000001, records=15
[DEBUG] parsed table             name=AppleSharePassword, id=0x80000002, records=0
[DEBUG] parsed table             name=X509Certificate, id=0x80001000, records=27
[DEBUG] parsed table             name=Metadata, id=0x80008000, records=1
[INFO]  parsed DBBlob            startCryptoBlob=120, totalLength=168, saltLen=20, ivLen=8, ciphertextLen=48
Enter keychain password:
[INFO]  master key derived       method=PBKDF2-SHA1, iterations=1000, keyLen=24
[DEBUG] decrypting DB key        ciphertextLen=48
[INFO]  DB key decrypted         keyLen=24
[INFO]  key list generated       keyCount=157
[DEBUG] GenericPasswords extracted total=141, decrypted=138, failed=0
[DEBUG] InternetPasswords extracted total=15, decrypted=13, failed=0
[DEBUG] PrivateKeys extracted    total=2, decrypted=2, failed=0
Extracted:
  Generic passwords:  141
  Internet passwords: 15
  Private keys:       2
  Certificates:       27

A few additional questions:

1. Was this keychain created on macOS 26, or migrated from an older macOS version?
2. Does security dump-keychain ~/Library/Keychains/login.keychain-db work on your system?

This will help us determine whether Apple changed the keychain format or encryption parameters in macOS 26.

[lyndonpm]

Here is output
Keychain: /Users/ws/Library/Keychains/login.keychain-db
[INFO] parsed header signature=kych, version=65536
[DEBUG] parsed schema tableCount=12
[DEBUG] parsed table name=SchemaInfo, id=0x00000000, records=12
[DEBUG] parsed table name=SchemaIndexes, id=0x00000001, records=90
[DEBUG] parsed table name=SchemaAttributes, id=0x00000002, records=164
[DEBUG] parsed table name=SchemaParsingModule, id=0x00000003, records=0
[DEBUG] parsed table name=PublicKey, id=0x0000000F, records=21
[DEBUG] parsed table name=PrivateKey, id=0x00000010, records=67
[DEBUG] parsed table name=SymmetricKey, id=0x00000011, records=74
[DEBUG] parsed table name=GenericPassword, id=0x80000000, records=57
[DEBUG] parsed table name=InternetPassword, id=0x80000001, records=16
[DEBUG] parsed table name=AppleSharePassword, id=0x80000002, records=0
[DEBUG] parsed table name=X509Certificate, id=0x80001000, records=6
[DEBUG] parsed table name=Metadata, id=0x80008000, records=1
[INFO] parsed DBBlob startCryptoBlob=120, totalLength=168, saltLen=20, ivLen=8, ciphertextLen=48
Enter keychain password:
[INFO] master key derived method=PBKDF2-SHA1, iterations=1000, keyLen=24
[DEBUG] decrypting DB key ciphertextLen=48
[ERROR] decrypt DB key failed error=keychainbreaker: wrong key or password: invalid padding value 186
Warning: keychainbreaker: wrong key or password: invalid padding value 186, exporting metadata only
[DEBUG] GenericPasswords extracted total=57, decrypted=0, failed=51
[DEBUG] InternetPasswords extracted total=16, decrypted=0, failed=11
[DEBUG] PrivateKeys extracted total=67, decrypted=0, failed=67
Extracted:
Generic passwords: 57 (metadata only)
Internet passwords: 16 (metadata only)
Private keys: 67 (metadata only)
Certificates: 6

1. Was this keychain created on macOS 26, or migrated from an older macOS version?
   Keychain migrated from an older macOS. Almost every version comes with an upgrade; before the upgrade, it's either version 26.2 or 26.3.
2. Does security dump-keychain ~/Library/Keychains/login.keychain-db work on your system?
   Yes, it wrok.

[moonD4rk]

@lyndonpm Thanks for the detailed output! This is very helpful.

Good news: the keychain file structure is identical to a working keychain on macOS 26.3 (same version, same DBBlob parameters, same table layout). So Apple has not changed the keychain format in macOS 26.4.

The failure happens at the DB key decryption stage, which typically indicates a password mismatch. Note that security dump-keychain (without -d) does not require a password, so it doesn't verify your password is correct.

Could you verify your password by running:

security lock-keychain ~/Library/Keychains/login.keychain-db

security unlock-keychain ~/Library/Keychains/login.keychain-db && echo "OK"

The first command locks the keychain, then the second attempts to unlock it with the password you enter. If the password is correct, it prints OK. If wrong, it shows an error.

Also: does your keychain password contain any non-ASCII characters (e.g., accented letters, CJK characters, symbols)?

[lyndonpm]

Yes, I am sure the password is correct.
Just a few numbers

[moonD4rk]

@lyndonpm Thanks for confirming the password is ASCII-only. That rules out encoding issues.

However, I've upgraded to macOS 26.4 myself and cannot reproduce this issue -- unlock works correctly with the same codebase.
To help narrow this down, could you please run these two commands and paste the exact output?

security lock-keychain ~/Library/Keychains/login.keychain-db

security unlock-keychain ~/Library/Keychains/login.keychain-db && echo "OK"

The first command locks the keychain. The second attempts to unlock it with your password -- if correct it prints OK, if wrong it shows an error.

This helps us determine whether macOS itself accepts your password, or if the keychain was re-keyed during a macOS upgrade.

I'll keep this issue open for a while waiting for the results. If there's no further response, I may close it as unable to reproduce.

[swobl]

I have the same problem on a freshly installed macOS 26.4, on a 26.3 to 26.4 upgrade, decryption works correctly.
A freshly installed macOS 26.4 returns an incorrect password, although it is 100% correct.

usermain@macos ~ % security lock-keychain ~/Library/Keychains/login.keychain-db
usermain@macos ~ % security unlock-keychain ~/Library/Keychains/login.keychain-db && echo "OK"
password to unlock /Users/usermain/Library/Keychains/login.keychain-db: 
OK
usermain@macos ~ %

[lyndonpm]

I have the same problem on a freshly installed macOS 26.4, on a 26.3 to 26.4 upgrade, decryption works correctly. A freshly installed macOS 26.4 returns an incorrect password, although it is 100% correct.

usermain@macos ~ % security lock-keychain ~/Library/Keychains/login.keychain-db
usermain@macos ~ % security unlock-keychain ~/Library/Keychains/login.keychain-db && echo "OK"
password to unlock /Users/usermain/Library/Keychains/login.keychain-db: 
OK
usermain@macos ~ %

It's the same as this. But my Mac was upgraded. I forget the exact version, it might be 26.3 or 26.2.

[moonD4rk]

Thanks @swobl for confirming the fresh install vs upgrade distinction -- this is the key finding.

Summary: We believe Apple changed the keychain encryption algorithm on freshly installed macOS 26. Upgraded systems retain the legacy keychain file, so decryption still works.

Evidence:

• File structure is identical between fresh and upgraded systems (same kych signature, DBBlob layout)
• Failure occurs at 3DES-CBC decryption -- output is garbage, causing PKCS#7 padding validation to fail
• Password is confirmed correct (security unlock-keychain succeeds)
• Apple's Platform Security Guide now describes keychain encryption as AES-256-GCM, and macOS 26 has deprecated 3DES

Next steps: We need a hex dump of the DBBlob region from a fresh macOS 26.4 keychain to confirm the algorithm change and identify the new encryption parameters.

[swobl]

Interestingly, this issue only affects login.keychain-db, decryption of any created custom keychain will work without issue.
This is likely related to an OS update and the CVE-2026-28864 patch. Perhaps they added a Secure Enclave?

[moonD4rk]

Where things stand

I've spent a good while reverse-engineering this one. Summary below.

What macOS 26.4 changed

The login keychain format bumped from blobVersion=0x100 to 0x200. Both fresh installs and upgrades re-wrap the keychain on first login after the update. Apple hasn't published details of the cryptographic change, and updated Security framework source for macOS 26 isn't out yet.

What I've been able to reverse-engineer

The cipher is unchanged — still PBKDF2-HMAC-SHA1 producing a 24-byte 3DES key over the DBBlob. What changed is that the password no longer reaches PBKDF2 directly:

v1:  password ─────────────────────────────► PBKDF2 ──► masterKey
v2:  password ──► SEP / keybag ──► 32B entropy ──► PBKDF2 ──► masterKey

Confirmed by tracing securityd:

• The 32-byte value fed into CSSM_DeriveKey as the PBKDF2 passphrase is deterministic per (device, password, keychain)
• The Stage 2 salt is not DBBlob.salt — it lives in CSSM_CONTEXT attributes that never touch disk
• The keybag holding DPSL / DPIC isn't on disk either (/var/keybags/ doesn't exist on 26.4+)
• Stage 1 is bound to the device's Secure Enclave UID key, which is hardware-fused and can't leave the chip

Result: offline brute force is no longer possible. Even with the keychain file and the correct password, Stage 1 can't be reproduced on another machine.

What I still don't know

• The exact KDF inside SEP (HKDF? PBKDF2-SHA256? something AKS-specific?)
• The Stage 2 iteration count
• Whether DPSL / DPIC can be pulled out of a live keybagd

Recovery on the originating machine

Everything after Stage 1 is identical to v1, so capturing the 24-byte masterKey once is enough — the existing --key option handles the rest offline.

In practice I've been pulling the masterKey by attaching lldb to securityd and breaking on CSSM_DeriveKey. It works but it's fiddly (SIP off + sudo + a bit of arm64e PAC/Mach juggling). Once captured the key stays valid as long as the keychain password doesn't change.

cc @lyndonpm @swobl