ByteGuard Security Architecture: Argon2id, AES-256-GCM, Passkeys, and FIDO2/WebAuthn
A developer walkthrough of ByteGuard Argon2id key derivation, AES-256-GCM field-level encryption, and FIDO2/WebAuthn passkey implementation — with full pipeline diagrams and competitor comparison.
Published: 2026-04-09 · 12 min read
🔐 The Complete Encryption Pipeline
Most password managers publish a "how we encrypt your data" page. Most tell you almost nothing useful — vague claims about "military-grade encryption" with no verifiable details.
This article is the opposite. Every parameter, every design decision, verified against ByteGuard's actual source code.
Every password manager ultimately reduces to a single question: what happens between the moment you type your Master Password and the moment your data is stored as ciphertext? ByteGuard's answer is a five-stage pipeline, each stage providing a distinct security guarantee.
The full key derivation and encryption pipeline, from user secrets to ciphertext
The input to key derivation is a concatenation of your Master Password and a 128-bit Secret Key stored in the device Keychain, protected by Keychain access control (biometryCurrentSet — requires current biometric enrollment to access). Neither secret alone is sufficient. An attacker who phishes your password still lacks the Secret Key; an attacker who steals your device still needs the password.
🛡️ Argon2id: Memory-Hard Key Derivation
Argon2id — winner of the 2015 Password Hashing Competition — is the first transformation. ByteGuard uses libsodium's implementation with these parameters:
Memory: 67,108,864 bytes (64 MB) · Iterations (opsLimit): 3 · Salt: 16 bytes · Output: 32 bytes (256-bit Master Key)
Why does memory hardness matter? The answer is GPU economics. A modern GPU has thousands of fast ALUs but limited per-core memory. Each Argon2id guess requires 64 MB of dedicated RAM that cannot be shared across threads.
64 MB per guess — a machine with 64 GB RAM maxes out at roughly 1,000 parallel attempts
Negligible memory per guess — the same machine can run millions of parallel computations
The cost to brute-force at scale becomes prohibitive with Argon2id.
Custom ASIC chips face the same constraint. ASICs accelerate computation by stripping away general-purpose circuitry, but Argon2id demands massive on-chip memory per operation. Memory is physically expensive on silicon — you can't miniaturize around it.
🔀 HKDF-SHA256: Cryptographic Key Separation
The 256-bit Master Key from Argon2id is never used directly for encryption. Instead, it feeds into HKDF-SHA256 (HMAC-based Key Derivation Function) to derive purpose-specific keys:
Wraps other key material. Used to protect keys at rest.
Authenticates requests. Never touches encryption operations.
Separate key per data type: type-login-v1, type-card-v1, type-note-v1, type-identity-v1.
Why not use the Master Key directly? Cryptographic separation. If a vulnerability were ever found that leaked one derived key, the other keys remain unaffected. Login credentials are encrypted with a different key than credit card data. A compromise of one domain cannot cascade into another.
HKDF derives two keys from the Master Key: a Key Encryption Key (KEK, info='KEK-v1') and an Auth Key (info='AUTH-v1'). The KEK protects a randomly generated Data Encryption Key (DEK). Per-type encryption keys are then derived from the DEK via HKDF (info='type-{dataType}-v1'). This two-layer design means changing your Master Password only requires re-encrypting the DEK — not every field in your vault.
🔒 AES-256-GCM: Authenticated Field-Level Encryption
Each sensitive field is encrypted independently using AES-256-GCM with the corresponding per-type key. The encryption parameters:
Key: 32 bytes (256-bit) · Nonce: 12 bytes (96-bit), randomly generated per encryption · Mode: Galois/Counter Mode (authenticated encryption)
The random 96-bit nonce means the same plaintext produces different ciphertext each time it is encrypted. There is no deterministic relationship between input and output. GCM's authentication tag provides tamper detection — if even a single bit of the ciphertext is modified, decryption fails entirely.
Field-level means each sensitive field (password, card number, note content) gets its own nonce and authentication tag. This is more granular than encrypting an entire vault as a single blob.
▶ Deep Dive: Argon2id vs bcrypt vs scrypt
bcrypt was a breakthrough when introduced in 1999, but it uses a fixed 4 KB memory footprint. This makes it GPU-friendly — modern GPUs can run tens of thousands of parallel bcrypt computations because 4 KB is trivial per-core. bcrypt also caps password input at 72 bytes, which limits entropy from long passphrases.
scrypt introduced memory-hardness in 2009, requiring configurable amounts of RAM per hash. However, scrypt uses a single-pass memory access pattern that is vulnerable to certain time-memory tradeoff (TMTO) attacks. It also lacks a hybrid mode — its memory access pattern is either data-dependent (faster but side-channel vulnerable) or data-independent (side-channel resistant but less GPU-hard).
Argon2id is a hybrid that combines the best of both Argon2 variants. The first half of each pass uses Argon2i (data-independent addressing), which resists side-channel attacks. The second half uses Argon2d (data-dependent addressing), which maximizes resistance to GPU and ASIC attacks. This hybrid design is why Argon2id won the Password Hashing Competition and is recommended by OWASP.
At ByteGuard's settings (64 MB, 3 iterations), each hash invocation takes roughly 0.5–1 second on a modern iPhone. That's imperceptible for a user unlocking their vault once — but devastating for an attacker who needs billions of guesses.
ByteGuard's pipeline turns your Master Password + Secret Key into per-type encryption keys through three deliberate stages: Argon2id defeats brute-force economics, HKDF-SHA256 provides cryptographic isolation between data types, and AES-256-GCM delivers authenticated field-level encryption with random nonces.
🔐 Passkey / FIDO2 / WebAuthn
Passwords have three inherent flaws that no amount of complexity requirements, rotation policies, or user education can eliminate:
A convincing replica page captures credentials. Even security professionals occasionally fall for sophisticated attacks.
One breached database feeds automated login attempts across thousands of other services. Password reuse makes this devastatingly effective.
"Password123!" meets most complexity rules. Predictable patterns make dictionary attacks trivially effective at scale.
Passkeys — built on the FIDO2/WebAuthn standard — eliminate all three by replacing shared secrets with public-key cryptography. Here is the exact flow.
🖌️ Passkey Registration
During registration, the private key never leaves the device's secure hardware
The device generates an asymmetric key pair. The private key is stored in the Secure Enclave (or platform equivalent) and never transmitted. Only the public key goes to the server. There is no shared secret to steal. On Apple platforms, passkey key pairs use ECDSA P-256 (ES256). The private key is generated inside the Secure Enclave and cannot be exported.
🔓 Passkey Authentication
Authentication uses a fresh challenge each time — no password is ever transmitted
Each authentication session starts with a fresh server challenge. Your device verifies your identity biometrically (Face ID, Touch ID), signs the challenge with the private key, and sends the signature back. The server verifies it using the stored public key. No secret is ever transmitted.
🎯 Origin Binding: Why Phishing Becomes Impossible
This is the critical differentiator. A passkey is cryptographically bound to the exact domain (origin) where it was created. If you register a passkey for bank.com, it will not activate on bank-secure.com, bank.com.attacker.net, or any other domain.
This is protocol-level enforcement, not a user decision. The browser checks the origin before allowing credential access. Even a pixel-perfect visual clone on the wrong domain gets nothing — the passkey simply does not exist from the attacker's perspective.
🔄 ByteGuard's Dual Support
Passkey adoption is growing but incomplete. ByteGuard is built for the transition period: use a Passkey for sites that support FIDO2/WebAuthn, generate and store traditional passwords for sites that don't, and manage TOTP/2FA codes alongside both. All three credential types are protected by the same zero-knowledge encryption pipeline.
▶ Deep Dive: WebAuthn Relying Party ID and origin enforcement
In the WebAuthn specification, the Relying Party ID (RP ID) is the effective domain of the website requesting authentication. When you create a passkey on login.example.com, the RP ID is typically example.com.
During authentication, the browser performs an origin check before any credential access occurs. The browser compares the requesting page's origin against the RP ID stored with each credential. If the origins don't match, the credential is not offered to the user and the authentication ceremony fails silently — the attacker doesn't even learn that a credential exists.
This enforcement happens at the browser/OS level, not in JavaScript. A malicious page cannot override or bypass the origin check. This is fundamentally different from password auto-fill, where a convincing-looking URL might trick a user (or even some auto-fill heuristics) into providing credentials to the wrong domain.
The result: a perfect visual clone of a login page, hosted on a different domain, receives zero passkey credentials. Phishing is not merely difficult — it is cryptographically impossible for passkey-protected accounts.
Passkeys replace shared secrets with public-key cryptography, eliminating phishing through cryptographic origin binding. ByteGuard supports Passkeys, traditional passwords, and TOTP codes within a single encrypted vault — covering both FIDO2-capable and legacy sites.
🛠️ Security Design Decisions
Architecture is a series of tradeoffs. Here are the deliberate choices ByteGuard makes — and the reasoning behind each one.
🚫 No "Forgot Password" by Design
ByteGuard has no password reset flow, no recovery email, no security questions. This is intentional. Any mechanism that allows account recovery without the original credentials is, by definition, a mechanism that allows someone other than you to access your data.
Any recovery mechanism that bypasses the original credentials creates an alternate path to your data — one that attackers can potentially trigger.
- Reset via email = alternate credential path
- Server must store recovery data
- Social engineering attack surface
- No reset flow = no alternate path
- No recovery data on server
- No social engineering vector
📱 Secret Key Bound to Device
The 128-bit Secret Key is stored in the device Keychain, protected by Keychain access control (biometryCurrentSet — requires current biometric enrollment to access). It never leaves the device over the network. Even if your Master Password is compromised through phishing or shoulder-surfing, the attacker cannot derive the encryption keys without physical access to an authenticated device.
The Secret Key's mnemonic phrase is the ONLY recovery path. If you lose both your Master Password and your mnemonic phrase, your data is cryptographically unrecoverable. This is the price of true zero-knowledge: no one — not ByteGuard, not Apple, not any government — can bypass the encryption.
☁️ Local-First + Optional iCloud Sync
ByteGuard stores your vault locally by default. When iCloud sync is enabled, only ciphertext leaves the device. The Master Key never touches the network. The Secret Key never leaves the Keychain.
This means Apple (as the iCloud storage provider) only ever sees encrypted blobs. A breach of iCloud storage would yield ciphertext that is computationally infeasible to decrypt without the user's Master Password and device-bound Secret Key.
🔨 Field-Level Encryption Tradeoffs
Encrypting each field independently rather than the entire vault as a single blob is a deliberate architectural decision with concrete tradeoffs:
- Granular access: display metadata without decrypting sensitive fields
- Efficient sync: only changed fields transfer over iCloud, not the entire vault
- Reduced memory exposure: decrypting one password doesn't load all passwords into memory
- More encryption operations: each field requires its own encrypt/decrypt cycle
- Storage overhead: each field carries its own 12-byte nonce and 16-byte authentication tag
On modern hardware (A15 chip and later), AES-256-GCM operations complete in microseconds thanks to hardware acceleration. The storage overhead is measured in bytes per field. ByteGuard's judgment: the security benefits of field-level isolation decisively outweigh the negligible performance and storage costs.
ByteGuard deliberately sacrifices password recovery convenience for zero-knowledge guarantees, binds the Secret Key to device hardware, transmits only ciphertext during sync, and encrypts at field granularity. Each decision increases the cost of attack while keeping the user experience fast on modern hardware.
📊 How ByteGuard Compares
Security architecture varies significantly across password managers. The following comparison is based on each product's publicly available security documentation and whitepapers.
| Aspect | ByteGuard | 1Password | Bitwarden | Apple Keychain |
|---|---|---|---|---|
| Key Derivation | Argon2id (64 MB) | Argon2id (varies) | PBKDF2 / Argon2id | PBKDF2 |
| Encryption Granularity | Field-level | Item-level | Item-level | Item-level |
| Second Factor | Secret Key (device) | Secret Key (Emergency Kit) | None (optional 2FA) | Apple ID + device |
| Data Storage | Local-first, optional iCloud | Cloud-primary | Cloud-primary | iCloud Keychain |
| Recovery | Mnemonic phrase only | Emergency Kit | Email/2FA recovery | Apple ID recovery |
| Open Source | Planned | No | Yes (client) | No |
Each approach has genuine merits. 1Password pioneered the Secret Key concept and has an excellent security track record. Bitwarden's open-source client enables independent security audits. Apple Keychain offers seamless device integration with minimal user friction. This comparison is based on publicly available security documentation — choose based on your threat model, not marketing claims.
Key differentiators worth noting: Bitwarden historically defaulted to PBKDF2 with 600,000 iterations but has been adding Argon2id support. 1Password uses Argon2id with parameters that vary by client platform. Apple Keychain relies on PBKDF2 but compensates with hardware-backed key storage and device trust chains. No single approach is universally "best" — the right choice depends on whether you prioritize open auditability, ecosystem integration, local control, or a specific threat model.
ByteGuard differentiates through field-level encryption, local-first storage, and Argon2id key derivation with a device-bound Secret Key. Competitors offer their own strengths — open-source transparency, cloud convenience, or ecosystem integration. Evaluate based on your specific security requirements.
🚀 Try ByteGuard
ByteGuard is available as a free download on the App Store. Zero-knowledge encryption, field-level security, Passkey support, and a local-first architecture — built for developers and security professionals who want to understand exactly how their data is protected.
Download ByteGuard on the App Store →