So a vendor/service provider makes a custom proxy for DNS record encryption and breaks the first rule of cryptography. Granted, they're basing it on DNSCurve so at least a few other people have looked at the design, but the implementation is custom... I wouldn't touch this with a 50 foot pole until a dozen PhDs vet it.
edit I didn't notice libnacl is provided, so I assume a good chunk of the crypto work is done by this. My comments were probably too harsh. But I would still like to see a professional look over the rest of their code to make sure there's no glaring problems.
Try reading the description of the crypto, it might make you feel better: http://dnscurve.org/crypto.html Basically it follows NSA recommendations for public-key crypto and uses an algorithm developed by Daniel J. Bernstein which adds even more guarantees. So it's not like they're starting from scratch here.
The problem isn't whether or not they're using a strong crypto algorithm as much as who implemented it and whether there was intense peer-review or not. Anybody can try to implement an algorithm, but most will probably screw something up, which is [one part of] why the first rule of cryptography is: don't do your own cryptography.
Luckily, the library they're using (NaCl) is part of a project led by djb, thus we can assume it's going to be competently written and reviewed by him. I hadn't seen this so this makes me feel better about the crypto part of their project.
You are confused. They didn't invent a new cryptographic system, just implemented it. Just in the same way Internet Explorer didn't invent SSL, they just dropped in a library.
The crypto under the hood is Curve25519. http://cr.yp.to/ecdh.html
I haven't looked at the source, but the most likely library for them to use (curve25519-donna) was written by the guy who does crypto for Chrome.
Thanks for pointing this out, I didn't see NaCl and who it was written by; I thought maybe they wrote their own version of Curve25519. I'm still wary of the implementation until an expert looks over it, though.
Just so you know, there are very, very few experts competent to evaluate the DNSCurve cryptosystem.
Since DNSCrypt relies on a proxy written in C, you'd want that reviewed, and can hope for a "looks clean" from the usual vulnerability research suspects. But you should understand that the people who submit Metasploit modules and the people who do real cryptosystem review are for the most part disjoint sets.
Yes, this is part of why I reacted the way I did. I'm looking for an 'expert' to review it, not an average infosec nerd who groks C. I just wish my friends who did crypto knew how to program =(
That would be the "don't bother encrypting that which is not authenticated"? ISTR a free DNS resolver company (I think it was OpenDNS) doing a MitM on my friend's Google searches when he used them.
Or are you just against anyone deploying new crypto protocols?
They hear it because it's really, really hard to do good crypto. As a rather impressive example, nearly all of the submissions to the NIST's SHA-3 hash competition have holes in them. https://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo These are big names and serious, multi-year projects, and they still fail. Bruce Schneier's "skein" hash is one of the few that haven't been cracked (yet).
Yes, and Rivest's MD-6 dropped out at the first round and DJ Bernstein's (HINT HINT) CubeHash algorithm on the second round of the SHA-3 competition.
But if you don't see the difference between inventing a new cryptographic hash function to improve on SHA-2 and what OpenDNS is doing with DNS then you ought not pass judgment on everyone who attempts to add some useful security where there is none at all now.
Actually, Daniel Bernstein is far more likely to come up with a new secure hash core that withstands real world attacks than anyone is to come up with a new crypto protocol that will survive adversaries. TLS had the best peer review any publicly known crypto system ever got, and it's been a litany of failures.
But this DNSCrypt proposal is specifically claiming to be a "slight variation" on DJB's DNSCurve protocol and curve25519. It uses his NaCl library for implementation too.
But looking at the DNSCrypt code on github, there's no indication of who actually wrote it. It has no attribution, no source code comments. Haven't found a protocol document either.
The author(s) were certainly meticulous though. The #includes are categorized according to their standardization origin (posix, C, internal) and alphabetized within those categories.
I'm not actually sticking up for DNSCrypt; they reached out to me awhile ago but I kind of stiffed them for review time --- it's been an especially busy month.
Yeah. I'm not one thing or another on it yet either. It's just kind of like a spaceship lands from planet OpenDNS and a CDROM rolled out containing the source for a new OpenBSD daemon (without the horns).
And you may be right about (DJB circa 2011) developing a new secure hash function more reliably than a new protocol if you take away the requirement that it also perform significantly better than SHA-2.
In general, unencrypted traffic of any kind can have advantages over badly encrypted traffic: at least you know the unencrypted traffic has no security, and you can treat it accordingly. Badly encrypted traffic gives a false sense of security.
It's actually a pretty reasonable way to read it (it's the way I read it as well). You are obviously using DNS now, and since almost all DNS traffic today is unencrypted, it is a reason assumption to believe your traffic is currently unencrypted†.
However, since you won't touch OpenDNS' encrypted DNS, the only logical reason for that is you feel unreviewed, encrypted DNS is more risky than the current unencrypted DNS.
† That assumption is where things may break down, of course. If you are already using DNSSec, then the reading becomes "I trust DNSSec more than OpenDNS' unreviewed client."
This 'logical conclusion' assumes I would make a comparison between two completely different use cases: wanting to encrypt my dns traffic and not wanting to encrypt my dns traffic. Saying one is better than the other is stupid because they're completely different things.
edit I didn't notice libnacl is provided, so I assume a good chunk of the crypto work is done by this. My comments were probably too harsh. But I would still like to see a professional look over the rest of their code to make sure there's no glaring problems.