[noise] Minor KDF concern
trevp at trevp.net
Sun Jul 6 14:23:43 PDT 2014
I'm replying to a private email of Stephen's, but we agreed to take
this back to the list so others can chime in:
On Sat, Jul 5, 2014 at 10:24 PM, Stephen Touset <stephen at squareup.com> wrote:
> I'd argue the tradeoff in simplicity is extremely minor. On the other hand,
> it's a good hedge against implementation mistakes and (past or future)
> design mistakes.
The added complexity is minor, but so is the value of the hedge. It
would only protect one specific design mistake: reusing the KDF on the
same input secret in two different contexts while failing to
differentiate the contexts through "info", expecting the output_len
will differentiate them.
If this was a general-purpose KDF, I might see more value in being so
conservative. But existing general-purpose KDFs *don't* hedge this,
that I'm aware (HKDF in RFC 5869, PBKDF1 and 2 in RFC 2898, or the 2
KDFs in NIST SP 800-56A).
And the Noise KDF is for a specific protocol where we of course won't
make this mistake.
> I empathize with but am wary of reasoning that involves the
> words "Currently that situation won't happen"; protocols change over time.
> Reasoning about properties in v1 doesn't necessarily hold for v2, but that
> fact is easy to overlook.
That's a good point in general, and one reason the KDF uses HMAC
despite length-extension being irrelevant in this specific case, i.e.
a simpler Hash(key || stuff) would probably suffice, but HMAC is
But having a simple/minimal protocol is nice too, the more features we
add the more drag there is to implementation and review, and the more
risk of weird, overlooked interactions, so there's a tension here we
just have to argue through in each case, I think.
> That said, I agree it's not much of a problem in its current state. It just
> seems relatively trivial to change at this point in the design, doesn't
> increase complexity by any meaningful amount, and is a reasonable
> future-proofing step.
To me, this is feeling more like a "Security Consideration" that we
note (in some yet-unwritten spec), but not really worth adding to the
protocol. I added some comments to the KDF to address this and
Jonathan's point, see if you think this is adequate for now.
More information about the Noise