[noise] Test vector format

[Alex]

On Wed, 6 Apr 2016 22:38:53 -0700
Trevor Perrin <trevp at trevp.net> wrote:

>  - Error testing might be better handled by specifying which
> particular ciphertext should trigger an error.  For example, have a
> "payload": "ERROR" special value, instead of "should_fail".  The test
> framework will expect decrypting the corresponding ciphertext to fail.
> 

I tend to dislike special values. What about a '"fail": true' key?

>  - I think I agree with Jonathan that pattern / cipher / hash /
> curve-type can be specified once, outside the party-specific blocks.
> 

The handshakes and keys can be defined outside of the vector array
entirely. I've attached an updated schema. What do you think?

> About JSON:  I worry about JSON files with large numbers of tests,
> since I think streaming APIs for JSON are less common than
> document-based APIs.  Also, I worry about someone developing for
> embedded systems, or smartcards, or IoT or something, who doesn't have
> JSON tools lying around.
> 

Given the ubiquity of JSON tools, I don't suspect it would be difficult
to convert the vectors in to a format more suitable for embedded work.

> Would it be reasonable to make the format JSON-compatible but more
> restrictive, to make it easier to consume for dumb streaming parsers,
> but still allow consumers to use JSON?  This would make it harder for
> producing, but I think the tests will be consumed more than produced.
> Also, these restrictions could make the tests more human-readable.
> 

JSON "pretty-printing" would definitely make the tests more human
readable, although I realize that's not what you've proposed below.

Would it be reasonable to commit full JSON documents to the repository
as "master" copies, but also include a small script which can
auto-generate new documents in the format you're after?

-- 
Alex
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vector_schema.txt
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160406/b9b3dce0/attachment.txt>