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.
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.
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.
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.
This is elitist. The whole point of the OP is to describe it for the "layman", and you've curtly declared yours suitable "for anyone" - an even broader term - and yet now you're claiming it's supposed to be only for programmers, when reality is still further from your claim: That it is for programmers with a certain level of math knowledge (when in fact, ironically, anybody can understand diffie-hellman without needing to know the mathematical terms and notation).
Even allowing that you meant "programmers" originally, "programming" covers a massive field of knowledge sets. For example, I know what exponentiation and modular arithmetic are, but I can't derive the practical implications from your example without further research. I also have no idea what "g" is.
Was feeling briefly superior the purpose of your little half-baked discourse, or did you actually intend to demonstrate something useful as a learning tool? Hard to tell.
The above argument might feel slightly wrong to people because it relies on the property that (g^a mod p) ^ b mod p == (g^ab mod p). The fact that this holds isn't too hard to figure out, but requires knowledge that pq mod r == ((p mod r) * (q mod r)) mod r, which again isn't too hard to figure out. However, at this point you're asking people to derive two basic number theory properties in a row, and notably "using modulus to write fizz buzz" (which is the level most non-math-major programmers are at wrt to modulus) is not the same thing as knowing how to do basic number theory, and proficiency in the former doesn't imply proficiency in the latter.
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.
Yes, just do not write (mod p), as it can be misleading to the reader. A mathematician doesn't care, but in RFCs they call the (mod p) groups a "prime group" to differentiate it from the Elliptic Curve group. (In fact, I think they call them "prime fields", not merely groups).
I think the keys can be smaller because every random coordinate is a valid value (valid key), but in the case of RSA, valid values are more sparse.
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.
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 initiator.
I didn't roll my own. I'm using built-in browser functionality, available under crypto.subtle object of the browser. You can review the code in my WebUtil library on Github @borisreitman. It's just a light wrapper on top of browser's functionality.
Only thing I would improve on this page is to remove all remote dependencies, youtube, font, cdn files ...
sw.js consonantly sending some data. Personally I do not trust Google they have way to more data, and even if all scripts are stripped questions is does Chrome collecting data as well?
I'm the author. No data is sent after dependencies have loaded. The "init()" function in the page runs right after. So you can use the Network debugger to see that nothing is sent anywhere.
I just don't think an ugly page can be useful for the layman. It has to be a nice and user friendly page, which means it would have a lot of design loaded as well. Use the "_bare" page if you want to customize it for your needs.
You are right about YouTube embed. The sw.js is sending stuff, and I don't want that. I'm going to put the YouTube into an overlay, and will remove it from DOM after it's watched. EDIT: it's done.