<div dir="ltr"><div><div>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.<br><br></div>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.<br><br></div><div>    Noise_IKnoidh(s, rs):<br>      <- s<br>      ...<br>      -> e, s, dhes, dhss<br>      <- e, dhee, dhes<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>It works if there is no PSK because the "s" token is in plaintext with no MAC value to fail.<br><br></div>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.<br><br>Maybe the lack of support for PSK's in this case is OK.  Maybe not.  Something to think about.<br><div><br></div><div>Cheers,<br><br></div><div>Rhys.<br><br></div></div>