[noise] Security Assumptions for Noise Pre-Messages

[Andris]

Hi all,

I have been struggling with this for a while now and haven't been able to come up with an entirely satisfying answer. Also, it would be useful to have a more official guidance.

My question is: What security properties can be assumed to hold for keys in pre-messages?

The closest thing to an answer I have found on this so far comes from the "Misusing public keys as secrets" section in the Security considerations of the Noise spec. However, this section only goes as far as stating that DH-keys shouldn't be used as PSKs and does not really touch on the above question.

The best I have been able to come up with is the following:

Confidentiality: None, since
a) These are public keys after all.
b) In some cases (e.g. the proposed use cases for fallback protocols or Noise Pipes) the keys would have been received from previous handshake messages where they were either sent unencrypted or encrypted with fairly weak guarantees (based on only an ee in the Noise Pipes switch handshake).

Authenticity:
- Fairly strong for static keys
- None for ephemeral keys
since
a) If we cannot assume the static keys to be authentic in some form, many of the security properties the spec asserts for the protocols wouldn't hold.
b) Ephemeral keys would presumably have been received in the clear. While, in the suggested use cases for fallback protocols, they would have been authenticated, a proposed reason for using the fallback protocol is being unable to verify this.

The reasons I am still skeptical of this are:
a) I likely missed something along the way. Having someone else looking over it can't hurt.
b) There is still a lot of handwaving involved. A more rigorous wording would be helpful for certain use cases.
c) Static and Ephemeral keys are treated differently. If possible, a more consistent approach seems preferable.
d) The suggested authenticity assumption for static keys is not always met. While I don't expect Noise to be the solution to the trust on first use problem, a better formulation of these assumptions might address this.

Cheers,
Andris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180713/d9e20dd8/attachment.html>