[noise] certificate chains

[Arvid Picciani]

Thanks Trevor,

i feel like the full details would be a bit boring and offtopic,
but essentially it's distributed routing table where a route is signed
by the recipient.
so each recipient is necessarily an ed25519 public key.

simplified table:

recipient |  via | otherstuff | signature
---------------------------------------------------
pub key 1 |  pub key 2 | .. | signed by privkey 1

in order to each a party, you validate its signature in the table and
connect to the peer in via.
there's some port magic done and we end up with a direct stream socket
established between pubkey1 and the initiator
now we're in noise land.
at this point we have a connection but we dont know if its the
expected peer. A hostile router can just not establish the peer to
peer but proxy the connection instead. We wouldnt know.
So in order to verify the connection is indeed the right peer, we need
the peer to proof it holds the ed25519 private key for the public key
we wanted to connect to

I could just use XX, and do a signature exchange on top, but just
doing KX with the x25519 derived from ed25519 seems no less secure to
my uneducated eyes.

> unauthenticated Noise handshake, then exchange signatures over the handshake hash afterwards

by that you mean XX or is the handshake hash in NN safe? I am really
scared of singing anything that is based on just ephemerals
transmitted on the wire. It just seems like it might be easy to
replay.

> Offline signing keys

this sounds very close to what i want, but isnt it the wrong way
around? If i read this correctly my case is more like:
(naming signature 'u' here, for a lack of understanding this properly,
very sorry)

  <- u
  ...
  -> e
  <- e, ee, s, u(s), es,
  -> s, u(s), se,


> to use signatures directly.

well, that would be really cool, but a totally different cryptosystem
so i dont feel comfortable wandering there alone.
Can you just simply sign the ephermal?

  <- u
  ...
  -> e, u(e)
  <- e, u(e), ee

this sounds a little too trivial to be correct. I'm guessing i want to
put something into the HKDF like you suggested, but wouldnt that have
to be identical on both ends?




On Sun, Jul 1, 2018 at 8:07 PM, Trevor Perrin <trevp at trevp.net> wrote:
> On Sun, Jul 1, 2018 at 12:40 PM, Arvid Picciani <aep at exys.org> wrote:
>> ok x255519 can be derived from ed25519 just fine.
>> here's what's working for me with XK:
>>
>> 1. initiator knows the ed25519 pubkey of the responder from an offline exchange
>> 2. responder knows the ed25519 pubkey of a CA
>> 3. responder derives a static x255519 sk/pk pair from its static ed25519
>> 4. initiator derives a static x255519 sk/pk pair from its static ed25519
>> 5. -> e, es
>> 6. <- e, ee
>> 7. > s, se  with payload being the initiators ed25519 plus its signature chain
>> 8. responder derives x255519 pubkey from the ed25519 in payload and
>> verifies it is identical with s
>> 9. responder verifies the rest of the chain contains a signature by the CA
>>
>> Other than using constant time comparison in 8, any other pitfalls in
>> this model?
>
>
> Hi Arvid,
>
> As a general rule you shouldn't reuse keys across different
> algorithms, or in different protocols.  So it sounds like you're doing
> dangerous things.
>
> If you describe your situation and goals from the ground up we can
> give better advice.  It's not clear what you're trying to do.
>
> Noise is currently designed to use long-term DH keys (like X25519
> keys).  If you are committed to long-term signing keys, then we'd have
> to think about how to fit them into Noise.  There might be a few
> options, such as:
>
>  * Channel binding, where you perform an unauthenticated Noise
> handshake, then exchange signatures over the handshake hash afterwards
>
>  * Offline signing keys / short-lived statics, as discussed in the
> recent post "Hashing additional context into handshake"
>
>  * Using "pattern modifiers" to transform Noise patterns to use
> signatures directly.
>
> It would take some thought and effort to choose between these and
> implement them, so we'd need a clear understanding of your use case to
> figure it out.
>
>
> Trevor