Hi Hugo,
On 25 February 2017 at 03:47, Hugo Krawczyk wrote:
> Martin,
>
> Which of these two derivation schemes are you proposing?
I mean the latter of your two, where you have effectively three layers
of HKDF-Expand from the master secret.
master secret -> exporter secret
exporter secret + e
On 24 February 2017 at 21:02, Ilari Liusvaara wrote:
> This technique seems to assume there is some fixed known set of exporter
> labels that are used. Since if you don't know the full set, you need to
> keep the master exporter secret around anyway.
This is correct. I assume here that many appl
On Fri, Feb 24, 2017 at 11:47:32AM -0500, Hugo Krawczyk wrote:
> Martin,
>
> Which of these two derivation schemes are you proposing?
> Are you assuming that all uses of the exporter_secret are known at the end
> of
> the handshake? If not, you still need to keep an exporter_secret beyond the
> ha
Martin,
Which of these two derivation schemes are you proposing?
Are you assuming that all uses of the exporter_secret are known at the end
of
the handshake? If not, you still need to keep an exporter_secret beyond the
handshake.
Master Secret
|
|
+-> Derive-Secret(., "expor
On Fri, Feb 24, 2017 at 04:40:19PM +1100, Martin Thomson wrote:
> On 24 February 2017 at 16:01, Sean Turner wrote:
> > So this isn’t entirely novel right I mean we did something similar wrt
> > other key schedules?
>
> I certainly hope it isn't novel. I'm just applying the same
> technique: kee
On 24 February 2017 at 16:01, Sean Turner wrote:
> So this isn’t entirely novel right I mean we did something similar wrt other
> key schedules?
I certainly hope it isn't novel. I'm just applying the same
technique: keep independent keys independent.
On 24 February 2017 at 16:09, Felix Günther
Hi Martin,
just to clarify: you add an additional HKDF.Expand step, not
HKDF.Extract, right?
You mentioned extract in the email and PR text, but in code it's a
second expand---which makes sense, as only expand allows to add context
(here: label).
Cheers,
Felix
On 23/02/2017 20:30 -0800, Martin
So this isn’t entirely novel right I mean we did something similar wrt other
key schedules?
spt
> On Feb 23, 2017, at 23:30, Martin Thomson wrote:
>
> https://github.com/tlswg/tls13-spec/pull/882 contains the longer description.
>
> In short, the existence of an exporter secret threatens the
https://github.com/tlswg/tls13-spec/pull/882 contains the longer description.
In short, the existence of an exporter secret threatens the forward
secrecy of any exported secret. This is a problem for QUIC and is
likely to be a more general problem.
The proposed fix is small: separate exporters i
