Key Rotation
Prerequisite reading
Introduction
It is possible for users to rotate their keys, which can be helpful if some of their keys are leaked. Key rotation allows users to continue using the same account without having to create a new one.
Because of this, notes are often associated with their nullifier key
(through a nullifier public key hash, often called npk_m_hash
) rather than any sort of 'owner' address.
It is still possible to nullify the notes with the old nullifier key even after the key rotation.
TokenNote
example
See the structure of the TokenNote
below:
#[aztec(note)]
struct TokenNote {
// The amount of tokens in the note
amount: U128,
// The nullifying public key hash is used with the nsk_app to ensure that the note can be privately spent.
npk_m_hash: Field,
// Randomness of the note to hide its contents
randomness: Field,
}
Source code: noir-projects/noir-contracts/contracts/token_contract/src/types/token_note.nr#L21-L31
In the TokenNote
type, you can see that the nullifer computation gets the nullifier secret key specific to the contract from the PXE, based on the stored npk_m_hash
, so a TokenNote
is not inherently or permanently linked to a specific Aztec account.
fn compute_nullifier(self, context: &mut PrivateContext, note_hash_for_nullify: Field) -> Field {
let secret = context.request_nsk_app(self.npk_m_hash);
poseidon2_hash_with_separator([
note_hash_for_nullify,
secret
],
GENERATOR_INDEX__NOTE_NULLIFIER as Field,
)
}
Source code: noir-projects/noir-contracts/contracts/token_contract/src/types/token_note.nr#L34-L44
Things to consider
- When using the
npk_m_hash
, used to represent ownership, whoever has the nullifier secret can nullify a note. - Consider how key rotation can affect account contracts, e.g. you can add additional security checks for who or how the key rotation is called
Resources
- End to end tests for key rotation can be found here