[noise] Use cases which don't fit Noise Pipes

[Kenton Varda]

[re-sending now that I'm on the list so it won't bounce]

On Fri, Feb 13, 2015 at 5:58 PM, Kenton Varda <kenton at sandstorm.io> wrote:

> Hi all,
>
> I can add more background on the Cap'n Proto case.
>
> Cap'n Proto is a distributed object capability protocol. A set of
> processes may hold object-capabilities granting access to objects hosted in
> other processes, and they may freely exchange these capabilities between
> each other. If process Alice holds a capability hosted by process Carol,
> Alice necessarily has a connection open to Carol. But if process Bob has
> never had any capabilities hosted by Carol, and vice versa, they may not
> have a connection. So when Alice takes her capability pointing to Carol and
> sends it to Bob, then Bob needs to open a new direct connection to Carol.
> Since we expect this to happen frequently, we want it to be fast.
>
> So, we commonly have the following use case:
> - Alice has preexisting open connections to Bob and Carol.
> - Alice wishes to instruct Bob to open a direct connection to Carol in
> order to access some capability hosted there, and instruct Carol to accept
> that connection and allow Bob to access the capability.
> - Bob doesn't care about Carol's identity except that she is the Carol
> that Alice told him to connect to. Similarly, Carol doesn't care about
> Bob's identity except that he is the Bob that Alice said was going to
> connect. Note in particular that we don't care if Alice can MITM this
> connection, because Alice is only delegating authority she already had
> anyway.
>
> I'd like to optimize the connection opening between Bob and Carol such
> that:
> - When Alice decides to introduce Bob to Carol, she can immediately send
> the introduction message to each without any non-local preparation.
> - As soon as Bob receives the introduction message from Alice, he can
> start sending messages to Carol, without any handshake. Similarly, Carol
> can immediately begin sending messages to Bob.
>
> I think that this can be done:
> - Alice can be sure to maintain up-to-date short-term public keys for
> every process to which she is connected.
> - Alice can forward Bob's key to Carol and vice versa in the introduction
> message.
> - Now Bob and Carol have all they need to generate a shared secret and
> start sending messages.
> - If Bob and Carol have already been introduced previously, they can keep
> using their existing session. This means there is only ever one session for
> any pair of keys, which seems useful for preventing replay attacks.
>
> However, I'm not a crypto protocol designer so, obviously, I shouldn't
> attempt to design my own. Would be great if there were some common
> construct for this purpose.
>
> Thanks,
> -Kenton
>
> On Thu, Feb 12, 2015 at 11:30 PM, Tony Arcieri <bascule at gmail.com> wrote:
>
>> Nanomsg is another interesting case study on people puzzling out
>> encryption for an asynchronous message-oriented protocol:
>>
>> https://www.freelists.org/post/nanomsg/nanomsg-and-encryption
>>
>> --
>> Tony Arcieri
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20150213/5b8604f3/attachment.html>