[noise] PQ crypto HFS

[Trevor Perrin]

Hey David,

Thanks for the info, let me tackle this question:

On Fri, Nov 16, 2018 at 11:34 PM dawuud <dawuud at riseup.net> wrote:
>
> As soon as possible I would like to see this HFS extension be officially part of the Noise specification.
> Perfect is the enemy of the good. What are we waiting for?

TLDR is I think you're right and we should move forward.

Let me explain the holdups, and why we can move past them:

(1) Post-quantum *authentication* with KEMs is more complicated than
"hybrid forward-secrecy", but would use the same mechanisms (new
modifiers; multiple algorithms in pattern names; new tokens for KEMs).
So we (or at least I) were reluctant to make decisions on "HFS" until
we had plans for handling the general "multi-algorithms in a
handshake" case.

At this point we have "deferred patterns" to help with post-quantum
auth, and I think we have fairly clear ideas for what KEM tokens and
multi-algorithm tokens would look like [1].

Modifier names for the general case is complicated (you could have a
Noise protocol with authentication using different types of
signatures, postquantum KEMs, DHs etc).

So it would be reasonable to choose a "hfs" modifier for now, since
that doesn't preclude a more general naming-scheme in future, but
avoids having to make those decisions now.


(2) Many post-quantum KEMs use some hashing function.  For example
NewHope uses SHAKE in various ways.  Since Noise also uses a hashing
function, it might be nice for Noise to provide a "hashing API" to
algorithms like NewHope, so they could use whatever hash algorithm
Noise was defined on, instead of having to hardcode some hash as an
internal detail.

I'm hoping the recent "Stateful Hash Object" discussion moves us
towards an API that would be suitable for that.

But we wouldn't require public-key algorithms to use such an API if
they preferred to hard-code their own symmetric crypto.  And that
would be the simplest option for now.  So if we just defined support
for HFS KEMs now, we could work out an optional hashing API for them
to use later.


Anyways, I'm not sure who else is interested, but I'll try to find
time to move the extension spec for this forward.

Trevor