[messaging] Two-pass DH instead commitment

[Van Gegel]

The above scheme use the classical commitment. But in my case it is more convenient to implement a two-pass key exchange instead commitment. 
The question is whether it is possible to effectively influence the SAS by changing at a part of the key even after most of the key was sent to the first pass? Is there a suitable mathematical methods to do this in the relative to EC25519? 

For example, an attacker must obtain a specified 32-bit SAS (for MitM). He receive a 224-bit key and then must send your 224-bit, and then receive  remaining 32 bits and must send remaining 32 bits. Can the attacker pick your key effectively to solve the problem in polinomal time? 

21 February 2016, 22:52:19, by "Natanael" < natanael.l at gmail.com >: 

This sounds like what KDF:s were invented for. You can send public key hashes before the public keys in your key exchange to verify that the keypairs was generated prior to learning the public key of the counterpart, then use a KDF like scrypt or the new Argon2 on the shared secret which was generated to derive the SAS. - Sent from my tablet Den 20 feb 2016 21:21 skrev "Van Gegel" < torfone at ukr.net >: 
I want to perform DH on the EC25519 and verify the secret using a short fingerprint (32 bits SAS). Typically in this case the commitment needed for preventing MitM by influence the responder's key after originator's key was received.  
To be securely the following scheme instead commitment: 
first exchange parts of the keys (first 224 bits) and then the remaining 32 bits during second pass? 


_______________________________________________ 
Messaging mailing list 
Messaging at moderncrypto.org 
https://moderncrypto.org/mailman/listinfo/messaging 

_______________________________________________
Messaging mailing list
 Messaging at moderncrypto.org 
 https://moderncrypto.org/mailman/listinfo/messaging 

 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20160222/033a1de1/attachment.html>