[noise] Potential forgery attack on "ee, ss" patterns

[Trevor Perrin]

On Fri, Jun 22, 2018 at 10:51 AM, Karthikeyan Bhargavan
<karthik.bhargavan at gmail.com> wrote:
> Trevor,
>
> I think we’re agreeing that the text in validity rule 3 of 7.1 may need some fixing but the precise conditions this rule intends to enforce on patterns is the following
> (I have broken it into 4 parts for my own understanding):
>
> a) If the initiator     encrypts data after processing an ss token, it must have also processed an es token
> b) If the responder     encrypts data after processing an ss token, it must have also processed an se token
> c) If the initiator     encrypts data after processing an se token, it must have also processed an ee token
> d) If the responder     encrypts data after processing an es token, it must have also processed an ee token
>
> Is the above correct?

Yes.


> Let me explain, just one last time before we move on, why the current text does not enforce the above rules.
> It is not a big deal, since writing down logical rules in readable text often leads to such ambiguities, but understanding it may guide us on how to fix the text:
>
>> After performing a DH between a remote public key (some remote e or remote s)  And any local key that is not the ephemeral private key (some local s), the local party must not call ENCRYPT() unless it has also performed a DH between the ephemeral private key (some local e) and the remote public key (the same remote e or remote s).
>
> This text reads as:
> a') If the initiator    encrypts data after processing an ss or se token, it must have also processed an es or ee token
> b') If the responder    encrypts data after processing an ss or se token, it must have also processed an es or ee token


I don't understand that reading.  The key phrase is "the remote public
key", at the end.

This is clearly referring to the remote public key that was mentioned
earlier in the text, but you seem to be reading it as "any remote
public key" (despite the parenthetical you added saying "the same
remote e or remote s")?

Anyways, I'm happy to spell this out more, I just think the current
text is correct, though probably too terse.



> Now, although I understand why Noise would want to enforce this validity rule (using ss only in combination with es/se) and it is fine to keep the current design.
> However, it is also worth noting that an alternative handshake processing and pattern validity rule could make things uniform for DH and PSK patterns and allow more safe patterns.
> For example:
> ====
> Handshake Token Processing (for all handshakes — both PSK and non-PSK):
> - In all handshakes, the "e" token in a pre-message pattern or message pattern always results in a call to MixHash(e.public_key), followed by MixKey(e.public_key).

It is debatable how "safe" patterns using only "ee" and "ss" are.
They are less safe than the patterns this validity rule enforces.

In any case, if we required MixKey(e) for all patterns we're imposing
a cost (extra HKDFs) on the majority of better patterns which don't
need this.  Also it would break compatibility, which is a nonstarter
at this point.

So we could imagine having a separate token for ephemerals ("me" or
something) which always does MixKey(ephemeral), and follows a
different validity rule than #3.

That's a lot of effort to support badly-designed protocols, so I don't
think we should do it.  I think it's a good thing that if you're using
Noise, you're probably using a good protocol with strong crypto, and
don't really want to compromise that.

But happy to keep considering it, if people really want "Unified
Model" style patterns for some reason.

Trevor