feat!: stop deriving signing key from privacy keys #24439
Open
nventuro wants to merge 8 commits into
Open
Conversation
Renames the account flag from --secret-key to --signing-key: the signing key is now the account's root and the privacy secret is derived from it, instead of deriving the signing key from the privacy secret. SSH accounts keep an independent random secret since their key is external. The wallet DB persists both keys. Also splits the ambiguous createOrRetrieveAccount into separate createAccount and retrieveAccount, and wires up the previously-unhandled ecdsasecp256k1 account type. BREAKING CHANGE: --secret-key is renamed to --signing-key and account addresses change.
The embedded stub providers routed schnorr_initializerless accounts to the ECDSA stub, disagreeing with stubClassIds which registers them under the schnorr stub class.
…unts Removes the deriveSigningKey(secret) fallback from the embedded wallet and TestWallet createSchnorr* methods so the signing key is always supplied explicitly, and threads it through the worker registerAccount RPC. Callers pass their fixture's signing key or a fresh random one. BREAKING CHANGE: createSchnorrAccount/createSchnorrInitializerlessAccount now require a signing key argument.
Removes the last usages of deriveSigningKey (which derived the account signing key from the privacy secret) and deletes the function, closing out #5837. The bot now treats its configured senderPrivateKey as the signing key and derives the privacy secret from it; the remaining test callers pass an explicit random signing key. BREAKING CHANGE: deriveSigningKey is removed; the bot's account address changes for a given senderPrivateKey.
cli-wallet switched to --signing-key, leaving createSecretKeyOption and parseSecretKey without any callers, so drop them. Also removes a now-redundant comment in the bot factory.
Adds migration notes for the signing-key decoupling, the aztec-wallet --secret-key -> --signing-key rename, and the bot senderPrivateKey change. Corrects the create-account guide and the wallet-extension tutorial (which taught the removed deriveSigningKey), and updates the type-checked examples to pass an explicit signing key.
nchamo
approved these changes
Jul 2, 2026
| @@ -13,7 +13,6 @@ | |||
| // createAztecNodeAdminClient, | |||
| // createAztecNodeClient, | |||
| // } from '@aztec/stdlib/interfaces/client'; | |||
| // import { deriveSigningKey } from '@aztec/stdlib/keys'; | |||
Contributor
There was a problem hiding this comment.
What are all these imports? Can we delete them?
| ); | ||
| let secretKey: Fr; | ||
| if (accountType === 'ecdsasecp256r1ssh') { | ||
| // SSH accounts sign with a key held in the agent, and so we cannot derive their privacy secret key from it. Insted |
Contributor
There was a problem hiding this comment.
Suggested change
| // SSH accounts sign with a key held in the agent, and so we cannot derive their privacy secret key from it. Insted | |
| // SSH accounts sign with a key held in the agent, and so we cannot derive their privacy secret key from it. Instead |
| .env('SECRET_KEY') | ||
| .argParser(argsParser ?? parseSecretKey) | ||
| new Option('-sk, --signing-key <string>', description) | ||
| .env('SIGNING_KEY') |
Contributor
There was a problem hiding this comment.
We should also update docker-compose.yaml, since it still used "SECRET_KEY"
| ```typescript | ||
| // From stdlib/src/keys/derivation.ts | ||
| export function deriveSigningKey(secretKey: Fr): GrumpkinScalar { | ||
| export function deriveMasterIncomingViewingSecretKey(secretKey: Fr): GrumpkinScalar { |
Contributor
There was a problem hiding this comment.
deriveMasterIncomingViewingSecretKey and deriveMasterNullifierHidingKey say we use GeneratorIndex.IVSK_M and GeneratorIndex.NHK_M, but they are actually DomainSeparator.IVSK_M / DomainSeparator.NHK_M
| if (!this.db) { | ||
| throw new Error('Cannot retrieve an account without a wallet database'); | ||
| } | ||
| const { type, signingKey, secretKey, salt } = await this.db.retrieveAccount(address); |
Contributor
There was a problem hiding this comment.
Please confirm, because maybe I got lost somewhere:
- The
wallet_dbfile now returnssigningKey = undefinedwhen it doesn'taddress:signingis absent this.buildAccountwill fail ifsigningKey = undefined- But previously saved accounts didn't have the ":signing"
Do we need a migration somehow? Or maybe just document it as part of the migration notes?
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.
Closes #5837
This PR makes it so we no longer derive signing keys from the master privacy key. If there's no user-supplied privacy key seed, we instead derive it from the signing key, which is a safe derivation: PXE never sees the signing key nor any value it is derived from.
This has a large knock-on effect on wallets, CLI, tutorials, etc., but there's ultimately no large decisions being made there, it is mostly mechanical changes. In some cases I reworked some internals of wallets to make this distinction clearer.