<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
        {margin-top:0;
        margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>I think something else that would make the spec <span>easier</span> to understand is to state explicitly the randomization of symmetric crypto depends on a using a random ephemeral asymmetric key for setup. This is implied in many places but the exact relationship
 between the symmetric encryption randomization and the ephemeral key is not explicitly called out early in the spec.</p>
<p><br>
</p>
<p>In my, probably naive, reading this concept and the state chaining are the two core ideas in the crypto for noise.</p>
<p><br>
</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Arial,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p></p>
<p style="font-family:"Times New Roman""><b><span style="font-family:Helvetica,sans-serif; font-size:12pt">Jonathan Moore, CTO</span></b></p>
<span style="font-family:Helvetica,sans-serif"></span><span style="font-size:11pt"></span><span style="font-family:Arial,Helvetica,sans-serif"></span><span style="font-size:11pt"></span><span style="font-family:Helvetica,sans-serif"></span>
<p style="font-family:"Times New Roman""><span style="font-family:Helvetica,sans-serif; font-size:11pt">SpiderOak</span></p>
<span style="font-family:Helvetica,sans-serif"></span><span style="font-size:11pt"></span><span style="font-family:Arial,Helvetica,sans-serif"></span><span style="font-size:11pt"></span><span style="font-family:Helvetica,sans-serif"></span>
<p style="font-family:"Times New Roman""><span style="font-family:Helvetica,sans-serif; font-size:11pt">415.425.5495</span></p>
<span style="font-family:Helvetica,sans-serif"></span><span style="font-size:11pt"></span><span style="font-family:Arial,Helvetica,sans-serif"></span><span style="font-size:11pt"></span><span style="font-family:Helvetica,sans-serif"></span>
<p style="font-family:"Times New Roman""><span style="color:rgb(0,111,201); font-family:Helvetica,sans-serif; font-size:11pt">>ENCRYPT EVERYTHING</span></p>
<span style="font-family:Helvetica,sans-serif"></span><br>
<p></p>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Trevor Perrin <trevp@trevp.net><br>
<b>Sent:</b> Wednesday, June 7, 2017 5:08:10 PM<br>
<b>To:</b> Jonathan Moore<br>
<b>Cc:</b> noise@moderncrypto.org<br>
<b>Subject:</b> [EXT] Re: [EXT] Re: [noise] Multi party psk</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On Wed, Jun 7, 2017 at 11:51 PM, Jonathan Moore<br>
<jmoore@spideroak-inc.com> wrote:<br>
> After thinking longer about it, and re-reading the psk section of the spec,<br>
> I realized I don't understand the intended usage of psk(s). My thought was<br>
> "It is a way to skip the key agreement and go right to the session" but<br>
> given that it still uses an ephemeral key (instead of a nonce) to generate a<br>
> unique ck, I don't know why I would use it over Noise_{K,X}.<br>
<br>
Yeah, we should say more about PSK rationale.<br>
<br>
PSKs are intended to provide "additive" security to a handshake, so<br>
they get used in combination with DH.  WireGuard is using them mainly<br>
for post-quantum properties:  A quantum computer might break your EC,<br>
but if you have a PSK it probably can't break that.<br>
<br>
Another use could be when resuming a session, where a PSK derived from<br>
an earlier session protects the zero-RTT data which is exchanged<br>
before the public-key handshake completes.  Or, the new handshake<br>
might just do an unauthenticated Noise_NN to get forward-secrecy for<br>
the new session, but rely on the PSK to extend the earlier session's<br>
authentication.<br>
<br>
But you're right that you don't need it in many / most cases.<br>
<br>
<br>
> My use case is that I have a multi party chat, Semaphor, that uses a shared<br>
> symmetric channel key. Right now we use a home grown protocol build on top<br>
> of libsodium but I am hoping that we can switch to noise. I would actually<br>
> like to switch to shared public channel key ( all parties know the private<br>
> key ) but I am concerned with decryption time when back filling history.<br>
> (Under the assumption that some phones can only handle ~1k DH operations/s)<br>
<br>
Sounds like a lot going on here!  So I couldn't say from that<br>
description whether Noise is a good fit.<br>
<br>
<br>
Trevor<br>
</div>
</span></font>
</body>
</html>