[noise] markdown + (blobs, boxes, lengths, extension data)

[Trevor Perrin]

I started moving to a Markdown spec, though still very rough:

https://github.com/trevp/noise/blob/master/noise.md

I'm trying to fit in a slew of changes, based on discussions.

Consider these tentative (i.e. if you implement you may have to back
out), but let's discuss:


Blobs
-----
https://moderncrypto.org/mail-archive/noise/2014/000069.html

On the wiki, a Noise Box is an encrypted/unpadded public key plus an
encrypted/padded contents.

We could treat these 2 encryptions consistently if they both used
padding, so I added a "blob" notion - a noise box is now just 2 blobs
(there might be a better name).


Typed Boxes
-----------
https://moderncrypto.org/mail-archive/noise/2014/000064.html

I added StandaloneBox / ClientBox / ServerBox structures, to make it
clearer what role the different keys play, and to handle the absent
ephemeral key in the ClientBox better.


Lengths
-------
On the Wiki, length fields were not part of the core protocol, and
were added in a "TCP profile".

The rationale was that sometimes boxes or pipes might be embedded in
another protocol with its own length fields.

But it's probably simpler just to add them, since they're useful
sometimes and pretty harmless if redundant.  And if the redundancy is
a problem, an encompassing profile could "compress" things by making
the Noise length fields implicit.

CC/CV derivation order
-------
KDF now derives the CC before the CV, since the CC is used first, this
seems to make more sense?

Extension Data
-------------
We talked about versioning.  I think the goals for a
versioning/extension system should be:
 (a) Do as little as possible in core
 (b) Provide extensibility so people can add whatever versioning /
negotiation they want
 (c) Provide extensibility by default, so you can start using
"vanilla" Noise boxes/pipes without thinking about this, and then add
versioning when the need arises

The proposal in spec is to add an arbitrary-length "extension data"
prior to each handshake message (Start, ServerBox, ClientBox).

The extension data are included in authenticated data, and libraries
should provide callbacks to read/write them, but there's no mandated
interpretation.

Example use:
 - After deploying Noise255 pipes, you decide you want clients to
offer Noise255 and Noise448 ephemeral keys, and servers to pick.  So
you add some version number and a Noise448 key into the
start_ext_data.  Old servers ignore it!  New servers peek at it, and
can return an extension data indicating acceptance of 448, and switch
to 448.

Since this mechanism is so generic, anyone wanting to do this has to
design all the details themselves.  But there's so many ways to do
versioning/negotiation that seems best.

Anyways, my hope is this is flexible enough to support anything you'd
want to do, do people disagree?

Trevor