[noise] New test vectors

Trevor Perrin trevp at trevp.net
Fri May 20 00:57:14 PDT 2016


On Tue, May 17, 2016 at 12:52 PM, Alex <alex at centromere.net> wrote:
>
> What I like best about the current format is how well it generalizes to
> all handshake patterns. In the case of SSK generality is not broken --
> the "init_ssk" and "resp_ssk" keys can be safely ignored if they are not
> understood.

I'm probably misunderstanding:  but you can't skip the SSK and still
expect to calculate the correct transport messages, of course.


> On the other hand, Noise Pipes require a change in how the messages
> array is interpreted for the special case of "XXfallback" (a
> non-normative, optional, application-level feature), which why I am not
> in favor of it being included in the "core" format.
>
> Would it make sense to have a separate format for Noise Pipes?

We could probably generalize and formalize the idea behind Noise Pipes
a little more, and that might help us answer this.

Noise Pipes have a "full" handshake, "resumption" handshake, and a
"fallback" case.  They use the XX and IK patterns for "full" and
"resumption".  But instead of XX/IK, you could do similar compound
protocols with:
 - NX/NK (no client auth)
 - XX/XK (stronger client identity hiding with deferred client auth)
 - XX/IE (resumption based on semi-ephemeral)
 - XX/PSK_NN (resumption based on a PSK derived from original session (TBD))
 - XX/PSK_XX (resumption with PSK overlaid on a full handshake)
etc

So if the spec was clearer about naming these and describing a generic
fallback mechanism, perhaps it would be easier to figure out how to
test that mechanism.

Anyways, that's something to think about for the next few weeks, since
we should try to flesh out the various ways to do resumption patterns
and compound protocols in revision 30.

Trevor


More information about the Noise mailing list