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

[Karthikeyan Bhargavan]

> 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.

Of course, you’re right. Was misreading it yet again.
In any case, all of this has given me a better understanding of why “ee,ss” isn’t a good Noise pattern.

Thanks for your patient answers,
Karthik

> 
> 
> 
>> 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