[noise] Noise @ Highload++ in Moscow

[David Wong]

>> One thing that we will need to be able to use NoiseSocket is static key
>> signatures. Now we transmit them as a simple JSON object (see
>> https://github.com/go-noisesocket/noisesocket/tree/master/virgil ) just to
>> make it work, but a more generalized spec is something we'll be working on
>> in a near future.
>
> Cool, David Wong was interested in that too.

For my Noise-plug-and-play implementation this is what I'm currently
doing. I'm trying to find the simplest way to tackle authentication.
I'd be happy to discuss about these:

* I have convenience functions that you can use to generate a "root"
(ed25519) key which can sign "noise" public keys (the 32-byte pubkey
of X25519 for example)
    - you can save/load a "root" keypair on disk as two hexadecimal
files with 0400 permissions for the private key and 0644 for the
public key.
    - I'm thinking about changing hex to b64 (shorter)
    - I'm thinking of requiring a passphrase to save/load the private key file
* The same convenience functions exist for generating and loading
"noise" (X25519) keypairs.
* I have convenience functions to sign (resp. verify) a static public
key via a "root" private key (resp. public key)
* If a peer needs to authenticate itself during a handshake, it will
send the signature as the encrypted payload of its last message
pattern (the one that sends the static key).
* I do not use any format (like JSON) anywhere. I'm just assuming that
the concatenation of all payloads sent during the handshake is the
signature in bytes.
* If users want to have something more complicated (a chain of
signatures or even X.509 certificates) then they can create their own
"create_proof" and "verify_proof" functions and pass them to the
configuration of both peers and it should work (I haven't tested that
yet)

I can see how formatting might be useful, but I'm currently not using
the handshake's payloads for anything else than sending a proof so it
is not needed in my case.

Cheers,
David