<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On 14 Nov 2017 12:02, "David Wong" <<a href="mailto:davidwong.crypto@gmail.com" target="_blank">davidwong.crypto@gmail.com</a>> wrote:<br type="attribution"><blockquote class="m_-52759443360991292quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-52759443360991292quoted-text">>> One thing that we will need to be able to use NoiseSocket is static key<br>
>> signatures. Now we transmit them as a simple JSON object (see<br>
>> <a href="https://github.com/go-noisesocket/noisesocket/tree/master/virgil" rel="noreferrer" target="_blank">https://github.com/go-noisesoc<wbr>ket/noisesocket/tree/master/<wbr>virgil</a> ) just to<br>
>> make it work, but a more generalized spec is something we'll be working on<br>
>> in a near future.<br>
><br>
> Cool, David Wong was interested in that too.<br>
<br>
</div>For my Noise-plug-and-play implementation this is what I'm currently<br>
doing. I'm trying to find the simplest way to tackle authentication.<br>
I'd be happy to discuss about these:<br>
<br>
* I have convenience functions that you can use to generate a "root"<br>
(ed25519) key which can sign "noise" public keys (the 32-byte pubkey<br>
of X25519 for example)<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I am interested in a simple signing method too. Was wondering about using a one way protocol message as a signature perhaps. But anything standard and simple would be great. I really don't want any Json or anything.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-52759443360991292quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    - you can save/load a "root" keypair on disk as two hexadecimal<br>
files with 0400 permissions for the private key and 0644 for the<br>
public key.<br>
    - I'm thinking about changing hex to b64 (shorter)<br>
    - I'm thinking of requiring a passphrase to save/load the private key file<br>
* The same convenience functions exist for generating and loading<br>
"noise" (X25519) keypairs.<br>
* I have convenience functions to sign (resp. verify) a static public<br>
key via a "root" private key (resp. public key)<br>
* If a peer needs to authenticate itself during a handshake, it will<br>
send the signature as the encrypted payload of its last message<br>
pattern (the one that sends the static key).<br>
* I do not use any format (like JSON) anywhere. I'm just assuming that<br>
the concatenation of all payloads sent during the handshake is the<br>
signature in bytes.<br>
* If users want to have something more complicated (a chain of<br>
signatures or even X.509 certificates) then they can create their own<br>
"create_proof" and "verify_proof" functions and pass them to the<br>
configuration of both peers and it should work (I haven't tested that<br>
yet)<br>
<br>
I can see how formatting might be useful, but I'm currently not using<br>
the handshake's payloads for anything else than sending a proof so it<br>
is not needed in my case.<br>
<br>
Cheers,<br>
David<br>
<div class="m_-52759443360991292elided-text">______________________________<wbr>_________________<br>
Noise mailing list<br>
<a href="mailto:Noise@moderncrypto.org" target="_blank">Noise@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer" target="_blank">https://moderncrypto.org/mailm<wbr>an/listinfo/noise</a><br>
</div></blockquote></div><br></div></div></div>