Show HN: Diffie-Hellman exchange for the layman(borisreitman.com)
borisreitman.com
Show HN: Diffie-Hellman exchange for the layman
https://borisreitman.com/privacy.html
53 comments
Update: the tool now allows to encrypt (and decrypt) files. It works in mobile browser too.
diffie-hellman key change for anyone:
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
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
Most people won’t understand any of what you’re describing there, except for “the end” and that you’re describing a four-step process.
Agreed, I really like the paint examples to explain diffie hellman.
https://www.comparitech.com/blog/information-security/diffie...
https://www.comparitech.com/blog/information-security/diffie...
The paint example is what made it click for me too. via this video . https://www.youtube.com/watch?v=YEBfamv-_do
most programmers won't understand exponentiation and modular arithmetic? whew boy no wonder people complain about leetcode style interviews
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.
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.
I guess eighth grade arithmetic is elitest now <shrug>
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.
>pq mod r == ((p mod r) * (q mod r)) mod r
that's just multiplication in Z_r...?
edit: alright i guess technically it uses homomorphism from Z to Z_r but you don't need to be able to write out the proof to intuit/believe it
that's just multiplication in Z_r...?
edit: alright i guess technically it uses homomorphism from Z to Z_r but you don't need to be able to write out the proof to intuit/believe it
"for anyone" and "for programmers" are two entirely different things.
you know lots of bakers that read hn?
[deleted]
What is g here?
Unfortunately I had to check it as well, and g seems to be a generating element of a finite cyclic group G
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...
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.
In the case of DH, g is some such element.
In the case of DH, g is some such element.
I think it should also explain why this is secure. It may not be obvious that why you can't just compute the logarithm and get the shared key.
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.
I don't think I can explain to a layman without math backround why it is secure. So I have kept it simple.
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.
Perhaps a simpler way of explaining:
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.
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.
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.
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 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.
p needs to be prime because...?
I'm using Elliptic Curve variant. There's no "mod". But you got the general idea. Also, all the math is built-in and done natively by the browser.
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?
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.
So, yeah I was right only not sure why did I got so many negative points, for stating obvious truth ?! :D
That's totally normal here. You also get downvotes for talking about it, like we both are now.
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.
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.
Interesting, but why does the "Check" use a handmade hashing algorithm that is just summing up all bytes?
A much safer implementation would be to take the sha256 of the key and only show the 2 rightmost bytes.
A much safer implementation would be to take the sha256 of the key and only show the 2 rightmost bytes.
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.
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.
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.
(https://security.stackexchange.com/questions/91699/why-cant-...)
TLDR: "Without authentication, impersonation is feasible, ..."
TLDR: "Without authentication, impersonation is feasible, ..."
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.
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.
cant help but be distracted by there being a circular picture of the author staring at me as i read this
I'm the author. This is a good suggestion, and I have moved my picture from the side menu, to the top of the scrollable portion.
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.
Thank you!
Thank you!
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.
Thank you, I am the author. Feel free to contact me if you have tips how to make it even simpler.
Note: P-256 is not considered a safe curve. Use Curve25519 instead. See: https://safecurves.cr.yp.to/
Hi, I am the author. I know, but I wanted to use something built-in in the browser. When the browser implements Curve25519 I will change the code.
IIRC, aren't there a bazillion gotchas and practical problems implementing DH where it's definitely something one shouldn't roll their own?
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.
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'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.