Noise NK1 pattern identity hiding

Question

In the official documentation for the Noise Framework there is a section with an overview of the identity hiding for each pattern. The numbering of properties there, obviously, from weaker properties to strong ones, and the last property is:

9. An active attacker who pretends to be the initiator and records a single protocol run can then check candidates for the responder's public key.

The NK1 pattern has this property.

NK1 pattern itself
  <- s
  ...
  -> e
  <- e, ee, es
  ->

What does this property mean?

• What mean check candidates for the responder's public key?
• How can recording a single run of a protocol help this? (preferably with an example)
• Why is this property the latest in the list (i.e. supposedly the strongest)?

---

(here is not any tag related to Noise Framework, this is strange)

Answer 1

Let's break apart the property description:

An active attacker

So an attacker who can both read and create packets on the network

who pretends to be the initiator

In the NK1 handshake, the initiator is anonymous, so it's not really pretending to be the initiator, it is an anonymous initiator like any other NK1 initiator

and records a single protocol run

This just means they remember every message sent and received. You need to do this to analyze the packets later! I'll give the analysis you do below.

can then check candidates for the responder's public key.

You explicitly ask about this part in your question. The responder's public key, whose identity you're trying to hide, is never transmitted in this protocol, so you won't be able to ever see or directly decrypt it. In order to learn the responder's public key, you can only check if a guess you have for the public key is valid. You could enumerate the entire public key space, but it's so infeasibly large you'd never find it. But if you think the responder might use a specific public key (its identity), say because you know a certain service uses that public key, you could check if your guess is right. That's what this part of the identity hiding property is all about.

How would you do this? The crucial bit here is that 2 Diffie-Hellman operations are done here: ee and es. For ee, you are the initiator and the server transmits it's "e", so you can do this DH easily. For es, you supplied the "e", but want to make guesses about "s". The implicit (possibly empty) transport message after the "es" token has a MAC whose key is derived from ee and es; so if you can guess the responder's public key "s", and you use it and it successfully validates the MAC sent, then you know your guess was right.

Finally, this property is last in the list because it was added last; deferred handshakes (like NK1) were added later. It's not the strongest identity hiding level, 8 is.