3 ms·

Can we remake the Internet by encrypting every packet with ECC? Something like DJB's CurveCP [1] to replace TCP, but with some user-friendly improvements (seein

by devx 13y ago

Can we remake the Internet by encrypting every packet with ECC? Something like DJB's CurveCP [1] to replace TCP, but with some user-friendly improvements (seeing proper names and links, not just strings of random characters). DJB said the performance overhead to do that is only 15 percent [2], which seems well worth it to me. I feel that to feel really protected against the NSA in the future we'll need something like that, along with starting to demand open source firmware from all hardware vendors. In the meantime we can use ECDHE to encrypt all sessions. [1] http://curvecp.org/ http://curvecp.org/ [2] http://www.youtube.com/watch?v=K8EGA834Nok&feature=youtu.be&t=40m31s http://www.youtube.com/watch?v=K8EGA834Nok&feature=youtu.be&...

daxelrod 13y ago
Be careful with what ECC algorithm you use. Bruce Schneier recommends against ECC in [1]: > Prefer conventional discrete-log-based systems > over elliptic-curve systems; the latter have > constants that the NSA influences when they can. and clarifies in [2]: > I no longer trust the constants. I believe the > NSA has manipulated them through their relationships > with industry. [1]: http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance http://www.theguardian.com/world/2013/sep/05/nsa-how-to-rema... [2]: https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929 https://www.schneier.com/blog/archives/2013/09/the_nsa_is_br...
- tptacek 13y ago
  First, Schneier has a weird track record with ECC. I think he may be alone among "well-known" cryptographers in his distrust for ECC, which goes back over a decade. Second, the CurveCP "constants" aren't NIST derived; they're Bernstein's Curve25519, which is derived transparently from first-principles math. Third, there are standardized NIST curves (over binary fields) that are also derived transparently from first-principles. Fourth, the curves that aren't totally transparent are still derived from a SHA hash of random string, per the method in IEEE 1363 (which in 1363's context makes perfect sense, since you can't really generate "fresh" curves for applications from first principles without everyone ending up with the same curves). The backdoor scenarios here are... convoluted. The more you learn about the situation with NIST ECC, the less likely an overt backdoor seems. Maybe academia has missed something big, and all of ECC is broken; if that's the case, I think you should kiss conventional IFP and DLP crypto guby too.
- mix52 13y ago
  CurveCP uses Curve25519, not an NIST curve. Schneier's comments on ECC apply only to NIST curves such as P-256, which were influenced by the NSA. Curve25519 was developed independently by a guy who sued the US for the right to export crypto (djb).
mix52 13y ago
Good news: CurveCP already supports the user-friendly feature you describe, via CNAMEs. You make a CNAME for www.example.com to $pubkey.example.com. Users never see $pubkey.

by devx 13y ago

daxelrod 13y ago

Be careful with what ECC algorithm you use. Bruce Schneier recommends against ECC in [1]: > Prefer conventional discrete-log-based systems > over elliptic-curve systems; the latter have > constants that the NSA influences when they can. and clarifies in [2]: > I no longer trust the constants. I believe the > NSA has manipulated them through their relationships > with industry. [1]: http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance http://www.theguardian.com/world/2013/sep/05/nsa-how-to-rema... [2]: https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929 https://www.schneier.com/blog/archives/2013/09/the_nsa_is_br...

tptacek 13y ago
First, Schneier has a weird track record with ECC. I think he may be alone among "well-known" cryptographers in his distrust for ECC, which goes back over a decade. Second, the CurveCP "constants" aren't NIST derived; they're Bernstein's Curve25519, which is derived transparently from first-principles math. Third, there are standardized NIST curves (over binary fields) that are also derived transparently from first-principles. Fourth, the curves that aren't totally transparent are still derived from a SHA hash of random string, per the method in IEEE 1363 (which in 1363's context makes perfect sense, since you can't really generate "fresh" curves for applications from first principles without everyone ending up with the same curves). The backdoor scenarios here are... convoluted. The more you learn about the situation with NIST ECC, the less likely an overt backdoor seems. Maybe academia has missed something big, and all of ECC is broken; if that's the case, I think you should kiss conventional IFP and DLP crypto guby too.
mix52 13y ago
CurveCP uses Curve25519, not an NIST curve. Schneier's comments on ECC apply only to NIST curves such as P-256, which were influenced by the NSA. Curve25519 was developed independently by a guy who sued the US for the right to export crypto (djb).

mix52 13y ago

Good news: CurveCP already supports the user-friendly feature you describe, via CNAMEs. You make a CNAME for www.example.com to $pubkey.example.com. Users never see $pubkey.