[noise] Multi-algorithm handshakes (a sketch)

[Trevor Perrin]

On Mon, Aug 13, 2018 at 9:37 PM, Justin Cormack
<justin at specialbusservice.com> wrote:
> I think it might help to break this up a little into more digestible
> pieces, and maybe the notations can
> be made cleaner.
>
> signature and KEM are relatively clear as standalone modifiers. I do
> wonder about the large number of
> different types of signature and formats that are common (inc non
> fixed length ones), so there are some
> practicalities to consider there. I think splitting these out makes
> sense, separately from doubled versions.

Yeah, that's probably a good dividing line - we could have one
document for signatures and KEMs, and a separate one for doubled
patterns.

But it's worth designing them simultaneously, to make sure everything
fits together.


> I am not sure we technically need the "1" modifiers on the s, kem, and
> sig tokens, as you can work out
> which they correspond to, but maybe there are some other clearer
> notation options.

Not sure exactly what you mean, maybe you could spell out alternatives?

>
> For doubled cases, I think I would rather if the deferred patterns
> were called out explicitly rather than being
> implicit.

I thought about that but couldn't come up with a good naming
convention - if we have "sig1id" mean "double the initiator's
authentication with a signature using algorithm 1", then we've already
glommed a lot of characters together, so it seemed like a lucky break
that we could let deferring that operation be implicit, instead of
something awful like "sig1idd".


> I wonder if it might make sense to define rules for
> combining two patterns.

That could be an interesting alternative to the doubling, for sure.
But I'm not sure how it would work, or how much useful flexibility it
could add beyond doubling.


Trevor