feat(aztec-nr): Initial handshake registry contract with non interactive handshake function

[vezenovm]

Fixes https://linear.app/aztec-labs/issue/F-586/handshake-registry-non-interactive-handshake-function

Flow:

• non_interactive_handshake(recipient) retrieves sender_for_tags from PXE via get_sender_for_tags()
• Sender stores registry note: HandshakeNote { secret_hash, handshake_type, recipient }
• Recipient-discoverable log emission, log contains 1-field [eph_pk.x]
• Invalid recipient fails
  • No upstream side effects to protect
  • Fallback would pollute state with notes recording handshakes to invalid non-curve points
• New utility get_handshake_for(sender_for_tags, recipient, handshake_type) -> Option<HandshakeNote>
• Various tests that cover the cases listed above

[nventuro]

The note is nullifiable, i.e. its nullifier is defined (and even computed during discovery). It's just that the registry never does nullify it.

[nventuro]

Given how we'll use this registry, perhaps it'd make more sense to write a helper function such as

fn get_constr_deli_shared_secret(context: &mut PrivateContext, recipient: AztecAddress) -> Field {
   ... // do utility call to registry.get_note_hint(recipient)
   context.assert_note_exists(note_hint, registry_address);
   assert_eq(recipient, note.recipient); // also handshake type
   let key_val_req = key_validation_request_oracle(note.secret_hash);
   context.push_key_validation_req(key_val_req);
  key_val_req.app_siloed_key
}

and then test the invocation of that. The registry won't really be called the way we're doing it in this test (which is why the msg.sender issues are not surfaced).

[vezenovm]

I tested the utility function but didn't go forward with the rest of the key validation checking because we still need the oracle to store the raw secret.

[nchamo]

Amazing work!

Left some comments and questions, but really like how it's turning up

[nchamo]

I'm curious about the next step. I understand that the sender will always be able to call this to get the note, and then check that handshake actually happened

But what about the recipient? What will they do when gets the secret in the private log? Not saying we need to tackle it now, just asking out loud

[vezenovm]

The recipient should be able to recover the master secret S using eph_pk.x (the scalar that was generated with the recipient_point). I was under the impression that after this handshake, the sender would then call an app and generate a tagging shared secret with tagging_shared_secret = hash(S, contract_address, CONSTR_TAG_DOMAIN_SEP). The recipient can then use S to find the tagging_shared_secret to ultimately recover the tag. Is this correct @nventuro?

[nchamo]

I also discussed this with him. So we need to figure out how, but the recipient will discover the log, get the secret and store it somewhere, so that they know to search for messages with that tag afterwards

[nchamo]

Answering some comments

[nchamo]

I also discussed this with him. So we need to figure out how, but the recipient will discover the log, get the secret and store it somewhere, so that they know to search for messages with that tag afterwards

[nchamo]

LGTM!

[AztecBot]

❌ Failed to cherry-pick to v4-next due to conflicts. (🤖) View backport run.