Confirmed users
471
edits
Identity/CryptoIdeas/01-PBKDF-scrypt: Difference between revisions
→Updates / Discussion
| Line 372: | Line 372: | ||
during the init phase: once that setup has been performed, all subsequent | during the init phase: once that setup has been performed, all subsequent | ||
messages could safely be sent in the clear. | messages could safely be sent in the clear. | ||
== Implementation-Driven Changes == | |||
NSS, the cryptographic library used in Firefox, is enthusiastic about keeping key material behind a notional barrier (retaining the ability to implement primitives on a smart card or HSM). So its KDF functions don't want to reveal the derived keys, since they're "keys" and not "data". To overcome this (and make it easier to take advantage of NSS, instead of reimplementing many primitives), the protocol needs to sneakily derive values from the "keys". | |||
I'm still working through what changes are necessary to support this, but at first glance, we'll need to define an EXTRACT function that encrypts a block of zeros (equal in length to the key size), using the derived key as the encryption key, and use the resulting "ciphertext" as the output of the KDF step. For example, instead of A=PBKDF(args), we'd use A0=PBKDF(args) and A=AES(key=A0).encrypt(plaintext=000). That lets us get "A" outside the NSS barrier and either deliver it to the scrypt-server or into the next KDF step (probably passing it back *into* the barrier). | |||
We'll need this EXTRACT step after the first round of PBKDF (on "A"), after the scrypt step on "B", and after the second round of PBKDF (on "C", giving us the option of storing "C" in the password manager). If HKDF is provided by NSS too, we'll have to do it again on each of the outputs of the HKDF step (PWK, MAC, and S1/SRPpw). | |||
== Updates / Discussion == | == Updates / Discussion == | ||