[noise] Notes from Noise meetup and working day

[Trevor Perrin]

Hi all, some notes from last few days:


Real World Crypto
------------------
Nadim gave an excellent talk on Noise Explorer (video doesn't seem to
be online yet).

We had a Noise lunch meetup with ~20 people.  We discussed
developments over the past year, some highlights:

 * Three projects formally analyzing Noise, including the Noise
Explorer work using ProVerif, upcoming work from Karthik's team using
CryptoVerif, and upcoming work from Paul Rosler and Ben Dowling
performing manual proofs and analysis.

 * Successful deployment of Noise into I2P, discussed by str4d.

 * WireGuard continues to become more popular and multiplatform.

 * There's an nQUIC prototype for Noise with QUIC.

 * Nadim is extending Noise Explorer into a framework for
code-generation (producing code for different handshakes in different
languages).

 * There's in-progress work on spec extensions in 3 areas:
   (a) new patterns for signatures, KEMs, PAKE, and combinations
   (b) symmetric-crypto overhaul centered around "stateful hashing"
   (c) NLS framework for negotiation and framing

For the upcoming year I'm hoping to finalize (a)-(c) so that Noise
covers essentially all 2-party AKE permutations using simple
public-key crypto (a), has simpler and more efficient options for
hashing/encryption (b), and has a good framework for negotiation along
with profiles for easy, off-the-shelf use (c).


Noise Working Day
------------------
About 10 of us met on Saturday for a "working day".  The main topics were:
 (1) Extending pattern naming and notation for signatures, KEMs, and
"multi-algorithm" combinations, discussion led by Justin Cormack
 (2) Integrating PAKE, led by Brian Warner
 (3) Noise/QUIC, led by David Wong
 (4) NLS framework, led by Gerardo Giacomo
 (5) Stateful hashing, led by Trevor and Mike Hamburg

Some highlights from each discussion:


(1) Pattern naming

 * We generally liked the token+number approach taken by "hfs" and
"sig" drafts (i.e. tokens like "s1", "sig1"; or "e2", "ekem2" where
the number suffix refers to the index of the public-key algorithm in
the pattern name, 0 being implicit and omitted).

 * Naming multi-algorithm patterns is challenging, we considered ways
to sidestep it by making the pattern name a hash or encoding of the
pattern itself, but having somewhat-comprehensible names helps us
communicate and think about patterns.

 * We explored Justin's pattern composition idea, considering how his
pattern-derivation rules from 18.3 of the spec could be extended to
"merge" multiple patterns.  A promising idea was to consider each
composed pattern as introducing a single public-key algorithm, Justin
and Jason Donenfeld were going to explore this further.


(2) PAKE

 * We discussed the "EKE"-style PAKEs (like SPAKE2 or PAK) which
provide a symmetric/balanced PAKE by "masking" the ephemeral public
key with a password-derived value.  This style of PAKE is efficient
and would probably be fairly easy to introduce into Noise notation.

 * We also discused "augmented" PAKEs like SPAKE2+ or OPAQUE where the
value the server stores is not "password-equivalent".  The OPAQUE
design is modular consisting of an OPAQUE round-trip overlapped with
some conventional AKE protocol (like a Noise handshake).  We discussed
what sort of Noise handshake would be combined with OPAQUE and thought
it might require something new, but on further thought I believe XX
would work, transporting the OPAQUE data in the Noise handshake
payloads.

 * PAKE overlaps with our interest in an indistinguishable-from-random
encoding of ephemeral public keys, in a couple ways:
   - They both involve "masking" the ephemeral in some way, so might
use similar notation, and we might have to consider how to perform
both simultaneously
   - They both are likely to use a hash-to-curve map like Elligator2.
  Thus, we should probably co-design these mechanisms.


(3) Noise/QUIC

 * This was a brief discussion, but QUIC has a lot of nice features as
a transport protocol.  It's still being designed, but we hope it will
end up a modular design allowing easy plugging of new crypto
handshakes (like Noise).  There was also some interest in seeing the
nQUIC design generalized to support different Noise handshakes, and
perhaps include NoiseLingo negotiation (the negotation language used
in NLS).


(4) NLS

 * We discussed the choice of encoding language.  There were some
questions about the decision to use protobufs, as it's not the
simplest format to write a parser for or inspect, and doesn't encode
deterministically.  We should discuss alternatives further.

 * Gerardo, Jason, and I reviewed the NLS rev2 draft (on wiki) and had
some ideas for simplifying:
   - Eliminate the NoiseTinyLink profile, and fold the aliases it
defines into NoiseLink.  At that point NoiseLink is capable of sending
small messages, so the NoiseTinyLink profile probably isn't
worthwhile.
   - Remove the "rejected-retry" mechanism, so we only have the safer
switch/retry mechanisms for negotiation.
   - Change TransportOptions so it describes the entire set of options
used by both parties.  The parties will "intersect" each
TransportOption to determine the final set.  This probably needs a bit
more thought.

 * I'll try to create a draft for these changes, and more discussion.


(5) Stateful hashing

 * I discussed the "SHO" API.  Mike is working on a simplified STROBE
API in the context of lightweight hashing.  There's a fair amount of
convergence in these APIs, which raises the question of how far we
could converge them.  A few differences:

 - Mike's API would allow absorb-squeeze-absorb-squeeze etc, whereas
the SHO API can only squeeze once.  The SHO design thus avoids having
to encode type of operation, and is sufficient for Noise, where we
need a main SHO object absorbing keys and transcript, but will not
squeeze directly from it.  Instead we will always clone it into a new
SHO object, absorb some domain-separation values into the clone, and
squeeze from the clone, when we need to extract keys.

 - Mike's API would preserve the idea of hashing the input as a
sequence of messages, whereas SHO just hashes a single byte stream.
Mike prefers the idea of indicating protocol semantics by breaking up
a byte-stream into separate messages, though it's not entirely clear
where/why we would draw these boundaries, for Noise.  We'll try to
come up with a proposal so we can make a more concrete comparison.


Trevor