On Fri, Feb 24, 2017 at 04:40:19PM +1100, Martin Thomson wrote: > On 24 February 2017 at 16:01, Sean Turner <s...@sn3rd.com> 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.
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. > On 24 February 2017 at 16:09, Felix Günther <guent...@cs.tu-darmstadt.de> > wrote: > > just to clarify: you add an additional HKDF.Expand step, not > > HKDF.Extract, right? > > Yes, you are right, I should have said expand. You need to use expand > to get the label-based separation on type. > > I don't know how I got confused about that. If we need to maintain > extract and expand in pairs (as we have already been burned by), then > I will defer to cryptographers on that. The creator of HKDF stated that HKDF should always be used with paired extracts and expands and any derpartion from that should be done with utmost care. Both the existing design and this design fail this: Because exporter secrets are of expanded type, you would need to extract them, and derive-secret is expansion type operation. Note that passing label as salt is definitely very bad idea, since you will get trivial collisions due to how HKDF works internally. And doing so even with hash might be a bad idea. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
