Re: [Cfrg] Twist insecurity of 2y^2=x^3+x/GF(8^91+5)

[Dan Brown <[e-mail]>]

-----Original Message-----
From: [e-mail] 
On Fri, Aug 18, 2017 at 09:20:01PM +0000, Dan Brown wrote:
> 
> If the static DH key in the Montgomery ladder implementation above is 
> used in a higher-level protocol that requires key confirmation from 
> the other side before using the shared key in encryption, then it 
> seems the previous attacker's chances either are drastically reduced, 
> or the attacker requires billions of (failed) interactions (instead of 
> 5).  Is this right?  If so, in such a protocol, would a good remedy be 
> to place a limit (e.g. 1000/month) on the number of failed key 
> confirmation attempts?

It depends on protocol.

As example of how things can go wrong, take TLS 1.3. If the server keeps fixed DH key, one can send a few handshakes, and from the resposes (the server does key confirmation first!) do offline ~2^65 operation attack to find the fixed DH key.

And TLS 1.3 breaks _really_ badly if the server static DH key is compromised.

<DB>
Thanks.  

I reviewed TLS 1.3 based on your comments, and I agree with your conclusion.

I noticed that the client in TLS 1.3 should normally receive a protected {Finish} from the server before releasing information derived the shared secret.  So, the client receives key confirmation.  If the client is re-using the same static DH key, using a Montgomery without point validation, then by verifying key confirmation, the client is partially protected from small-subgroup attacks.  (I don't know if this is a known countermeasure.)  Or, am I missing something?

So, anyway, any initial I-D I write will likely put a MUST on point validation of static DH keys...

</DB>