BOLT 8: Add test vectors.

[rustyrussell]

Needs @Roasbeef to check they work for him (at least, the success cases).

[sstone]

I believe that you've used secp256k1's ecdh function which returns sha256(serialized compressed point) instead of point.x ? With this change I can generate your results with our own implementation.

[rustyrussell]

Indeed! Lets defer this pending results of #43

[Roasbeef]

I think we should also specify what the starting h and ck values should be (for both sides before ActOne):

h = 0x8401b3fdcaaa710b5405400536a3d5fd7792fe8e7fe29cd8b687216fe323ecbd
ck = 2640f52eebcd9e882958951c794250eedb28002c05d7dc2ea0f195406042caf1

This'll help implementers to ensure they initialized the state properly.

[rustyrussell]

Good idea... and those numbers match mine.

[Roasbeef]

So everything lines up for me up until this point.

Instead I have:

sk=4438f22354d2620c3e7698c96bc880eee8101709baa6318e73ad799db173ca2d
rk=4453668c85a468a61fdfe661864fc543eaeac9ce0634dd827a5e2c0205c8edfb

[Roasbeef]

What are your full HKDF parameters for secret, salt, info?

[rustyrussell]

OK, here it is in the debugger.

Inputs to HKDF:
salt = 0x91, 0x92,
0x19, 0xdb, 0xb2, 0x92, 0xa, 0xfa, 0x8d, 0xb8, 0xf, 0x9a, 0x51, 0x78,
0x7a, 0x84, 0xb, 0xcf, 0x11, 0x1e, 0xd8, 0xd5, 0x88, 0xca, 0xf9, 0xab,
0x4b, 0xe7, 0x16, 0xe4, 0x2b, 0x1
saltlen: 32
IKM-len: 0
info-len: 0

Gives PRK: {0x54, 0xde,
0x99, 0x40, 0xe0, 0xbe, 0x34, 0x8d, 0x2, 0x4d, 0x40, 0xf6, 0xfd, 0x38,
0x5d, 0x64, 0x92, 0xf6, 0x1f, 0xb, 0x1d, 0xb5, 0x7, 0x64, 0xb4, 0xcb,
0x34, 0x11, 0x70, 0xcf, 0x9b, 0xcb}

T(0) = ""
T(1) = HMAC_SHA256(PRK || 0x01) = {0x96, 0x9a,
0xb3, 0x1b, 0x4d, 0x28, 0x8c, 0xed, 0xf6, 0x21, 0x88, 0x39, 0xb2,
0x7a, 0x3e, 0x21, 0x40, 0x82, 0x70, 0x47, 0xf2, 0xc0, 0xf0, 0x1b,
0xf5, 0xc0, 0x44, 0x35, 0xd4, 0x35, 0x11, 0xa9}
T(2) = HMAC_SHA256(PRK || T(1) || 0x2)
= {0xbb, 0x90,
0x20, 0xb8, 0x96, 0x5f, 0x4d, 0xf0, 0x47, 0xe0, 0x7f, 0x95, 0x5f,
0x3c, 0x4b, 0x88, 0x41, 0x89, 0x84, 0xaa, 0xdc, 0x5c, 0xdb, 0x35, 0x9,
0x6b, 0x9e, 0xa8, 0xfa, 0x5c, 0x34, 0x42}

[rustyrussell]

OK, if I fix the nonce endian to le, I get:

output: rk,sk=0x969ab31b4d288cedf6218839b27a3e2140827047f2c0f01bf5c04435d43511a9,0xbb9020b8965f4df047e07f955f3c4b88418984aadc5cdb35096b9ea8fa5c3442

If you concur @sstone , I'll regen the test vectors.

[sstone]

I get the same results, with the following intermediate values for act 3:

Initiator:

