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

[Trevor Perrin]

On Wed, Mar 25, 2015 at 3:42 PM, Kenton Varda <kenton at sandstorm.io> wrote:
>>
>> 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.

Works for introductions, that's sort of Kerberos, but:
 - How does Alice open sessions with Bob and Charlie in first place?
It can't be introductions all the way down, being able to connect
based on public key seems desirable somewhere?
 - Using DH means Alice can't read Bob and Charlie's traffic, seems
like a nice if not necessary property


> 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.

Dunno about that, if introduction keys are being encrypted to the
process's private key, then compromising the private key gets you the
introduction keys.


>> 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.)

The introducer could provide a token or introduction key, and the
parties could strike it out upon receiving the 0-RTT message.  So
that's a whitelist approach to 0-RTT antireplay.

In this case the introducer could execute a replay attack on
introduced parties (by providing the same token twice), but maybe
that's OK.

Trevor