axiom-cryptokit

CryptoKit

Authenticated encryption, digital signatures, key agreement, Secure Enclave key management, and quantum-secure cryptography for iOS apps.

When to Use This Skill

Use when you need to:

• ☑ Encrypt data at rest or in transit beyond what TLS/Data Protection provides
• ☑ Sign payloads for integrity verification (receipts, tokens, API requests)
• ☑ Generate or manage cryptographic keys (including Secure Enclave hardware keys)
• ☑ Migrate from CommonCrypto C API to CryptoKit
• ☑ Implement key agreement (ECDH) for end-to-end encryption
• ☑ Use HPKE for modern asymmetric encryption
• ☑ Adopt quantum-secure algorithms (ML-KEM, ML-DSA) for post-quantum readiness
• ☑ Interoperate with server-side Swift Crypto or non-Apple platforms

Example Prompts

"How do I encrypt user data with AES-GCM?" "How do I sign a payload and verify it on my server?" "How do I use the Secure Enclave to protect a signing key?" "I'm using CommonCrypto — should I migrate to CryptoKit?" "How do I do ECDH key agreement for end-to-end encryption?" "How do I make my app quantum-secure?" "My server can't verify signatures from my iOS app" "What's the difference between P256 and Curve25519?"

Red Flags

Signs you're making this harder or less secure than it needs to be:

• ❌ Using CommonCrypto C API when CryptoKit exists — Buffer management nightmares, no authenticated encryption, manual IV handling. CryptoKit provides memory-safe, authenticated encryption in one call. Migration takes minutes per call site.
• ❌ AES-CBC without authentication — Ciphertext is malleable. Padding oracle attacks let an attacker decrypt data one byte at a time without the key. AES-GCM (CryptoKit's default) provides authenticated encryption — tampering is detected automatically.
• ❌ Rolling your own crypto protocol — Timing attacks, padding oracles, nonce reuse. Unless you are a professional cryptographer, use CryptoKit's high-level APIs. Apple's security team designed them to prevent exactly these mistakes.
• ❌ Ignoring Secure Enclave for signing keys — "Too complex" is wrong. The SE API is nearly identical to software P256. SE keys survive jailbreaks. If the key protects money, health data, or identity, SE is the correct choice at zero extra effort.
• ❌ Using AES-128 when AES-256 costs nothing extra — Grover's algorithm halves symmetric key strength on quantum computers. AES-128 drops to 64-bit security. AES-256 drops to 128-bit — still safe. The performance difference is negligible.
• ❌ Force-unwrapping crypto operations — AES.GCM.open and signature verification throw on failure. Force-unwrapping masks authentication failures and turns security errors into crashes. Always use try/catch.
• ❌ Storing raw private keys in UserDefaults — Readable from device backups, accessible on jailbroken devices, visible in plaintext in the app's plist. Use Keychain for software keys, Secure Enclave for hardware-bound keys.