[noise] Oddity with IKnoidh, IXfallback, and PSK's

[Rhys Weatherley]

The new fallback variants have been pulled from rev30, but I was already
half-way through the code so I decided to continue to get the basics in
place ready for rev31.

All of the extra fallback scenarios work except for one: IKnoidh ->
IXfallback when PSK's are involved (the scenario is fine if there isn't a
PSK).  It took a while to figure out why.

    Noise_IKnoidh(s, rs):
      <- s
      ...
      -> e, s, dhes, dhss
      <- e, dhee, dhes

If there is a PSK involved, then the "s" token from the initiator to the
responder in the abbreviated handshake will be encrypted and MAC'ed.  The
associated data for this token encryption is based on a "h" generated from
the "rs" in the IKnoidh pre-message.

When the packet arrives at the IKnoidh responder, the "s" token cannot be
decrypted if the responder's "rs" has changed.  The associated data "h"
value will be different, so the "s" value from the initiator will be
discarded before it can be decrypted.  The initiator's "s" value is then no
longer available to initiate the "IXfallback" pattern.

It works if there is no PSK because the "s" token is in plaintext with no
MAC value to fail.

I'm not sure that any fallback/dependent pattern with a pre-message of "e,
s" can work if PSK's are involved during the abbreviated handshake.  Not
without relaxing the rules about checking MAC's anyway.

Maybe the lack of support for PSK's in this case is OK.  Maybe not.
Something to think about.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160707/77f2f71c/attachment.html>