[noise] Cap'n Proto case (was: Potential redesign?)

[Kenton Varda]

On Wed, Mar 25, 2015 at 1:24 PM, Trevor Perrin <trevp at trevp.net> wrote:

> > Well, Alice can only introduce nodes she's still connected to, so the
> > ephemerals couldn't have been destroyed yet.
>
> In general protocols destroy ephemeral DH private keys immmediately
> after a handshake, e.g. Noise envisioned that the parties might do
> one-way updating of their cipher keys as they exchange messages, so
> that a compromise doesn't reveal old data, but that means you have to
> throw the ephemeral DHs away.
>

Ah! Right. I'm not sure why I didn't realize that. I guess this invalidates
a lot of my thinking.


> > Bootstrapping trust from long-lived keys will happen at a different
> level.
> > For example, it could be that a DNS-like system returns not only an
> address
> > but also the current process key, signed by a long-term key.
> (Incidentally,
> > this means that the live process never needs to see the long-term key
> which
> > helps reduce the damage from heartbleed-type attacks.)
>
> OK, I'd been assuming the "static" keys *were* the long-lived keys,
> but I guess things are different.  You mentioned earlier you would
> encourage "process lifetimes to be limited to a day or less".
>

I'm probably being confusing because I seem to have three levels of keys
(per-connection, per-process, and permanent) whereas most protocols expect
only two. "Per-process" can map to "static" in the sense that it is used
for multiple sessions but "ephemeral" in that it has a limited lifetime.


> It's hard to make suggestions about keys/protocols without
> understanding all the key management, there's just a lot of ways to
> slice these problems, and everything interacts.
>
> But if it's true that processes have "static" keys of a day or less,
> you could possibly get by with just Nacl-style boxes (BoxSS), where
> you encrypt directly based on static-static DH keys, and live with
> forward-secrecy windows of < day (due to static key replacement).
>

Thanks, that was my feeling.

Though now I am thinking of some other ideas...

When Alice introduces Bob to Carol, Alice could generate a random symmetric
key sent to both parties. Bob and Carol would use this key as an additional
seed for their PRF chains.

Now, to decrypt a recorded conversation between Bob and Carol, you would
need not only to compromise one of their private keys, but also to
compromise this introduction key, which requires compromising the
conversation with Alice. In fact, it seems like you don't necessarily even
need a DH exchange here at all, because as stated earlier if Alice is the
only introducer between Bob and Carol, we actually consider it acceptable
for Alice to MITM the session. Once there is a second introducer, the
second introduction key will be factored in, and now the two introducers
would have to be in collusion to decrypt the conversation (which, again, we
don't consider a threat).

But this seems entirely too simple and obvious to actually work. :) I must
be missing something.

Even if it does work, I would probably keep DH on top of this for defense
in depth, but the addition of the introduction key seems to mean that
merely compromising a process's private key gets you nothing on its own.

Forward-secrecy, and particularly "perfect" forward secrecy, is sort
> of a misnomer.  There's not a binary property here, there's just a
> relationship between key lifetimes and how much data is exposed if the
> key is compromised.
>
> So the more-quickly you destroy keys for old data the better, but that
> has to be balanced against other concerns.
>

Yeah, I think I'm more looking for opinions than facts here. :)


> Anyways, one factor I haven't brought up - and that dkg did a good job
> bringing up on TLS list recently - is that 0-RTT depends on recipients
> maintaining state (whitelists or blacklists) to prevent replays of
> initial messages.
>
> I don't know how big an issue that would be in your system.  If you
> don't want to deal with that state-management, and the risks it brings
> (performance, DoS, losing the state) then accepting a 1-RTT protocol
> may be easier.
>

Indeed. State management is relatively easy in my case because we're
talking about processes, so state can be kept in RAM. If the state table
gets too large, kill the process and start a new one.

Then again, the introduction key thing might help here too. If the process
somehow lost its state while keeping its private key, a replay attack would
not work because it would be using an introduction key that the receiver
doesn't recognize. (But again, this seems too easy so I must be missing
something.)

-Kenton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20150325/3418ad94/attachment.html>