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.
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.
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.
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.
DH relies on the discrete logarithm problem. That means that if I give you g + g + .. + g, where g is added to itself n times, it will be difficult for you to find out what n is.
Both parties share the same prime p, and the same base point g. Then each of them select a random, secret point. Say Alice's secret is a and Bob's is b. Now each of them create their "public key", which is just g + g + g .. a times, and g + ... b times to create A and B, respectively. The (mod p) simply means divide the result by p and take the remainder as the answer.
Now if I am Alice, my secret is a, my public key is A. Bob sends me B = g^b (mod p). I exponentiate this with my own secret key to get shared secret = (B)^a = (g^b)^a = (g^a)^b = g^(ab) (mod p)
(mod can be deferred to the end of the calculation or done at each step, without changing the answer)
So you can see that, since the order of exponentiation doesn't matter, when Bob does the same calculation (multiplying his private b with alice's public key g^a) he gets the same shared secret.
I have no idea what this means, personally. I did understand the math and its practical implications long ago: I started with the paint-mixing example, which helped a lot, and went from there.
Note that I'm using the Elliptic Curve Diffie-Hellman (ECDH) exchaneg, which is an additive group. That's how I can get the shared keys down to a small size.
A group is a group. Doesn't matter whether you call it additive or multiplicative. So DH doesn't change since either way g^a and a*g are both defined as repeated action of g on g via the group operation.
ECDH has smaller keys because the attacks are (until now) weaker and not because you're using an additive cyclic group.
I'm the author. If you are referring to my page, the Developer notes provide all the info you need, and the source code is trivial. I've placed all the encryption stuff in a barebones open source library that you can read on GitHub. This makes the remaining source code in the page trivial.
I don't think I can explain to a layman without math backround why it is secure. So I have kept it simple.
Diffie Hellman Key Exchange is performed over a cyclic group. That's just a large set of elements that wrap back around to each other. So for example the integers mod 7 is {0, 1, 2, 3, 4, 5, 6}. A generator for this group is any element that you can continuously add to generate the whole group, for example: 1.
Good idea. I will change it, should be live in 1 hour. I am going to SHA-256 hash it, then add the bytes of the hash and mod by 10000. It's better than just taking the first two bytes, because I want a 4 digit number.
I've improved the encrypt/decrypt form. Now the textareas expand, and there's a copy to clipboard button in order to copy the output. It makes it much easier to use on the phone.
This is really great! I liked the video explanation as well as the page which shows how we go about exchanging information using DH exchange. Will be sharing this page with some of my non-technical friends.
I've simplified the page by creating two modes: "simple" and "advanced". By default "simple" is shown, and it's what you'd need if you are the recipient, rather than an initiator would would be normally more technical.
I've made a new addition: now the operating system of the other party is also sent as part of the exchange. This info helps decide what software to use for further encryption. e.g. DMG or BitLocker? And, I managed to do it without making the string longer. I stuffed it in the unused bits of the compressed coordinate.
Readit News
TLDR: "Without authentication, impersonation is feasible, ..."
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.
given large prime p, some a, some b:
1. A = g^a mod p
2. B = g^b mod p
3. exchange A,B
4. B^a mod p = (g^b)^a mod p = (g^a)^b mod p = A^b mod p is the shared key.
the end
https://www.comparitech.com/blog/information-security/diffie...
DH relies on the discrete logarithm problem. That means that if I give you g + g + .. + g, where g is added to itself n times, it will be difficult for you to find out what n is.
Both parties share the same prime p, and the same base point g. Then each of them select a random, secret point. Say Alice's secret is a and Bob's is b. Now each of them create their "public key", which is just g + g + g .. a times, and g + ... b times to create A and B, respectively. The (mod p) simply means divide the result by p and take the remainder as the answer.
Now if I am Alice, my secret is a, my public key is A. Bob sends me B = g^b (mod p). I exponentiate this with my own secret key to get shared secret = (B)^a = (g^b)^a = (g^a)^b = g^(ab) (mod p)
(mod can be deferred to the end of the calculation or done at each step, without changing the answer)
So you can see that, since the order of exponentiation doesn't matter, when Bob does the same calculation (multiplying his private b with alice's public key g^a) he gets the same shared secret.
ECDH has smaller keys because the attacks are (until now) weaker and not because you're using an additive cyclic group.
I don't think I can explain to a layman without math backround why it is secure. So I have kept it simple.
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...
In the case of DH, g is some such element.
Deleted Comment
A much safer implementation would be to take the sha256 of the key and only show the 2 rightmost bytes.
Thank you!