scrypt

What memory-hard means

Most password-cracking attacks scale by parallelising compute — running many guesses simultaneously on GPUs, FPGAs, or custom ASICs. Memory-hard functions resist this by requiring a large amount of memory per evaluation — meaning each parallel guess needs its own memory allocation, dramatically increasing the cost of mounting a credential-brute-force attack.

Why scrypt over alternatives

PBKDF2 (the older standard) is not memory-hard, making it vulnerable to GPU-accelerated cracking. Argon2 (the modern Password Hashing Competition winner) has stronger security but less deployment mileage and weaker library support in some platforms. scrypt sits in the middle: memory-hard, well-vetted, supported everywhere, and standardised by IETF (RFC 7914). For SkyeConnex's threat model — where the wrapped UMK might be observed but should not be brute-forceable — scrypt is the conservative choice.

SkyeConnex's scrypt parameters

SkyeConnex tunes scrypt parameters to take roughly 100-300 ms per evaluation on a modern client device — slow enough to make a credential-stuffing attacker need significant capital to mount even a small attack, fast enough to not affect the user-visible authentication latency materially. The exact parameters (N, r, p) are tuned per deployment.

Where this matters in the threat model

The wrapped User Master Key is stored on the SkyeConnex server. If a database were compromised — or if SkyeConnex itself were compelled to surrender wrapped UMKs — the attacker would face the same problem the user does: deriving the UMK requires the password, and scrypt's memory-hardness makes brute-forcing the password expensive even with substantial resources.

The recovery key option

Users who don't want to depend on a remembered password can rely on the 24-character recovery key, which is generated with full entropy and wraps the UMK independently of the password. scrypt is irrelevant in that path; the recovery key is directly used as a wrapping key.