4 ms·
CurveCP implementation committed to Google Chrome repo
- cleverjake 15y agohttp://curvecp.org/ http://curvecp.org/ for more info =]
- valyala 15y agoNice. 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 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 15y agoApparently "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 http://en.wikipedia.org/wiki/DNSCurve
- valyala 15y agoOK. 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/ http://dnscurve.org/ .
- cpr 15y agoFascinating. Too bad NaCl means something entirely different in the Curve CP world than in the Chrome world.