[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