[noise] New test vectors

[Trevor Perrin]

On Tue, May 17, 2016 at 2:38 AM, Alex <alex at centromere.net> wrote:
>
> Are the features described in the "Advanced uses" section considered
> mandatory, optional, or something else?
>
> Are they normative?

Hmm, we don't have precise concepts or terminology about that.  We'll
need to think about it.

>From a protocol perspective, if you're implementing, say,
Noise_XX_25519_AESGCM_SHA256, then nothing beyond that is "normative",
and you can ignore everything in the spec about PSKs, other patterns,
other crypto, etc.

So I guess the question is really: how do we label and talk about libraries?


> I've always considered Noise Pipes to be non-normative, which is why
> I left "XXfallback" out of the pattern specification:
>
> "pattern": "NN|KN|NK|KK|NX|KX|XN|IN|XK|IK|XX|IX|XR|N|K|X",
>
> It's not clear to me whether the test vector format should support
> non-normative optional extensions.

It makes sense to differentiate some of these advanced uses from the core.

But it also makes sense to be able to test "advanced uses" with the
test vectors format.

Maybe the test vectors format should allow optional fields, but if you
don't recognize those fields, you skip the test?

We might also need to more clearly "name" some of these features, so
we can create matrixes saying which implementations and test suites
support which features.  For example:

  null public keys optimization
  pipes
  indistinguishable pipes
  handshake hash
  secondary symmetric key

We might also separate out advanced features which require library
code changes (null public keys optimization, handshake hash, ssk),
from those like pipes which just require new patterns?

Hopefully we won't add much more to that list.  But as we consider
zero-RTT / resumption cases more deeply, we'll probably at least end
up defining some additional patterns.

Trevor