4 ms·
> Your conception of the speed of public-key crypto is warped by how slow SSL is; 256 bit elliptic curve crypto, which hasn't degraded in security for almost 25
by briansmith 16y ago
> Your conception of the speed of public-key crypto is warped by how slow SSL is; 256 bit elliptic curve crypto, which hasn't degraded in security for almost 25 years, is so fast that you can rekey 10 million sessions every 10 minutes on standard PC hardware.
This argument implies ECC and SSL are mutually exclusive when they aren't. ECC has been a standardized part of SSL for years and there are many shipping implementations. The same thing stopping ECC in SSL from being deployed is what would stop DJB's ECC-hard-coded protocol from being deployed.
I guess DJB still wants to use Curve25519, but nobody has taken any steps to make Curve25519 actually implementable by mainstream software vendors. The first necessary step is to get it approved by NIST. A second necessary step would be to get IANA identifiers reserved for its use in TLS and other protocols. The third necessary step would be for his claims about the un-patented-ness of the curves verified in a way that venders can rely on. A nice fourth step would be to have it endorsed by the NSA like the Suite B curves. IIRC, this would require some standards to slightly weaken their minimum requirements of 256-bit curves to allow this not-quite-256-bit curve.
> * That being the case, there's no excuse not to bake fast modern crypto into HTTP so that it's simply always there; Bernstein has created a TCP-friendly alternate transport protocol that does exactly this.
Lots of people are working on doing this using existing standards like DNSSEC, TLS, and (maybe) X.509 already. Minimal extensions of these existing standards are going to win unless they are shown to be unworkable or unless some other protocol is soon shown to be obviously overwhelmingly better.
> [B]ake public keys directly into URLs or hostnames ("nym-based security"), use CNAMEs and aliases to make things more user-friendly, and secure the end-user connections to the DNS.
I wonder how this would work in the real world when keys are rotated and/or revoked.
- tptacek 16y agoNIST reviews! Official IANA identifiers for TLS! A prove-the-negative patent resolution! And, it'd sure be nice if the NSA came out and endorsed the solution! Yeah, this is definitely an apples to apples standard compared to what DNSSEC dealt with. I am, for the record, (a) a proponent of x509 and (in particular) TLS, (b) not a particular fan of "nym security", (c) not optimistic about any ground-up replacement of TCP. It's weird that you're arguing with me about this stuff. But he's straight-up right about DNS security.
- briansmith 16y agoI'm not arguing with you (aren't you just summarizing somebody else's viewpoint?). I think it's important to see the non-technical factors that may cause a new scheme to lose out to even technically-inferior alternatives. How much value is there in a NIST or NSA rubber stamp? Well, so far MS and Mozilla have only implemented Suite B curves. How hurtful is the ECC patent FUD? Well, look at how much work Red Hat did to strip all ECC code from all the software they ship in their products. How likely is it that there will be a standard that takes off without being distributed by either Microsoft or Red Hat (or Oracle or CentOS)? What would it take to get Curve25519 used in Firefox? Well, there's not much reward for implementing a curve that isn't going to be implemented by many other browsers or servers, so it's hard to justify spending time to consider it, even ignoring the NIST/NSA/IETF/IANA angle.
- tptacek 16y agoI think there's zero chance any of this stuff ever gets deployed, for whatever that's worth. I think that, and that Bernstein is probably right.
- shotgun 16y agoJust curious: what troubles you about nym security?