5 ms·

It bears note that this is still subject to a MITM attack on whatever channel is used for the information exchange. You cannot generate a shared secret without

It bears note that this is still subject to a MITM attack on whatever channel is used for the information exchange. You cannot generate a shared secret without either an existing shared secret or some form of secure authenticated communication channel in the first place. I mean, you can, but you can't be sure who it is that you're sharing the new secret with.

TickleSteve 6y ago
(https://security.stackexchange.com/questions/91699/why-cant-i-mitm-a-diffie-hellman-key-exchange https://security.stackexchange.com/questions/91699/why-cant-...) TLDR: "Without authentication, impersonation is feasible, ..."
- libeclipse 6y ago
  tldr: preventing MITM attacks requires setting up an authentication workflow. Without this, you have no guarantees about who you're speaking to. For example, TLS 1.3 does this by (after performing ephemeral DH key exchange) signing the conversation transcript with the server's long term identity key. After this the client is sure that they are speaking to the correct server, but the server has no authenticity guarantees about the client.
  - boris1 6y ago
    The only way is to use another channel for the Short Authentication String (SAS) (check digits in my case). I recommend that people SMS them the check digits, and exchange the DH offers by email.
boris1 6y ago
That's why you have the Check Digits. There's no way to communicate a long and cryptic password on the phone. But it is easy to compare check digits on the phone.
- MauranKilom 6y ago
  I'm not convinced that transmitting the first, say, 5 characters of the full password is any less secure than transmitting the sum of all its "digits". In fact, I would expect the latter to be significantly easier to match by brute force by a MITM adversary.
  - boris1 6y ago
    There's no difference for the MITM how I pick the Short Authentication String (SAS) (the check digits). But there's a difference in terms of strength of the encryption key, if you are planning to use the full password as input to Key Derivation Function (KDF). If you make public the first 5 letters of a 44 letter password, you've just made lost some of the entropy. By the way, based on a comment in this thread, I added a SHA-256 stage. I now hash the full password, and sum the bytes of the hash to generate the check digits.

TickleSteve 6y ago

(https://security.stackexchange.com/questions/91699/why-cant-i-mitm-a-diffie-hellman-key-exchange https://security.stackexchange.com/questions/91699/why-cant-...) TLDR: "Without authentication, impersonation is feasible, ..."

libeclipse 6y ago
tldr: preventing MITM attacks requires setting up an authentication workflow. Without this, you have no guarantees about who you're speaking to. For example, TLS 1.3 does this by (after performing ephemeral DH key exchange) signing the conversation transcript with the server's long term identity key. After this the client is sure that they are speaking to the correct server, but the server has no authenticity guarantees about the client.
- boris1 6y ago
  The only way is to use another channel for the Short Authentication String (SAS) (check digits in my case). I recommend that people SMS them the check digits, and exchange the DH offers by email.

boris1 6y ago

That's why you have the Check Digits. There's no way to communicate a long and cryptic password on the phone. But it is easy to compare check digits on the phone.

MauranKilom 6y ago
I'm not convinced that transmitting the first, say, 5 characters of the full password is any less secure than transmitting the sum of all its "digits". In fact, I would expect the latter to be significantly easier to match by brute force by a MITM adversary.
- boris1 6y ago
  There's no difference for the MITM how I pick the Short Authentication String (SAS) (the check digits). But there's a difference in terms of strength of the encryption key, if you are planning to use the full password as input to Key Derivation Function (KDF). If you make public the first 5 letters of a 44 letter password, you've just made lost some of the entropy. By the way, based on a comment in this thread, I added a SHA-256 stage. I now hash the full password, and sum the bytes of the hash to generate the check digits.