perf(storage): cut V19 PIN KDF to 70k iterations (30% faster unlock) - #371
Open
BitHighlander wants to merge 1 commit into
Open
perf(storage): cut V19 PIN KDF to 70k iterations (30% faster unlock)#371BitHighlander wants to merge 1 commit into
BitHighlander wants to merge 1 commit into
Conversation
V19 restored a 100,000-iteration PBKDF2 work factor after V16 had reduced it to ten. Two passes at that count is the multi-second unlock wait users are hitting on 7.15.0-rc27. Drop to 70,000 (chunk 700, so the progress loop still ticks 100 times) for a 30% cut in unlock wall-clock. The offline work factor this buys is bounded by the PIN search space -- alphabet 1-9, and most users pick four digits -- so the last 30k iterations are paid on every single unlock to move a GPU attack by minutes. V19 has not shipped in any tag. These constants are part of the persistent storage format, so this has to be settled before release: changing it after costs a V20 and a migration for every wallet. V15 and V16 constants are untouched, as old wallets must unwrap with their original parameters.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
PIN_ITER_COUNT_v19100000 → 70000,PIN_ITER_CHUNK_v191000 → 700.Why
V19 (e109404) restored a 100,000-iteration PBKDF2 work factor after V16 had cut it to ten. Two passes at that count is the multi-second unlock wait now visible on 7.15.0-rc27 hardware.
The offline work factor this buys is bounded by the PIN search space, not by the iteration count. The alphabet is 1–9 and most users pick four digits — 6,561 candidates. Those last 30,000 iterations are paid on every unlock, forever, to move a GPU attack by minutes.
Correctness
layoutProgresslands on 1000.unittests/firmware/storage.cppexercises the KDF as a round-trip (derive → unwrap → rewrap), not against fixed key vectors, so no goldens are pinned to the iteration count.Timing
V19 has not shipped in any tag. These constants are part of the persistent storage format, so the number has to be settled before release — changing it afterward costs a V20 and a migration for every wallet.
Not verified here
The 30% is proportional, not measured: PBKDF2 is linear in iterations, but no stopwatch reading was taken off rc27 hardware. Worth timing the progress bar on a build of this branch before merge. Reviewers who know the rationale behind the V19 hardening — if it came from an audit finding that named a specific work factor, that constrains this number and I'd want to hear it.