[noise] Aligning with Chrome and IETF's ChaCha20/Poly1305

[Trevor Perrin]

I changed a few things to align with ChaCha20/Poly1305 as in Google
Chrome and IETF drafts (sorry Stephen and Jonathan!, but these should
be easy changes):

Background: Google's Chrome browser has deployed ChaCha20/Poly1305 and
the IETF is working on a standard for it [1,2].  Because other IETF
protocols and things like GCM use 96-bit nonces instead of the 64-bit
that DJB spec'd, and that were implemented in Chrome, the latest IETF
draft changes things slightly (reallocating one 32-bit word from the
counter to the nonce, i.e. from 64-bit counter and nonce to 32-bit
counter and 96-bit nonce).  But as long as we encrypt <2^32 blocks =
256 GB this is the same as setting the first 32 bits of a 96-bit nonce
to zero, so I don't think this change affects us except perhaps
setting a size limit on boxes.

But a few other alignments seemed worthwhile:
 * The IETF drafts encode len(authtext) and len(plaintext) in
little-endian, which makes sense as ChaCha20, Poly1305, and Curve25519
are encoded in little-endian.  The Noise draft was ambiguous, but
Noise had used big-endian elsewhere (GCM and pad_len).  Anyways, I
changed lengths to little-endian, including pad_len, but excepting GCM
(which should probably stay following the NIST standard).

 * For ChaCha20/Poly1305, if len(authtext) or len(plaintext) is a
multiple of 16, add 0 bytes of padding (instead of 16).

 * Encrypt the plaintext starting at count=1 instead of count=2, by
taking the "rekey" bytes from the end of the keystream instead of the
beginning.

Trevor

[1] http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04
[2]: https://datatracker.ietf.org/doc/draft-nir-cfrg-chacha20-poly1305/?include_text=1