Encryption Performance Feedback — iPhone 16 Pro

TL;DR

Crypto choices (AES-256-GCM + scrypt) are solid. Performance is not — scrypt derivation takes 1.3s with N=4096, which is abnormally slow for this hardware. This points to an implementation issue rather than a configuration one.

Key Findings

1. Scrypt derivation is too slow for the parameters used

N=4096 is actually a low cost factor (OWASP recommends N=32768+), yet it takes 1.3s on an A18 Pro chip. A native C implementation should handle N=16384 in ~200-400ms on this device. This strongly suggests a non-native (pure Swift/JS) scrypt implementation is being used.

2. Encryption re-derives the key every time

Each encrypt call takes ~1.3s regardless of data size (32 bytes vs 1KB — no meaningful difference). The time is entirely spent on scrypt, not on AES. The scrypt cache clearly works in isolation (0.07ms on cache hit), but the encrypt doesn’t appear to use it.

3. UX impact

A full encrypt + decrypt cycle takes 2.82s for a simple API key. Users will notice this. Saving or retrieving credentials should feel instant.

Suggestions

1. Use the cached derived key for encrypt/decrypt — the cache mechanism already exists, it just needs to be wired into the encrypt path. This alone would drop encrypt time from 1.3s to single-digit ms.

2. Switch to a native scrypt implementation (or use CommonCrypto / a C binding). This would allow raising N to a more secure value (16384–32768) while still being faster than the current 1.3s at N=4096.

3. Consider Argon2id as an alternative KDF — it’s the current OWASP recommendation over scrypt, has good native iOS support, and is easier to tune for mobile.

Test Environment

∙ Device: iPhone 16 Pro (A18 Pro)

∙ Algorithm: AES-256-GCM

∙ KDF: scrypt (N=4096, r=8, p=1)