Change method of PK production for FAKE friend in DHT #1235
Conversation
|
|
|
* Friday, 2018-10-19 at 21:05 -0700 - Cho <[email protected]>:
It would be better for FAKE friend to use real public key.
One of the features of Curve25519 is "free key validation": every
32-byte bitstring is a valid public key. So using random_bytes to
generate a fake public key is fine, no?
|
|
But, this PR can completely remove possibility of redundancy of fake friend's PK. |
|
* Saturday, 2018-10-20 at 02:36 -0700 - Cho <[email protected]>:
But, this PR can completely remove possibility of redundancy of fake friend's PK.
I don't know. Maybe it's neater not to rely on this property of the
cryptosystem, but on the other hand calling crypto_new_keypair means
doing (a small amount of) needless computation. I'd like a third
opinion. @iphy?
|
|
What is the redundancy this PR eliminates? |
It is possible that my dht PK is same as random fake PK. |
|
How does |
|
As I remember, PK generated with |
If you manage to generate a random 32 byte string that matches your own Public Key you must be very unlucky as this is so unlikely it's impossible for all practical applications. |
|
@NamsooCho how does UUID avoid collisions? By the way, I'm not against this PR in principle, but if we do it, we should do it for the right reason. Can you check whether your memory ("As I remember") is in fact correct, and point at the documentation or code location in libsodium that demonstrates it? |
|
https://crypto.stackexchange.com/questions/54378/short-ed25519-keys-can-i-use-as-id Well, I can't insist on using |
|
* Saturday, 2018-10-20 at 02:12 -0700 - zugz <[email protected]>:
* Friday, 2018-10-19 at 21:05 -0700 - Cho ***@***.***>:
>It would be better for FAKE friend to use real public key.
One of the features of Curve25519 is "free key validation": every
32-byte bitstring is a valid public key. So using random_bytes to
generate a fake public key is fine, no?
Actually no, it isn't fine. Although every 32-byte bitstring is a valid
public key, not every such bitstring is *generated as* a public key in
key generation. The scalar multiplication function Curve25519 defined on
p5 of https://cr.yp.to/ecdh/curve25519-20060209.pdf is not surjective.
So using a random bitstring as fake friend public key means they will
often (about 1/2 of the time) be distinguishable from actual DHT public
keys. It is a useful property of fake friends that they make it a little
more difficult for people trying to track actual friend searches. So, we
might as well strengthen this effect by eradicating this
distinguishability, which is what this PR does.
So, I approve of this PR after all!
|
|
Looks fine. Can you rebase on master? |
NamsooCho
force-pushed
the
random_pk
branch
3 times, most recently
from
ca1a4bb
to
f4cfd4b
Compare
|
I did rebase. But I can't confirm rebasing is actually done. Let me know if rebasing is done successfully. |
Codecov Report
@@ Coverage Diff @@
## master #1235 +/- ##
========================================
- Coverage 83.2% 82.9% -0.4%
========================================
Files 82 82
Lines 14685 14685
========================================
- Hits 12220 12175 -45
- Misses 2465 2510 +45
Continue to review full report at Codecov.
|
zugz
force-pushed
the
random_pk
branch
2 times, most recently
from
10ef3b0
to
e448882
Compare
|
rebase done. |
|
* Tuesday, 2018-10-23 at 20:17 -0700 - Cho <[email protected]>:
rebase done.
Sorry, I messed things up in trying to trigger the build system to
unstick. Could you resign the commit (by doing 'git commit --amend'
say)?
|
|
done |
There was a problem hiding this comment.
Reviewed 1 of 1 files at r1.
Reviewable status: 0 of 1 approvals obtained
Fixes #1169
It would be better for FAKE friend to use real public key.
This change is