Use Apple CryptoKit for Swift cryptographic primitives. Use when hashing with SHA-2 or SHA-3, generating HMACs, encrypting with AES-GCM or ChaChaPoly, signing with P256/P384/P521/Curve25519 or ML-DSA keys, performing ECDH, HPKE, ML-KEM, or X-Wing key exchange, using Secure Enclave CryptoKit keys, or

CryptoKit Apple CryptoKit provides a Swift native API for cryptographic operations: hashing, message authentication, symmetric encryption, public key signing, key agreement, HPKE, quantum secure key encapsulation/signing, and Secure Enclave backed keys. Most core primitives are available on iOS 13+; check availability for HPKE (iOS 17+) and SHA 3 / post quantum APIs (iOS 26+). Prefer CryptoKit over CommonCrypto or raw Security framework APIs for new cryptographic primitive code targeting Swift 6.3+. Contents [Hashing]( hashing) [HMAC]( hmac) [Symmetric Encryption]( symmetric encryption) [Public Key Signing]( public key signing) [Key Agreement]( key agreement) [HPKE]( hpke) [Post Quantum CryptoKit]( post quantum cryptokit) [Secure Enclave]( secure enclave) [Common Mistakes]( common mistakes) [Review Checklist]( review checklist) [References]( references) Hashing Use SHA256/SHA384/SHA512 on iOS 13+; SHA3 256/SHA3 384/SHA3 512 require iOS 26+. All conform to HashFunction . One shot hashing SHA 3 availability Use SHA 3 only behind an availability check unless the deployment target is iOS 26+: Incremental hashing For large data or streaming input, hash incrementally: Digest comparison Compare CryptoKit digest values directly. Do not convert digests to strings or arrays for security sensitive equality checks. HMAC Use HMAC when a protocol requires keyed message authentication; verify with isValidAuthenticationCode rather than comparing serialized values yourself. Computing an authentication code Verifying an authentication code Incremental HMAC Symmetric Encryption CryptoKit provides two authenticated encryption ciphers: AES GCM and ChaChaPoly. Both produce a sealed box containing the nonce, ciphertext, and authentication tag. AES GCM The default choice for symmetric encryption. Hardware accelerated on Apple silicon. ChaChaPoly Use ChaChaPoly when AES hardware acceleration is unavailable or when interoperating with protocols that require ChaCha20 Poly1305 (e.g., TLS, WireGuard). Authenticated data Both ciphers support additional authenticated data (AAD). The AAD is authenticated but not encrypted useful for metadata that must remain in the clear but be tamper proof. Use .bits256 as the default SymmetricKey size for AES 256 GCM or ChaChaPoly. To create a key from existing data: Public Key Signing CryptoKit supports ECDSA signing with NIST curves and Ed25519 via Curve25519. NIST curves: P256, P384, P521 P384 and P521 use the same API substitute the curve name. NIST keys support DER, PEM, X9.63, and raw representations. See [references/cryptokit patterns.md](references/cryptokit patterns.md) for serialization examples. Curve25519 / Ed25519 Curve25519 keys use rawRepresentation only (no DER/PEM/X9.63). Choosing a curve Curve Signature Scheme Key Size Typical Use P256 ECDSA 256 bit General purpose; Secure Enclave support P384 ECDSA 384 bit Higher security requirements P521 ECDSA 521 bit Maximum NIST security level Curve25519 Ed25519 256 bit Fast; simple API; no Secure Enclave Use P256 by default. Use Curve25519 when interoperating with Ed25519 based protocols. Key Agreement Key agreement lets two parties derive a shared symmetric key from their public/private key pairs using ECDH. ECDH with P256 Bob computes the same sharedSecret using his private key and Alice's public key. Both derive the same symmetricKey . ECDH with Curve25519 Key derivation functions SharedSecret is not directly usable as a SymmetricKey . Always derive a key using one of: Method Standard Use hkdfDerivedSymmetricKey HKDF (RFC 5869) Recommended default x963DerivedSymmetricKey ANSI X9.63 Interop with X9.63 systems Always provide a non empty sharedInfo string to bind the derived key to a specific protocol context. HPKE HPKE is available on iOS 17+ for public key encryption workflows. Prefer it over hand rolled ECDH + HKDF + AEAD protocols when encrypting to a recipient public key. HPKE.Sender and HPKE.Recipient are stateful; keep them as var , send encapsulatedKey alongside the ciphertext, and open messages in the same order they were sealed. See [references/cryptokit patterns.md](references/cryptokit patterns.md) for ciphersuite selection and post quantum HPKE. Post Quantum CryptoKit iOS 26+ adds quantum secure APIs: Key encapsulation: MLKEM768 , MLKEM1024 Hybrid HPKE: XWingMLKEM768X25519 with .XWingMLKEM768X25519 SHA256 AES GCM 256 Digital signatures: MLDSA65 , MLDSA87 Secure Enclave variants: SecureEnclave.MLKEM768 , SecureEnclave.MLKEM1024 , SecureEnclave.MLDSA65 , SecureEnclave.MLDSA87 Use hybrid mechanisms for migration when both classical and quantum secure resistance matter. Account for much larger public keys, ciphertexts, and signatures than P256 or Curve25519. Secure Enclave The Secure Enclave provides hardware backed key storage. Private keys never leave the hardware. For classical elliptic curve CryptoKit, Secure Enclave supports P256 signing and key agreement. On iOS 26+ supported hardware, CryptoKit also exposes Secure Enclave ML KEM key encapsulation and ML DSA signing types. Availability check Creating a Secure Enclave signing key Access control Use SecAccessControl with .privateKeyUsage when the key requires biometric or passcode gated use. Keep detailed Keychain policy decisions in the swift security domain. Persisting Secure Enclave keys The dataRepresentation is an encrypted blob that only the same device's Secure Enclave can restore. Store it in the Keychain. Secure Enclave key agreement Common Mistakes 1. Using the shared secret directly as a key 2. Reusing nonces 3. Ignoring authentication tag verification 4. Using Insecure hashes for security Insecure.MD5 and Insecure.SHA1 exist only for legacy compatibility (checksum verification, protocol interop). Never use them for new security sensitive operations. 5. Storing symmetric keys in UserDefaults 6. Not checking Secure Enclave availability Review Checklist [ ] Using CryptoKit, not CommonCrypto or raw Security framework [ ] SHA256+ for hashing; no MD5/SHA1 for security purposes [ ] HMAC verification uses isValidAuthenticationCode (constant time) [ ] AES GCM or ChaChaPoly for symmetric encryption; 256 bit keys [ ] Nonces are random (default) not hardcoded or reused [ ] Authenticated data (AAD) used where metadata needs integrity [ ] SharedSecret derived via HKDF, not used directly [ ] sharedInfo parameter is non empty and context specific [ ] HPKE used instead of custom ECDH+HKDF+AEAD for recipient public key encryption on iOS 17+ [ ] SHA 3 and post quantum APIs guarded with iOS 26+ availability [ ] Secure Enclave availability checked before use [ ] Secure Enclave key dataRepresentation stored in Keychain [ ] Private keys not logged, printed, or serialized unnecessarily [ ] Symmetric keys stored in Keychain, not UserDefaults or files [ ] Encryption export compliance considered ( ITSAppUsesNonExemptEncryption ) References Extended patterns (key serialization, Insecure module, Keychain integration, AES key wrapping, HPKE): [references/cryptokit patterns.md](references/cryptokit patterns.md) Apple documentation: [CryptoKit](https://sosumi.ai/documentation/cryptokit) Apple documentation: [HPKE](https://sosumi.ai/documentation/cryptokit/hpke) Apple documentation: [Quantum secure workflows](https://sosumi.ai/documentation/cryptokit/enhancing your app s privacy and security with quantum secure workflows) Apple sample: [Performing Common Cryptographic Operations](https://sosumi.ai/documentation/cryptokit/performing common cryptographic operations) Apple sample: [Storing CryptoKit Keys in the Keychain](https://sosumi.ai/documentation/cryptokit/storing cryptokit keys in the keychain)