[noise] Test vector format

[Trevor Perrin]

On Fri, Apr 8, 2016 at 10:51 PM, Alex <alex at centromere.net> wrote:
> On Fri, 8 Apr 2016 19:25:06 -0700
> Trevor Perrin <trevp at trevp.net> wrote:
>
>>  - What are the semantics for "name", does it have to be unique?
>
> If a handshake fails it would be nice to be able to identify it in
> debugging messages. So, while uniqueness isn't required, it certainly
> would be helpful.

Cool, makes sense.


>>  - "fail" will usually be "false", so it's mostly redundant and just
>> takes up space.  I didn't mind "payload": null or some other special
>> value to indicate failure.  Alternatively the "payload" line could be
>> replaced by the "fail": true line, for error cases?
>>
>
> My approach for verifying the vectors is to replay both sides of the
> conversation while collecting the (payload, ciphertext) pairs at each
> step. After the entire conversation is over -- i.e. all payloads in the
> "messages" array have been converted to ciphertext -- the "messages"
> array from the file and the results from the replayed conversation are
> tested for equality. Due to this, I am not keen on a "payload: null"
> line to indicate failure, because the message sender needs a payload to
> generate a ciphertext (encryption never fails, only decryption does).
> This also applies to omitting the "payload" key entirely.


Not sure I follow.  I think there's two cases for processing a
"payload"/"ciphertext" test element:

Assuming the test framework manages two HandshakeStates, A and B, for
a non-error case you can test:

 - "payload -> A.writeMessage() -> "ciphertext"
 - "ciphertext" -> B.readMessage() -> "payload"

For the error case you only test:

 - "ciphertext" -> B -> ERROR

So I don't see why you'd need the "payload" in the error case?

Trevor