[noise] Signatures, and QUIC example

Trevor Perrin trevp at trevp.net
Wed Mar 25 01:29:57 PDT 2015


On Sat, Mar 21, 2015 at 2:27 PM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>> QUIC and maybe TLS 1.3 use pre-knowledge of an ephemeral key for
>> 0-RTT, but then the server can present a fresher ephemeral:
>>
>> HandshakeNE(s, rs, re):
>>  -> e, dhee, dhes
>>  <- e, dhee
[...]
>
> Looking back, I was oversimplifying QUIC and TextSecure by omitting
> the fact that the remote static key also signs the prekey.
[...]
>  I was hoping to keep Noise a DH-only
> framework, but perhaps it should be able to express this too.


I could imagine a "sig" token for Noise, which means "sender signs
hash of all previous messages in session".

This allows a broader range of protocols.  For example, Google's QUIC
[1] allows for a signed prekey and 0-RTT.  If the client doesn't have
a signed prekey, it spends the first round-trip fetching one:
 ->
 <- e, sig

Then it executes the 0-RTT handshake, with the server providing a
fresher ephemeral on response:
 -> e, dhee
 <- e, dhee


So by using the sig early on your own message you can get "signed
prekeys" without losing deniability, but by placing it later we can
get more traditional key-agreement protocols in the style of TLS,
SIGMA, etc., where the parties are signing values provided by each
other, e.g.
 -> e
 <- e, sig
 -> dhee


This is another thing that could be misused (easy to throw away
deniability, for example).  And it complicates the question of
public-key formats.  But it's a nice gain in expressiveness for a
small addition, and would let Noise cover most types of key agreement.

Trevor

[1] https://docs.google.com/a/trevp.net/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit


More information about the Noise mailing list