[noise] Potential redesign?

[Kenton Varda]

Hi Trevor,

Thanks for generalizing things so that Cap'n Proto and others might be able
to make use of this.

I think this is a step in the right direction, but I'm not sure if I see
quite yet how Cap'n Proto would use this. In our case, with introductions,
we have a symmetric situation:
1) Alice sends messages to Bob and Carol introducing them to each other.
2) Upon receiving the introductions, Bob and Carol can immediately begin
sending messages to each other, without waiting for any round trips.

I'm not quite sure how to apply any of the handshakes you've specified in
this symmetric situation -- they all mention an "initiator" and a
"responder" which appear to be treated asymmetrically.

Would it make any sense to have a symmetric handshake like:

  (i = initial prekey)
  HandshakeEE(s, i, rs, ri)
    -> e, dhei, dhes, s, dhsi
    <- e, dhei, dhes, s, dhsi

Maybe the above can be simplified because both sides know each other's 's'
already...

  (i = initial prekey)
  HandshakeEE(s, i, rs, ri)
    -> e, dhei, dhes, dhsi
    <- e, dhei, dhes, dhsi

(I suspect some of those DH's can be collapsed or removed but I'm not sure.)

Or perhaps we should make the introducer explicit:

  (A/B/C = Alice/Bob/Carol)
  (sX = static key of X)
  (eXY = ephemeral public key of X used in session with Y)
  (n = random nonce generated by Alice)
  HandshakeABC
    A->B (preexisting session) sC, n, eCA
    A->C (preexisting session) sB, n, eBA
    B->C n, e, dhe(eCA), dhes, dhs(eCA)
    C->B n, e, dhe(eBA), dhes, dhs(eBA)

In other words, the session between Bob and Carol initially uses the
ephemeral public keys originally used with Alice, and then switches to new
ephemeral keys as soon as they are received.

Also, forgive my noobishness, but I'm not quite sure I understand from the
document how the PRF chain interacts with streams moving in both
directions. Is there just one PRF chain for both streams, with some sort of
ordering defined between messages in opposite directions, or is there a
separate PRF chain for each direction? In the latter case (which is highly
preferable), how does the responder's ephemeral key get integrated into the
sender's outgoing PRF chain, and how does the responder know when this has
happened? For instance, in HandshakeXE, I assume that the initiator's
messages should eventually be encrypted in a way that integrates the
responder's ephemeral key, but clearly this cannot start happening until
one round trip has completed. It's unclear to me how the initiator signals
to the responder that it has completed the handshake and integrated the
responder's ephemeral key.

I also have a more abstract and opinionated question: In Cap'n Proto's
case, the "static" keys are per-process. A process generates a new key when
it starts up and that key never leaves its address space. Moreover, we
encourage process lifetimes to be limited to a day or less (and in
Sandstorm we will actually have forced restarts). In this scenario, in your
opinion (or anyone else here), how important is it really to generate a new
ephemeral key pair for every connection? I realize that forward secrecy
depends on it, but usually when we're talking about forward secrecy we're
thinking of static keys that are stored long-term on disk, with many orders
of magnitude higher risk of leakage. If an attacker can dump a specific
process's RAM it seems like it's already game over, so maybe ephemeral keys
are not accomplishing very much in that case? (Or maybe it's fair to
consider the per-process keys "ephemeral" even though they are used for
multiple connections?)

Thoughts?

-Kenton

On Mon, Mar 16, 2015 at 5:51 PM, Trevor Perrin <trevp at trevp.net> wrote:

> I'm considering a redesign of Noise, with the goal of making it a
> framework that can express a wider range of DH-based protocols.
>
> The previous Noise had a single box message, and a single pipe
> protocol.  So it wasn't optimal for every case, e.g. where clients had
> prior knowledge of server keys, or didn't want to do client
> authentication:
>
> https://moderncrypto.org/mail-archive/noise/2015/000109.html
>
>
> So the idea now is that Noise messages could be described with strings
> that just list a bunch of DH public keys and calculations in the order
> they should be sent / calculated, and libraries should be able to
> handle any message described by such a string (a descriptor).
>
> This needs a lot of fleshing out, but I'm curious if people like the basic
> idea.
>
> https://github.com/trevp/noise/blob/noise2/noise.md
>
>
> Here's how you can express various protocols with descriptors:
>
> ---
>
> The following "Box" protocols represent one-shot messages from a sender to
> a
> recipient.
>
>     Box naming:
>      S_ = static key for sender known to recipient
>      N_ = no static key for sender
>      X_ = static key for sender transmitted to recipient
>      _S = static key for recipient known to sender
>      _E = static and ephemeral keys for recipient known to sender
>
>     BoxSS(s, rs):            # ~ Nacl crypto_box
>       ndhss
>
>     BoxNS(rs):               # ~ public-key encryption
>       e, dhes
>
>     BoxXS(s, rs):            # ~ miniLock, old Noise box
>       e, dhes, s, dhss
>
>     BoxNE(rs, re):           # ~ public-key encryption + prekey
>       e, dhee, dhes
>
>     BoxXE(s, rs, re):        # ~ TripleDH
>       e, dhee, dhes, s, dhse
>
> The following Noise protocols represent handshakes where the initiator and
> responder exchange messages.
>
>     Handshake naming:
>
>      N_ = no static key for initiator
>      X_ = static key for initiator transmitted to responder
>      _S = static key for responder known to initiator
>      _X = static key for responder transmitted to initiator
>      _E = static key and an initial prekey for responder are known
>           to the initiator (but responder will also use a fresher
>           ephemeral)
>
>     HandshakeNX():           # ~ Ntor (+ server-id-hiding)
>     (1)    -> e
>     (2)    <- e, dhee, s, dhse
>
>     HandshakeXX(s):          # ~ old Noise pipe
>     (1,2)  HandshakeNX()
>     (3)    -> s, dhse
>
>     HandshakeNS(rs):
>     (1)    BoxNS(rs)
>     (2)    <- e, dhee
>
>     HandshakeXS(s, rs):
>     (1,2)  HandshakeNS(rs)
>     (3)    -> s, dhse
>
>     HandshakeNE(s, rs, re):
>     (1)    BoxNE(s, rs, re)
>            <- e, dhee
>
>     HandshakeXE(s, rs, re):
>     (1)    BoxXE(s, rs, re)
>            <- e, dhee, dhse
>
>
> Trevor
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20150320/65a5446a/attachment.html>