[noise] Test vector format

[Trevor Perrin]

Thanks for driving this forward!  Comments:

 - Hex is easier than Base64 for debugging, e.g. it can be useful to
count bytes and recognize that part of the ciphertext is what you
expect, but part is different.

 - Probably also use hex for prologue and psk?

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

 - It would be possible to use Noise with non-elliptic-curve DH, so
better to call this "dh" or something, rather than "curve".

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.

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.

For example, what if every test block had the exact same sequence of
fields prior to the "messages", one per line, with no sub-structures
(unused psk or DH fields could have a special value "EMPTY"):

"vectors": [
{
"name": "arbitrary identifier",
"pattern": "NN",
"dh": "25519",
"cipher": "AESGCM",
"hash": "SHA256",
"init_prologue": "foo",
"init_psk": "bar",
"init_static": "<hex formatted private key data>",
"init_semiephemeral": "<hex formatted private key data>",
"init_ephemeral": "<hex formatted private key data>",
"init_remote_static": "<hex formatted public key data>",
"init_remote_semiephemeral": "<hex formatted public key data>"
"resp_prologue": "foo",
"resp_psk": "bar",
"resp_static": "<hex formatted private key data>",
"resp_semiephemeral": "<hex formatted private key data>",
"resp_ephemeral": "<hex formatted private key data>",
"resp_remote_static": "<hex formatted public key data>",
"resp_remote_semiephemeral": "<hex formatted public key data>"
},
"messages": [
{
"payload": "<hex formatted payload>",
"ciphertext": "<hex formatted ciphertext>"
},
{
"payload": "<hex formatted payload>",
"ciphertext": "<hex formatted ciphertext>"
},
{
"payload": "<hex formatted payload>",
"ciphertext": "<hex formatted ciphertext>"
}
]
}


Trevor


On Wed, Apr 6, 2016 at 6:44 PM, Alex <alex at centromere.net> wrote:
> On Wed, 6 Apr 2016 21:26:41 -0400
> Jonathan Rudenberg <jonathan at titanous.com> wrote:
>
>> What do you think about using Base64 instead of hex for the binary
>> parts?
>>
>
> I'm OK with that.
>
>> I’m unsure about specifying the pattern/cipher/hash/curve separately
>> for both sides of the handshake, it seems like that’s only useful for
>> failure mode testing and would be better suited in local unit tests
>> for the implementation.
>>
>
> I think it would be useful to be able to simulate a MITM in which
> one party has a different remote static key than the one that is
> presented.
>
> --
> Alex
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise