[noise] certificate chains

[Trevor Perrin]

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