FAQ: LockRoot Technical Specifications

This FAQ addresses the cryptographic design, memory management, and platform integration specifics of the LockRoot local password manager. It is intended for developers, security researchers, and systems engineers evaluating the threat model.

1. Why does LockRoot use Argon2id instead of PBKDF2 or bcrypt?

PBKDF2 and bcrypt require negligible memory to execute. This allows an attacker who steals an encrypted vault to use highly parallelized GPU clusters (e.g., Hashcat) to compute millions of hashes per second. Argon2id (RFC 9106) is a memory-hard KDF. LockRoot requires 64 MiB of RAM per hash attempt. This creates a severe memory bandwidth bottleneck on GPUs, drastically reducing the attacker’s hash rate and making brute-forcing mathematically unfeasible for strong passwords.

2. How does the AEAD tag prevent vault tampering?

LockRoot uses AES-256-GCM, an Authenticated Encryption with Associated Data (AEAD) cipher. GCM calculates a 16-byte authentication tag over the ciphertext and any provided Associated Data (AAD). LockRoot constructs a pipe-delimited string containing all public envelope metadata (KDF parameters, ciphers, salts) and binds it into the AAD. If an attacker modifies the iteration count in the JSON envelope, the AAD changes, the calculated tag won’t match the stored tag, and decryption mathematically fails.

3. Does LockRoot use symmetric or asymmetric encryption?

LockRoot relies exclusively on symmetric cryptography (AES-256-GCM). Because it is a local, offline password manager, there is no server infrastructure and no need for key exchange protocols like RSA or Diffie-Hellman. The 256-bit encryption key is derived directly from the master password.

4. How does LockRoot handle memory erasure in Kotlin and Java?

The JVM Just-In-Time (JIT) compiler often eliminates dead code, meaning an Arrays.fill(bytes, 0) instruction might be stripped if the array isn’t read afterward. LockRoot bypasses this by utilizing a @Volatile sink variable (wipeSink = bytes.hashCode()). Forcing a read operation on the zeroed array guarantees the JIT compiler executes the erasure instruction.

5. Why is Swift’s String considered unsafe for cryptography?

Swift strings are immutable and handled opaquely by the runtime. They cannot be securely overwritten (zeroed) in place. When a Swift string falls out of scope, it remains in RAM until the reference count drops and the memory is eventually reclaimed. LockRoot converts UI input to a raw Data buffer as early as possible, which can be deterministically wiped using sodium_memzero.

6. What happens if an exception is thrown during Argon2id derivation on iOS?

LockRoot wraps the memory erasure instruction (sodium_memzero) inside a Swift defer {} block. This guarantees that even if the derivation fails or throws an exception, the memory buffer containing the master password is wiped synchronously before the function unwinds.

7. How does LockRoot protect against screen capture on Android?

The application sets WindowManager.LayoutParams.FLAG_SECURE on the main activity window. This instructs the Android SurfaceFlinger compositor to exclude the app’s buffers from screenshot APIs and replaces the app’s snapshot with a blank screen in the recent-apps task switcher.

8. Does LockRoot support biometric unlock (FaceID/TouchID)?

No. Biometric unlock typically requires storing the derived AES key (or the master password) inside the OS Keychain or Secure Enclave, wrapped by a biometric prompt. This expands the trust boundary to include the OS biometric daemon. LockRoot enforces strict zero-trust: the key exists only in volatile RAM while unlocked and is wiped on lock.

9. How are cross-platform payload differences handled in the V2 JSON envelope?

The encrypted V2 envelope is byte-for-byte identical across all platforms. However, the decrypted JSON payload differs slightly (e.g., C# desktop payloads utilize createdAt timestamps, while mobile payloads use schemaVersion). The platform parsers are designed to handle both schema variations gracefully during import to ensure cross-platform compatibility.

10. Why did LockRoot migrate away from XChaCha20-Poly1305?

XChaCha20-Poly1305 was originally chosen for mobile (via libsodium) due to its performance on older ARM chips lacking AES acceleration. However, the desktop implementations (.NET) only supported AesGcm natively. To unify the ecosystem and avoid bloating the desktop apps with C-bindings, LockRoot migrated universally to AES-256-GCM, as all modern mobile hardware now includes AES-NI hardware acceleration.

11. How does the V1 to V2 cryptographic migration work?

It is a transparent, one-way opportunistic migration. The mobile apps bundle a legacy reader. Upon successful decryption of an XChaCha20 vault, the app automatically generates a new AES-GCM nonce, re-encrypts the payload in memory with the active key, and overwrites the legacy file with the V2 JSON envelope.

12. How does LockRoot mitigate Denial of Service (DoS) via crafted vault files?

Because KDF parameters are stored in plaintext in the JSON envelope, an attacker could craft a file demanding 8 GiB of memory for Argon2id. LockRoot parsers strictly enforce parameter bounds (e.g., max 256 MiB memory, max 10 iterations) before passing the values to the cryptographic pipeline, halting the unlock flow and preventing an Out-Of-Memory (OOM) crash.

13. How does LockRoot clear the clipboard on iOS?

It initiates a Swift Concurrency Task that sleeps for 20 seconds. Before clearing the clipboard, it checks UIPasteboard.general.changeCount. It only evicts the clipboard if the counter hasn’t changed, ensuring it doesn’t accidentally delete a URL the user manually copied during that 20-second window.

14. What cryptographic libraries does LockRoot use?

LockRoot relies on well-maintained, production-ready libraries: BouncyCastle (Android Argon2id), JCE (Android AES/GCM), CryptoKit (iOS/macOS AES/GCM), Argon2Swift (iOS/macOS), and the native .NET AesGcm (Windows/Linux). No custom cryptographic primitives were written.

15. How does LockRoot utilize iOS Data Protection?

When saving the vault file to disk on iOS, LockRoot sets the .completeFileProtection attribute. This delegates a layer of hardware encryption to the Secure Enclave, tying the file’s readability to the device passcode and preventing offline extraction of the vault file from a powered-off, locked device.

16. Why is there no “Forgot Password” or recovery key mechanism?

Implementing a recovery mechanism inherently requires either key escrow (storing a backup key on a server) or asymmetric cryptography (encrypting the vault with a secondary public key). Both approaches compromise the strict local-only, zero-knowledge threat model. In LockRoot, the master password is the only mathematical path to decryption.

17. How does LockRoot manage background states on iOS?

The iOS app binds to the SwiftUI scenePhase environment value. When the phase shifts to .inactive (e.g., the user opens the app switcher), a synchronous lock command fires, zeroing the AES key and scrubbing the decrypted UI state before the OS takes a snapshot of the app.

18. Does LockRoot protect against compromised or rooted operating systems?

No. Once the vault is unlocked, the AES key and plaintext entries reside in the application’s memory space. A privileged process (root/malware) with memory read access (e.g., ptrace) can extract these secrets. LockRoot’s threat model assumes a secure host OS.

19. How are export files secured?

Exports are encrypted using the identical AES-256-GCM / Argon2id V2 envelope format. However, they use a distinct Lockroot_EXPORT magic string, a randomly generated fresh salt, and require the user to set a separate export password. Knowing the vault password provides no mathematical advantage in decrypting an export file.

20. Does LockRoot perform password hashing for authentication?

No. LockRoot never stores the master password, neither in plaintext nor hashed. Authentication is implicit: the master password derives the AES key, and if the AEAD tag validates during decryption, the password is correct. If the AEAD tag fails, the password was incorrect.