

CurveCP implementation committed to Google Chrome repo - self
http://src.chromium.org/viewvc/chrome/trunk/src/net/curvecp/

======
cleverjake
<http://curvecp.org/> for more info =]

~~~
valyala
Nice. I couldn't find the description on how long-term public keys' sharing
will avoid man-in-the-middle attack. It's unclear how clients will obtain
long-term public keys from new servers and how servers will obtain long-term
public keys from new clients? What if long-term keys will be compromised or
updated? Is there keys' revocation procedure?

The page <http://curvecp.org/security.html> says literally the following
regarding man-in-the-middle attack: "The client knows the server's long-term
public key in advance, before making a CurveCP connection. Servers that
differentiate between clients know the clients' long-term public keys in
advance."

I cannot imaging how all servers can know all clients' (billion of clients)
long-term keys?

~~~
bumbledraven
Apparently "by using DNS CNAME records to prepend the CurveCP elliptic curve
cryptography public keys to the DNS names of the DNS servers."
<http://en.wikipedia.org/wiki/DNSCurve>

~~~
valyala
OK. How this prevents from man-in-the-middle attack on public keys sent over
untrusted network? Can you point me to the description of the protocol aimed
against man-in-the-middle attack during long term public keys' distribution?
Let's say we have a server with a public key S and a client with a public key
C. How can they prevent man-in-the-middle attack when exchanging their public
keys over untrusted network?

I couldn't find any relevant details regarding this question on the official
DNSCurve site <http://dnscurve.org/> .

------
cpr
Fascinating. Too bad NaCl means something entirely different in the Curve CP
world than in the Chrome world.

