<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 29, 2017 at 9:51 AM, Paul F Fraser <span dir="ltr"><<a href="mailto:paulf@a2zliving.com" target="_blank">paulf@a2zliving.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div bgcolor="#FFFFFF">
<p>Hi,</p>
<p>I have been following this mail list for some time and am now
ready to attempt to incorporate Noise into my network code.</p>
<p>Brief explanation of my network-</p>
<ul>
<li>Every node on the network has status data about every other
node on the network including the public key. ( like blockchain,
but not blockchain hashes etc.) <br>
</li>
<li>Users communicate with their node using mobile browser. <br>
</li>
</ul>
<p>From my limited understanding of Noise at this time my approach
might be to use between nodes -</p>
<ul>
<li> the Noise_KK pattern as public keys are already known.<br>
</li>
<li>use h, the handshake hash as PSK to remove the need for a
handshake on resumption of a connection.</li></ul></div></blockquote><div><br></div><div>The handshake hash is a public value, known to eavesdroppers, so it isn't a very good PSK. We're still working on the exact mechanism for generating a PSK from one session to resume the next. There will still need to be a handshake upon resumption (to get fresh ephemerals), but it could use a shorter pattern.</div><div><br></div><div>Frankly, Noise sessions are so cheap to set up that resumption isn't needed in many cases. TLS sessions are very slow to setup. Noise, not so much.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div bgcolor="#FFFFFF"><ul>
</ul>
<p>A problem I am facing is the communication between a users mobile
and their node.</p>
<ul>
<li>SSL would be the obvious choice for this but would require an
X509 certificate (lets encrypt) tied to an Ip Address rather
than domain name.</li>
<li>X509 certificates tied to Ip Addresses seem to be a problem.</li>
</ul>
<p>There has been quite a bit of discussion on this list about Noise
and TLS.</p>
<p>My question in this case-</p>
<ul>
<li>is there any way currently available to use other than an X509
certificate to secure the link between a mobile browser and in
my case a jetty server?</li>
<li>preferably using Noise.</li></ul></div></blockquote><div><br></div><div>To secure a connection between two end-points, Noise only requires static public keys (32 bytes in the case of DH=25519, 56 bytes in the case of DH=448). Any kind of signing, certificate issuing, or proof of key ownership, is currently out of bounds for Noise. The application decides such policies. There is no standard certificate format yet. I proposed one a while ago using a protobuf-based format rather than the X.509 format. It's still a work in progress.</div><div><br></div><div>XX can be used by the parties upon the first connection to swap static public keys, with KK on follow-up connections. Alternatively, use Noise Pipes which describes a more complete system for first-time / next-time connections.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div bgcolor="#FFFFFF">
<p>Comments appreciated.<br>
</p>
<p>Finally, thanks to all the contributors to this technology,
especially in my case, to Rhys for the Noise-Java code. <br>
</p>
<p>-being fellow Australians, I can call him by his first name <span class="gmail-m_-7463922785699869209moz-smiley-s1"><span>:-)</span></span></p></div></blockquote><div><br></div><div>Thanks.</div><div> </div><div>Cheers,</div><div><br></div><div>Rhys.<br></div></div><br></div></div>