Repository navigation
Conversation
…for ECDH Every GuardedKey read runs 4096..8191 mix rounds by design (~45-75 µs), and the generic nip59 unwrap read the vault once per layer, each time also deriving a keypair it never used. Local accounts now unwrap with a single read and use the bare SecretKey for NIP-04/44, keeping nip59's checks in the same order. Inbound unwrap, median of 8 interleaved launches: 373 µs -> 297 µs (-20%). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K9tM3F7VFTMcoTN1cmoiuo
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
Author
|
Closing: Generated by Claude Code |
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
2 participants
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.
Requested by JSKitty · project thread
Before: unwrapping one received gift wrap on a local account read the
GuardedKeyvault twice, once per NIP-44 layer, and derived a full keypair each time just to do ECDH. A vault read is deliberately expensive (4096 to 8191 mix rounds, about 45 to 75 µs depending on the launch), so vault work was roughly 45% of every unwrap.After: local accounts unwrap with one vault read for both layers, and every
GuardedSignerNIP-04/44 op uses the bareSecretKeywithout deriving a keypair. nip59's checks still run, in the same order: kind, outer verify, seal verify, and rumor author matching the seal.Numbers
cargo test --release -p vector-core --test bench_unwrap -- --ignored --nocapture, master and this branch run alternately for 8 launches each (4 vCPU Linux):UnwrappedGift::from_gift_wrap(GuardedSigner)GuardedSigner::unwrap_gift_wrapEvery NIP-04/44 op through
GuardedSigner(seal encrypt on send, NIP-04 paths) also gets ~24 µs cheaper (to_keys()+decryptvsGuardedSigner nip44_decryptrows, same binary).How
GuardedKey::to_secret_key(): vault read with no keypair derive.to_keys()now wraps it.GuardedSigner::unwrap_gift_wrap: mirrorsnip59::UnwrappedGift::from_gift_wrap_with_ctx, but takes the secret once after the outer verify and drops it straight after the second decrypt.prepare_eventuses it forActiveSigner::Local. Bunker, NIP-55 and rawKeyskeep the generic path.cargo test -p vector-core: 1726 passed.Trade-off to review: the secret now lives for one ~180 µs window covering both decrypts plus the seal parse and verify, instead of two ~60 µs windows. It's still a stack
SecretKey, zeroized on drop by the patched fork.🤖 Generated with Claude Code
https://claude.ai/code/session_01K9tM3F7VFTMcoTN1cmoiuo
Generated by Claude Code