[prev in list] [next in list] [prev in thread] [next in thread]
List: moderncrypto-noise
Subject: Re: [noise] Some questions from a new user
From: Rhys Weatherley <rhys.weatherley () gmail ! com>
Date: 2017-06-30 1:48:55
Message-ID: CADmumMpJyjCHiNePFzBDROVs3RqQiW8_W_SMDyQj0kbp2foMPg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Jun 29, 2017 at 9:51 AM, Paul F Fraser <paulf@a2zliving.com> wrote:
> Hi,
>
> I have been following this mail list for some time and am now ready to
> attempt to incorporate Noise into my network code.
>
> Brief explanation of my network-
>
> - 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.)
> - Users communicate with their node using mobile browser.
>
> From my limited understanding of Noise at this time my approach might be
> to use between nodes -
>
> - the Noise_KK pattern as public keys are already known.
> - use h, the handshake hash as PSK to remove the need for a
> handshake on resumption of a connection.
>
>
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.
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.
>
> A problem I am facing is the communication between a users mobile and
> their node.
>
> - 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.
> - X509 certificates tied to Ip Addresses seem to be a problem.
>
> There has been quite a bit of discussion on this list about Noise and TLS.
>
> My question in this case-
>
> - 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?
> - preferably using Noise.
>
>
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.
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.
Comments appreciated.
>
> Finally, thanks to all the contributors to this technology, especially in
> my case, to Rhys for the Noise-Java code.
>
> -being fellow Australians, I can call him by his first name :-)
>
Thanks.
Cheers,
Rhys.
[Attachment #5 (text/html)]
<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>
[Attachment #6 (text/plain)]
_______________________________________________
Noise mailing list
Noise@moderncrypto.org
https://moderncrypto.org/mailman/listinfo/noise
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic