DNSCurve: Usable security for DNS 

Cryptography in DNSCurveThe DNSCurve project adds linklevel publickey protection to DNS packets. This page discusses the cryptographic tools used in DNSCurve.Ellipticcurve cryptographyDNSCurve uses ellipticcurve cryptography, not RSA.RSA is somewhat older than ellipticcurve cryptography: RSA was introduced in 1977, while ellipticcurve cryptography was introduced in 1985. However, RSA has shown many more weaknesses than ellipticcurve cryptography. RSA's effective security level was dramatically reduced by the linear sieve in the late 1970s, by the quadratic sieve and ECM in the 1980s, and by the numberfield sieve in the 1990s. For comparison, a few attacks have been developed against some rare elliptic curves having special algebraic structures, and the amount of computer power available to attackers has predictably increased, but typical elliptic curves require just as much computer power to break today as they required twenty years ago. IEEE P1363 standardized ellipticcurve cryptography in the late 1990s, including a stringent list of security criteria for elliptic curves. NIST used the IEEE P1363 criteria to select fifteen specific elliptic curves at five different security levels. In 2005, NSA issued a new "Suite B" standard, recommending the NIST elliptic curves (at two specific security levels) for all publickey cryptography and withdrawing previous recommendations of RSA. Some specific types of ellipticcurve cryptography are patented, but DNSCurve does not use any of those types of ellipticcurve cryptography. Curve25519DNSCurve uses a particular elliptic curve, Curve25519, introduced in the following paper: Daniel J. Bernstein, "Curve25519: new Diffie–Hellman speed records," pages 207–228 in Proceedings of PKC 2006, edited by Moti Yung, Yevgeniy Dodis, Aggelos Kiayias, and Tal Malkin, Lecture Notes in Computer Science 3958, Springer, 2006, ISBN 3540338519.This elliptic curve follows all of the standard IEEE P1363 security criteria. It also follows new recommendations that achieve "sidechannel immunity" and "twist security" while improving speed. What this means is that secure implementations of Curve25519 are considerably simpler and faster than secure implementations of (e.g.) NIST P256; there are fewer opportunities for implementors to make mistakes that compromise security, and mistakes are more easily caught by reviewers. An attacker who spends a billion dollars on specialpurpose chips to attack Curve25519, using the best attacks available today, has about 1 chance in 1000000000000000000000000000 of breaking Curve25519 after a year of computation. One could achieve similar levels of security with 3000bit RSA, but encryption and authentication with 3000bit RSA are not nearly fast enough to handle modern DNS loads and would require much more space in DNS packets. Twokey communicationAll DNSCurve communications are between two public keys. When a DNSCurve cache sends a packet to a DNSCurve server, it encrypts and authenticates the packet from its own public key to the server's public key. Similarly, when the server sends a packet back to the cache, it encrypts and authenticates the packet from the server's public key to the cache's public key.Specifically, let's say the cache's longterm secret key is c and the server's longterm secret key is s. The cache's longterm public key is then Curve25519(c), and the server's longterm public key is Curve25519(s). The cache and the server both compute a shared secret Curve25519(cs), and then use fast secretkey cryptographic mechanisms to encrypt and authenticate data. DNSCurve does not use signatures broadcast from one public key. Signatures might seem to be an adequate substitute for twokey protection when confidentiality is not required, and they would allow an important speedup: the server, after computing a signature once, can reuse the signature for any number of clients. However, DNSCurve allows two speedups that turn out to be even more important:
VersionThis is version 2009.06.26 of the crypto.html web page. 