stateless crypto

[dominictarr]

This change removes the state.js module and replaces it with stateless.js. The objective here is to have all crypto generated by pure functions, this makes it easy to have a set of test vectors, which makes it easy to port.

There are a few crypto functions which apply to both the client and server. (initialize, createChallenge, clean, and verifyChallenge) the rest are divided into client and server. All functions that with "create" in the name return a buffer, but do not change state. All functions with "verify" take the state and a buffer (which was the output of the remote's previous create function) and mutate the state object and return it. mutating the state makes it not a "pure" pure function, but we don't want to have all our secrets just floating around, so this means we might have a chance to zero them, which reduces exposure to say, unsafe memory access.

It's getting late here, but the next step is to generate a set of test vectors. They are really simple, just an array of [methodname, [args...], returnValue] This would be most portable in JSON format, with base64 or hex encoded buffers, I figure this should be easy on most languages?

Then, an implementer just needs to implement the functions, and iterate over the test vector and make sure every output matches. The logic of the handshake is pretty straightforward after that.

@cryptix @keks @david415 @Kodest

[cryptix]

welcome this a lot!

ps: just a small typo here:

and return a mutate the state object and return it.

I guess and return a mutated version of the state object?

[dominictarr]

@cryptix thanks

[dominictarr]

okay, the protocol logic and the crypto are now clearly separated. next I'm gonna generate test vectors by wrapping the crypto functions in loggers, write that to a json file, and then read that back as test vectors.

[dominictarr]

still a little bit of tidying up due before this is mergeable, but I got test vectors https://github.com/auditdrivencrypto/test-secret-handshake

that matches the reference implementation (though, only on packet type differs) not the spec

[dominictarr]

@david415 ^ test vectors are available

[1082008]

glad to see those test vectors, they will be very useful for my planned C++ implementation. (I think json format is approachable.)

[david415]

looks good. it still needs test vectors in a json file.

[dominictarr]

I think I might change from base64 to hex - hex is what you'd see if you use tools like hexdump, and if you really need to, it is easier to implement hex than base64, also it's less ambigious whether a normal string is hex or not, where as most printable ascii strings are base64

[david415]

ok yeah hex is fine

[dominictarr]

merged into 1.1.3, test vectors available at https://github.com/auditdrivencrypto/test-secret-handshake

would implementers like to move their implementations into a single org? this is probably easier for users, and I feel gives the impression that yes, a few sets of eyes have gone over the protocol & implementations.