Change method of PK production for FAKE friend in DHT

[NamsooCho]

Fixes #1169
It would be better for FAKE friend to use real public key.

---

This change is 

[CLAassistant]

All committers have signed the CLA.

[zugz]

* Friday, 2018-10-19 at 21:05 -0700 - Cho <notifications@github.com>:

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?

[NamsooCho]

But, this PR can completely remove possibility of redundancy of fake friend's PK.

[zugz]

* Saturday, 2018-10-20 at 02:36 -0700 - Cho <notifications@github.com>:

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?

[iphydf]

What is the redundancy this PR eliminates?

[NamsooCho]

What is the redundancy this PR eliminates?

It is possible that my dht PK is same as random fake PK.
Random fake PK may be same as a node's dht PK in tox network.
Here a node is not my friend.

[iphydf]

How does crypto_new_keypair avoid this?

[NamsooCho]

As I remember, PK generated with crypto_new_keypair is UUID.

[sudden6]

It is possible that my dht PK is same as random fake PK.

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.

[iphydf]

@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?

[NamsooCho]

https://crypto.stackexchange.com/questions/54378/short-ed25519-keys-can-i-use-as-id

Well, I can't insist on using crypto_new_keypair.
I guess that using crypto_new_keypair would make a little bit thing to avoid collision.

[zugz]

* Saturday, 2018-10-20 at 02:12 -0700 - zugz <notifications@github.com>:

* 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!

[iphydf]

Looks fine. Can you rebase on master?

[NamsooCho]

I did rebase. But I can't confirm rebasing is actually done. Let me know if rebasing is done successfully.

[codecov]

Codecov Report

Merging #1235 into master will decrease coverage by 0.3%.
The diff coverage is 100%.

@@           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

Impacted Files	Coverage Δ
toxcore/DHT.c	76.7% <100%> (-0.1%)	⬇️
toxav/msi.c	63.9% <0%> (-2.8%)	⬇️
toxav/toxav.c	67.3% <0%> (-2.3%)	⬇️
auto_tests/toxav_basic_test.c	81.6% <0%> (-2%)	⬇️
toxcore/net_crypto.c	93.5% <0%> (-1.5%)	⬇️
toxcore/onion_client.c	96% <0%> (-0.2%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 744dc2f...15cc805. Read the comment docs.

[NamsooCho]

rebase done.

[zugz]

* Tuesday, 2018-10-23 at 20:17 -0700 - Cho <notifications@github.com>:

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)?

[NamsooCho]

done

[zoff99]

Reviewed 1 of 1 files at r1.
Reviewable status: 0 of 1 approvals obtained

[zoff99]

Reviewable status: 0 of 1 approvals obtained