# Act Three
# encryptWithAD(0x908b166535c01a935cf1e130a5fe895ab4e6f3ef8855d87e9b7581c4ab663ddc, 0x000000000100000000000000, 0x90578e247e98674e661013da3c5c1ca6a8c8f48c90b485c0dfa1494e23d56d72, 0x034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa)
# c=0xb9e3a702e93e3a9948c2ed6e5fd7590a6e1c3a0344cfc9d5b57357049aa22355361aa02e55a8fc28fef5bd6d71ad0c3822
# h=0x5dcb5ea9b4ccc755e0e3456af3990641276e1d5dc9afd82f974d90a47c918660
# ss=0xb36b6d195982c5be874d6d542dc268234379e1ae4ff1709402135b7de5cf0766
# HKDF(0xe89d31033a1b6bf68c07d22e08ea4d7884646c4b60a9528598ccb4ee2c8f56ba,0xb36b6d195982c5be874d6d542dc268234379e1ae4ff1709402135b7de5cf0766)
# ck,temp_k3=0x919219dbb2920afa8db80f9a51787a840bcf111ed8d588caf9ab4be716e42b01,0x981a46c820fb7a241bc8184ba4bb1f01bcdfafb00dde80098cb8c38db9141520
# encryptWithAD(0x981a46c820fb7a241bc8184ba4bb1f01bcdfafb00dde80098cb8c38db9141520, 0x000000000000000000000000, 0x5dcb5ea9b4ccc755e0e3456af3990641276e1d5dc9afd82f974d90a47c918660, <empty>)
# t=0x8dc68b1c466263b47fdf31e560e139ba
output: 0xb9e3a702e93e3a9948c2ed6e5fd7590a6e1c3a0344cfc9d5b57357049aa22355361aa02e55a8fc28fef5bd6d71ad0c38228dc68b1c466263b47fdf31e560e139ba
# HKDF(0x919219dbb2920afa8db80f9a51787a840bcf111ed8d588caf9ab4be716e42b01,zero)
output: sk,rk=0x969ab31b4d288cedf6218839b27a3e2140827047f2c0f01bf5c04435d43511a9,0xbb9020b8965f4df047e07f955f3c4b88418984aadc5cdb35096b9ea8fa5c3442

Responder:

input: 0x00b9e3a702e93e3a9948c2ed6e5fd7590a6e1c3a0344cfc9d5b57357049aa22355361aa02e55a8fc28fef5bd6d71ad0c38228dc68b1c466263b47fdf31e560e139ba
# decryptWithAD(0x908b166535c01a935cf1e130a5fe895ab4e6f3ef8855d87e9b7581c4ab663ddc, 0x000000000100000000000000, 0x90578e247e98674e661013da3c5c1ca6a8c8f48c90b485c0dfa1494e23d56d72, 0xb9e3a702e93e3a9948c2ed6e5fd7590a6e1c3a0344cfc9d5b57357049aa22355361aa02e55a8fc28fef5bd6d71ad0c3822)
# rs=0x034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
# h=0x5dcb5ea9b4ccc755e0e3456af3990641276e1d5dc9afd82f974d90a47c918660
# ss=0xb36b6d195982c5be874d6d542dc268234379e1ae4ff1709402135b7de5cf0766
# HKDF(0xe89d31033a1b6bf68c07d22e08ea4d7884646c4b60a9528598ccb4ee2c8f56ba,0xb36b6d195982c5be874d6d542dc268234379e1ae4ff1709402135b7de5cf0766)
# ck,temp_k3=0x919219dbb2920afa8db80f9a51787a840bcf111ed8d588caf9ab4be716e42b01,0x981a46c820fb7a241bc8184ba4bb1f01bcdfafb00dde80098cb8c38db9141520
# decryptWithAD(0x981a46c820fb7a241bc8184ba4bb1f01bcdfafb00dde80098cb8c38db9141520, 0x000000000000000000000000, 0x5dcb5ea9b4ccc755e0e3456af3990641276e1d5dc9afd82f974d90a47c918660, 0x8dc68b1c466263b47fdf31e560e139ba)
# HKDF(0x919219dbb2920afa8db80f9a51787a840bcf111ed8d588caf9ab4be716e42b01,zero)
output: rk,sk=0x969ab31b4d288cedf6218839b27a3e2140827047f2c0f01bf5c04435d43511a9,0xbb9020b8965f4df047e07f955f3c4b88418984aadc5cdb35096b9ea8fa5c3442

[Roasbeef]

After fixing the HKDF related bug Rusty pointed out on IRC, my results now match up with y'alls.

@sstone are you including the 0x00 version byte before each handshake message?

[sstone]

No you're right I left it out sorry...

[rustyrussell]

@sstone Hmm, your nonce value was "0x000000000100000000000000" and mine was "0x010000000000000000000000". I assumed 96 bit LE, should I assume 64 bit with 0 pre-pad? @Roasbeef ?

[sstone]

That's what I understood from the Noise specs: 32 bits of zeros followed by little-endian encoding of n (the first 32 bits of zeros make it compatible with the old ChaCha20 implementations that use a 64 bit nonce).

[Roasbeef]

Ahh, I must've skimmed over the nonce bit in the vectors!

I implemented it the way way that @sstone did, so my nonce is 0x000000000100000000000000. As he said, a 96-bit nonce is used here in order to match AES-GCM and other IETF related AEAD specifications. The chacha rfc we're using atm allows the protocol itself to specify the nonce size, in this instance Noise chooses a 64-bit nonce rather than a 96-bit nonce.

[rustyrussell]

Yay, now we seem to match! If no objections, I'll squash some commits together and merge.