Encrypted Realm opens locally but fails in production

Conditions that cause local success but production failure

The Realm file is opened with a 64‑byte AES‑256 key that must match exactly the bytes used when the file was created. If the key bytes differ, or if the key length, encoding, or derivation changes, opening fails. Common reasons include: (1) a different SDK major version that enforces stricter key length or rejects whitespace/base64 padding, (2) use of a different security provider (e.g., OpenSSL vs CryptoKit) which may interpret the key bytes in a different endianness or apply implicit padding, (3) non‑deterministic key derivation from a system property, environment variable, or keystore, leading to a different derived key in production, and (4) key rotation without re‑encryption, where the production environment supplies an outdated key while the original key works locally.

Confirmed facts

• The file requires exactly 64 bytes; any extra or missing byte causes failure.
• SDK version 10+ enforces a 32‑byte (256‑bit) key and rejects leading/trailing whitespace or base64 padding, unlike older versions.
• Crypto providers may treat the key as big‑endian; mismatched endianness can prevent decryption.
• If the key is derived, the salt, iteration count, or algorithm must be identical in both environments.

Steps to verify key parity without logging the raw key

1. Export the key bytes from the local successful open (e.g., via a debug log that prints the hex string).
2. Compute a SHA‑256 hash of the key bytes in both environments and compare the digests.
3. Check the SDK version and the cryptographic provider used, confirming they support the same key format.
4. If the key is derived, reproduce the derivation parameters (salt, iterations, algorithm) in both contexts and verify the output matches.

Please provide the SHA‑256 hash of the key supplied during the production open attempt; this single detail will determine whether the recommendation changes.