BSD insists on putting ``ports'' under/usr/local, while Linux insists on not using/usr/local for anything that comes with the system. Both approaches produce failures for the users: programs not starting, for example. More importantly, the lack of cross-platform compatibility imposes tremendous costs on the UNIX community.
Poly1305-AES
on
SHA-1 Broken
·
· Score: 5, Informative
For people interested in secret-key message authentication: There are authenticators that are (1) much faster than HMAC-SHA-1 and (2) guaranteed to be as secure as AES. In particular, check out Poly1305-AES. Public-domain Poly1305-AES software is now online, though it isn't nicely packaged yet; if you're interested in further announcements, join the Poly1305 mailing list.
(This is not meant as a comment on the security of HMAC-SHA-1.)
``Let everything break, and when it goes live, disallow any characters that are 'risky' ''---No, you have the situation completely backwards. My IDNC3 proposal would never have allowed registration of any characters in domain names except characters specifically designated as being safe. If you read the discussion of six design issues in my original proposal then you'll see this important prohibition emphasized in four of them. The security problem that Firefox is now dealing with is one of those four issues.
Incidentally, there's no obstacle to Firefox adding IDNC3 support. If the user types a non-ASCII URL, Firefox can't simultaneously treat it as both broken-IDN and IDNC3, but the whole discussion here is prompted by Firefox turning off broken-IDN by default.
``He goes to St Petersburg and complains about the hotel''---C'mon, that's hardly a fair summary. You could at least mention the part where they pumped poison gas into my hotel room.
When I bought my Thinkpad T40 many months ago, I chose a Cisco internal (mini-PCI) wireless card instead of the Intel internal wireless card. FreeBSD already included a driver for the Cisco card. The driver worked perfectly.
Sure, this substitution means that the T40 is not officially a Centrino, but who cares? The OS uses the two antennas built into the laptop; it doesn't need a PCMCIA wireless card; it simply works.
The crucial question in most First Amendment cases is whether the government's regulation is based on content. A law usually survives First Amendment scrutiny if the burdens that it imposes on communication don't depend on the content of the communication.
DMCA targets instructions with certain effects---i.e., instructions with certain content. Unfortunately, EFF failed to emphasize this crucial point in their briefs. The Second Circuit started from the (ludicrous) idea that DMCA wasn't based on content, and easily concluded that DMCA was constitutional.
This issue didn't matter for my case because ITAR was a ``prior restraint'' law. As an extreme example, imagine a law that says ``Before publishing any book, you must send the book to the mayor for approval.'' The law is, on its face, content-neutral, but it gives the mayor power to make decisions based on content, so it's unconstitutional. This is an issue of procedures: basically, the only government officials permitted to evaluate content on a case-by-case basis are judges.
The only way the government could have escaped from this was by pushing the (ludicrous) idea that publishing instructions isn't an example of communication. They tried, and failed.
Actually, DNS updates for newly misspelled names are immediate. Your ISP's DNS cache will remember information about old names for a little while, but for new misspellings it immediately contacts VeriSign's.com servers.
The reason that people are seeing inconsistent results is that the servers themselves are inconsistent. VeriSign has put the wildcard on four servers (so far) while leaving it off the other nine.
Requests for unknown.com names are handled by VeriSign's thirteen.com servers. As of 2003.09.16 01:35 UTC, the wildcard is on only four of those servers. So you may or may not see it; there's no guarantee that your ISP's DNS cache will contact a particular server.
Presumably VeriSign will copy the wildcard to the other servers at some point. I wouldn't be surprised if they're ramping up slowly, monitoring the load as they expand the wildcard coverage.
Evidently it didn't ``configure itself'': you had to manually type various extra commands. Of course, servers on the same machine still aren't reachable through IPv6. Let's also ignore the steps that you took to manually configure the router.
This lack of automation is a huge obstacle to IPv6 deployment. How are you going to convince millions of users to configure IPv6 on their machines? It doesn't give them access to any new web pages, or let them talk to additional customers, or save time, or provide any other apparent benefits. So why should they bother?
It didn't have to be this way. All of the configuration difficulties come from a single mistake in the IPv6 addressing architecture. See cr.yp.to/djbdns/ipv6mess.html.
Speaking as a mathematician who was around MSRI 1991-1995, 2000, and 2002-2003: We say ``misery'' because that's the easiest way to pronounce MSRI, not to express any negative sentiments towards the place. When Bill Thurston took over as director in the early 1990s, he tried to get everyone to switch to a French-style ``emissary,'' but that word just isn't as easy to say as ``misery.''
You think dnscache is vulnerable to this attack? Try it! Fact: You won't be able to consume a noticeable amount of CPU time per hash lookup.
Exercise: How did Bernstein manage to publish code in 1999 that defends itself against an attack announced in 2003? Choose one of the following answers:
The part of Bernstein's code that mentioned ``hash flooding'' actually had something to do with illegal drugs. It stops this new attack purely by accident.
Bernstein doesn't know anything about computer security, but he's mastered time travel.
Local IPv6 addresses don't offer any advantages over 10.* IPv4 addresses.
Global IPv6 addresses don't work. Most client computers around the Internet can't talk to a server on a global IPv6 address, and most server computers around the Internet can't talk to a client on a global IPv6 address. Sure, a few people could connect to my IPv6 addresses; so what? Why should I go to extra effort to make those addresses work?
All the operating systems I use have been claiming ``IPv6 support'' for years. But they still require manual action by the system administrator before they can talk to IPv6 addresses. What do I gain by spending time setting up IPv6?
(All of this boils down to a small protocol design error in IPv6. A small change to IPv6 software would make IPv6 addresses work without any administrator action. I have a web page, http://cr.yp.to/djbdns/ipv6mess.html, explaining this in much more detail.)
You say that it wasn't easy to get daemontools working. Did you follow the official installation instructions in cr.yp.to/daemontools/install.html? If not, why not? If you did, what went wrong?
I also don't understand your comment about having to ``learn'' daemontools. There aren't any decisions to make, and you aren't expected to read any of the daemontools documentation before using djbdns. All you have to do is install the programs so that djbdns can use them.
claims, incorrectly, that scp et al. are proprietary;
claims, incorrectly, that TSIG is ``compatible'' and IPSEC isn't; and
says that some of the disadvantages of zone transfers aren't issues for him, as if this meant that they don't matter to anybody.
Lesson for software authors: If you want to see what features are important, watch people actually using the computer, not people speculating about how other people use the computer. Typical speculation doesn't have much to do with reality.
Rick Moen is an idiot. He claims that, if an MTA tries to reach all the relevant DNS servers, and none of them respond, the MTA bounces the message instead of trying again later. He then makes the same claim with ``SMTP servers'' in place of ``DNS servers.'' Not only are both claims factually incorrect, but both claims are, on their face, patently absurd.
Think about it: what would happen to one of those message transfer agents if its own network connection failed? Answer: It would bounce every message in the queue! People who claim that it's a disaster for servers to be reachable less than 100.0000000000% of the time are forgetting that client connections are nowhere near that level of reliability.
This is just one of the issues discussed in my cost-benefit analysis of third-party DNS servers. Note that my page doesn't say that third-party DNS servers are always bad; it analyzes the costs and benefits in detail, so you can see whether you're in the rare situation where the benefits outweigh the costs.
Moen is also completely incorrect when he claims that my web page ``argues against the very notion of backup nameservers.'' On the contrary. The page clearly states, both in its title and in its introduction, that it is discussing the costs and benefits of third-party DNS servers.
In contrast, backup DNS servers are useful at many sites, just like backup HTTP servers, and my documentation specifically recommends DNS service replication at large sites. If your company has identical HTTP servers in New York and Paris, obviously you should put identical DNS servers at the same locations.
``Support zone transfers rather than telling to go away and rsync your gibberish-zone-files behind the scenes.'' djbdns supports zone transfers. They aren't recommended, because they're obsolete, but if you need them to talk to third-party servers then you can use them.
``Have zone files which someone might be able to read and make any sense of.'' No sane human-interface designer would choose BIND's
4.3.2.1.in-addr.arpa. 86400 IN PTR lion.heaven.af.mil.
lion.heaven.af.mil. 86400 IN A 1.2.3.4
(even worse, in two separate files!) over the tinydns-data equivalent:
=lion.heaven.af.mil:1.2.3.4
See the upgrade-from-BIND page, under Administration, for a list of ten time-saving features in the data format.
Even more important is that the data format is easy for programs to read and write. There are tinydns management tools supporting several different administrative tastes: MySQL, LDAP, a web interface, etc. Development of these tools was faster for tinydns than for BIND, and will remain faster, because I'm not throwing artificial barriers in the way of implementors.
www.lycos.com is the web server. The DNS servers are running djbdns. You're also wrong when you claim that this endorsement was ``tacit''; the administrator sent a testimonial to the mailing list three months ago.
NOTIFY is an optional standard. I don't support it because I have better tools for the same thing. RTFM.
Similarly, TSIG is an optional standard. I don't support it because I have better tools for the same thing: for example, IPSEC and ssh.
As for DNSSEC, the protocol isn't even finished, let alone required. Basic features are still in flux, and the system won't work without a centralized key-management system that doesn't exist.
``On how many billion-query nameservers does DJBDNS run? How many mission-critical servers run DJBDNS?'' Are Lycos and Citysearch big enough for you? How about Namezero, the largest domain-hosting company on the Internet?
``How many root nameservers run DJBDNS?'' None at the moment. Of course, none of them run BIND 9 either.
Funny how the BIND proponents say that BIND 8 and BIND 9 are completely different products when we're talking about security, but then suddenly forget the version number when we're talking about deployment.
Rick Moen is an idiot. See an attorney's summary of Aymes v. Bonelli, 47 F.3d 23 (2d Cir. 1995), or the case itself, for an example of your right to modify copies of software that you own.
Moen's source John Cowan is correct about one thing: namely, CONTU said that users ``should'' have modification rights, not that they ``do'' have modification rights. What Cowan and Moen fail to understand is that (1) CONTU was giving recommendations to Congress regarding changes to copyright law and (2) except for something that isn't relevant here, Congress followed those recommendations.
Cowan says that ``there is no evidence that the right... was in fact added'' to copyright law. In fact, the evidence is overwhelming. (Cowan logic: if Cowan hasn't seen the evidence, the evidence must not exist.)
Cowan says that my quote from CONTU is ``misleadingly selective,'' and that my ``claim that private modifications are allowed'' is not ``credible.'' In fact, modifications are allowed. (Cowan logic: if there isn't evidence that he's wrong, then he must be right.)
Moen says that Cowan ``furnished a more-complete quotation,'' finding that it ``contradicts'' my summary and that my quote was ``distortively selective.'' In fact, my comments are entirely consistent with the CONTU report. (Moen logic: If Cowan puts the most words in quotes, Cowan must be right.)
Moen says that Cowan ``convincingly disputed'' my summary. And so on ad nauseam. It's rather amazing how tall a tower of stupidity can be built on a foundation of ignorance.
``I tried djbdns, and it simply did not have the functionality I needed for my application. (mainly, multiple DNS views)''
djbdns has supported client differentiation since January 2001, version 1.04.
For comparison, BIND 9.0.0 was released in September 2000. It was practically unusable. The BIND company now says that BIND 9.0.0 had more than six hundred bugs, many of them quite serious.
Are you saying that you tried djbdns two years ago, had to use BIND 9's ``views'' instead, managed to survive BIND 9's bugs, and haven't looked at djbdns since? If so, take another look. Client differentiation is substantially easier with djbdns than with BIND 9.
Or are you saying that you tried djbdns more recently, and somehow acquired the false impression that it doesn't support client differentiation? If so, how did you acquire that impression? Is there something in the documentation that could be improved?
Not everyone has heard that I'm still challenging the export regulations under the First Amendment. The next round of oral argument is scheduled for Friday 18 October 2002 in San Francisco.
See export.cr.yp.to for the case status, mailing-list information, background documents, where to send descriptions of your experiences, etc.
Conventional NFS implementations (and TWINKLE), as described in (for example) Silverman's cost-analysis paper or the Lenstra-Shamir TWINKLE paper, take time L^(1.901...+o(1)) on a machine of size L^(0.950...+o(1)), exactly as stated in my paper.
One can, of course, trade time for hardware cost. For example, one can carry out the same computation in time L^(1.711..+o(1)) on a machine of size L^(1.140...+o(1)).
My NFS circuits take time L^(1.185...+o(1)) on a machine of size L^(0.790...+o(1)), exactly as stated in my paper.
The exponent ratio 1.443...+o(1) corresponds to multiplying the number of input digits by 3.009...+o(1).
Carl Pomerance has pointed out that a slightly different conventional NFS implementation takes time L^(1.754...+o(1)) on a machine of size L^(1.006...+o(1)), or time L^(1.656...+o(1)) on a machine of size L^(1.104...+o(1)), but this is still vastly less cost-effective than a circuit for large numbers. The NFS cost ratio between conventional computers and circuits grows as a quite noticeable power of the cost itself.
There are two basic reasons for this improvement. First, for large numbers, using conventional computers (or TWINKLE) for NFS sieving is a bad idea, because the low-memory smoothness-testing circuits described in my paper are much more cost-effective. Second, for large numbers, using conventional computers for NFS linear algebra is a bad idea, because the linear-algebra circuits described in my paper are much more cost-effective.
3 versus 1.17: why there is a dispute. This Lenstra-Shamir-Tomlinson-Tromer paper observes, correctly, that reasonably fast low-memory smoothness-testing techniques have been known for decades. (Of course, my paper says the same thing.)
The Lenstra-Shamir-Tomlinson-Tromer paper then leaps to the incorrect conclusion that the cost-effectiveness of those techniques for large numbers was widely known before my paper.
If this fact was known before, why didn't it appear in the aforementioned Silverman and Lenstra-Shamir papers two years ago? Both of those papers were discussing the cost of state-of-the-art integer factorization.
As for the Coppersmith paper cited by Lenstra et al.: As mentioned in my paper, Coppersmith suggested ECM in a context where RAM sieving would have meant looking at many more numbers. He didn't observe that ECM was better than RAM sieving in other contexts. In fact, for the first step of his algorithm, he specifically suggested RAM sieving!
The simple fact is that papers before mine optimized their machines purely for operation count. The resulting machines are far less cost-effective than the circuits described in my paper.
The Lenstra-Shamir-Tomlinson-Tromer paper does not claim that circuits are less cost-effective (slower or larger) than stated in my paper. It also does not claim that conventional implementations are competitive. It does not claim that circuits are actually not so scary. What it claims is that we already had fairly scary circuits. This is revisionist history, not a technical dispute.
Simple versus optimized. My paper is a grant proposal. It explains a very simple circuit, enough to prove the L^(1.185...+o(1)),L^(0.790...+o(1)) result. It then briefly points out several ways that the circuit can be changed and improved. The objective of the grant is to find the most cost-effective circuit. The simplest circuit is certainly not the best one; finding the best one is a huge project.
Treating the simplest algorithm as if it were my final result, with every trivial improvement worth pointing out, is a serious misrepresentation of my work.
In particular, the use of mesh routing in this context is one of many obvious possibilities, and is already mentioned in my paper as an alternative to mesh sorting. Lenstra et al. claim that this is an ``improvement'' over my paper; that claim is false.
I described a counterclockwise mesh routing algorithm in an email message to one of those authors in mid-April, as part of explaining why conventional implementations aren't cost-effective. (On a 20x20 mesh: ``Take a batch of, say, 1000 hits generated by each processor; route the hits 19 steps down, then 19 steps right, then 19 steps up, then 19 steps left, to reach the proper memory locations.... The point is that the time ratio grows linearly with the 20, while the cost ratio is simply 1 plus overhead. The overhead can be dramatically reduced with special-purpose circuitry, allowing the 20 to be raised by half as many orders of magnitude.'')
I am astonished that anyone would publish this obvious use of mesh routing as if it were an interesting new result.
The balance between sieving and linear algebra. There are many parameters in NFS: dials that can be adjusted to affect the speed of the algorithm in complicated ways. The most important parameter is the ``prime bound,'' usually called y.
As y increases from ``tiny'' to ``standard,'' the cost of sieving drops down to a smallest possible value, while the cost of linear algebra rises. As y increases past standard, the cost of sieving starts rising again, and keeps rising, while the cost of linear algebra also rises.
In the context of TWINKLE, Lenstra and Shamir claimed that sieving speedups had limited value, because linear algebra by itself was a bottleneck. That claim is obviously false: one can always decrease y to reduce the cost of linear algebra until sieving and linear algebra are in balance.
The Lenstra-Shamir-Tomlinson-Tromer paper now makes the opposite claim, that linear-algebra speedups have limited value, because sieving by itself is a bottleneck. That claim is also false, at least for large numbers: the optimal value of y is substantially smaller than standard, as stated in my paper, so one can increase y to reduce the cost of sieving until sieving and linear algebra are in balance.
Perhaps someday we'll discover better linear-algebra methods. Perhaps the cost of linear algebra will become unnoticeable for standard values of y; then sieving by itself will be a bottleneck. However, as stated in my paper, the current situation for large numbers is that linear algebra is relatively difficult; as a consequence, when parameters are chosen properly, sieving and linear algebra are in balance.
Large numbers versus small numbers, and the cost of sieving. Figuring out that one NFS approach is much better than another for large numbers is much easier than figuring out the situation for small numbers, such as 1024 bits or 1536 bits.
Analogy: It's easy to prove that merge sorting is much faster than insertion sorting for large arrays. You don't have to worry about all the different variations of the sorting algorithms; these changes can make big differences in speed, but those differences are unnoticeable next to the gigantic speed gap between merge sorting and insertion sorting for large arrays. It's much more difficult to figure out the fastest method for small arrays, such as arrays of size 16.
The Lenstra-Shamir-Tomlinson-Tromer paper has one paragraph (Section 5.2) on the cost of sieving for a specific input size, namely 1024 bits. That paragraph estimates that RAM sieving would take about a year on 30 million large-memory PCs. It implicitly assumes that conventional RAM sieving is the most cost-effective approach to sieving for 1024-bit numbers. In particular, it implicitly assumes that circuits (mesh sorting, mesh routing, early-abort Pollard+ECM, etc.; see my paper) wouldn't be much less expensive. It concludes that sieving by itself is a bottleneck for 1024-bit numbers.
There is no justification for these assumptions and conclusions. The authors claim to understand, and to have understood for a decade, that conventional RAM sieving is much less cost-effective than circuits for large numbers; however, when faced with 1024-bit numbers, they don't even consider the possibility of 1024 being large and of conventional RAM sieving being the wrong approach. This is a gaping hole in the Lenstra-Shamir-Tomlinson-Tromer analysis.
Maybe special-purpose circuits will have a dramatic impact on the difficulty of 1024-bit and 1536-bit and 2048-bit factorizations. Maybe they'll have no impact at all. I don't know yet. I do know that ignoring the question doesn't help us find the answer.
Slashdot Mirror
BSD insists on putting ``ports'' under /usr/local, while Linux insists on not using /usr/local for anything that comes with the system. Both approaches produce failures for the users: programs not starting, for example. More importantly, the lack of cross-platform compatibility imposes tremendous costs on the UNIX community.
(This is not meant as a comment on the security of HMAC-SHA-1.)
Incidentally, there's no obstacle to Firefox adding IDNC3 support. If the user types a non-ASCII URL, Firefox can't simultaneously treat it as both broken-IDN and IDNC3, but the whole discussion here is prompted by Firefox turning off broken-IDN by default.
The big advantage of kqueue is its speed at handling many simultaneous descriptors.
``He goes to St Petersburg and complains about the hotel''---C'mon, that's hardly a fair summary. You could at least mention the part where they pumped poison gas into my hotel room.
Sure, this substitution means that the T40 is not officially a Centrino, but who cares? The OS uses the two antennas built into the laptop; it doesn't need a PCMCIA wireless card; it simply works.
DMCA targets instructions with certain effects---i.e., instructions with certain content. Unfortunately, EFF failed to emphasize this crucial point in their briefs. The Second Circuit started from the (ludicrous) idea that DMCA wasn't based on content, and easily concluded that DMCA was constitutional.
This issue didn't matter for my case because ITAR was a ``prior restraint'' law. As an extreme example, imagine a law that says ``Before publishing any book, you must send the book to the mayor for approval.'' The law is, on its face, content-neutral, but it gives the mayor power to make decisions based on content, so it's unconstitutional. This is an issue of procedures: basically, the only government officials permitted to evaluate content on a case-by-case basis are judges.
The only way the government could have escaped from this was by pushing the (ludicrous) idea that publishing instructions isn't an example of communication. They tried, and failed.
The case archive is now http://export.cr.yp.to. That archive has about 200 of the case documents; the old EFF archive has only about 100.
The reason that people are seeing inconsistent results is that the servers themselves are inconsistent. VeriSign has put the wildcard on four servers (so far) while leaving it off the other nine.
Presumably VeriSign will copy the wildcard to the other servers at some point. I wouldn't be surprised if they're ramping up slowly, monitoring the load as they expand the wildcard coverage.
This lack of automation is a huge obstacle to IPv6 deployment. How are you going to convince millions of users to configure IPv6 on their machines? It doesn't give them access to any new web pages, or let them talk to additional customers, or save time, or provide any other apparent benefits. So why should they bother?
It didn't have to be this way. All of the configuration difficulties come from a single mistake in the IPv6 addressing architecture. See cr.yp.to/djbdns/ipv6mess.html.
Speaking as a mathematician who was around MSRI 1991-1995, 2000, and 2002-2003: We say ``misery'' because that's the easiest way to pronounce MSRI, not to express any negative sentiments towards the place. When Bill Thurston took over as director in the early 1990s, he tried to get everyone to switch to a French-style ``emissary,'' but that word just isn't as easy to say as ``misery.''
Exercise: How did Bernstein manage to publish code in 1999 that defends itself against an attack announced in 2003? Choose one of the following answers:
- The part of Bernstein's code that mentioned ``hash flooding'' actually had something to do with illegal drugs. It stops this new attack purely by accident.
- Bernstein doesn't know anything about computer security, but he's mastered time travel.
- This attack isn't new.
You have five seconds to reply.Local IPv6 addresses don't offer any advantages over 10.* IPv4 addresses.
Global IPv6 addresses don't work. Most client computers around the Internet can't talk to a server on a global IPv6 address, and most server computers around the Internet can't talk to a client on a global IPv6 address. Sure, a few people could connect to my IPv6 addresses; so what? Why should I go to extra effort to make those addresses work?
All the operating systems I use have been claiming ``IPv6 support'' for years. But they still require manual action by the system administrator before they can talk to IPv6 addresses. What do I gain by spending time setting up IPv6?
(All of this boils down to a small protocol design error in IPv6. A small change to IPv6 software would make IPv6 addresses work without any administrator action. I have a web page, http://cr.yp.to/djbdns/ipv6mess.html, explaining this in much more detail.)
I also don't understand your comment about having to ``learn'' daemontools. There aren't any decisions to make, and you aren't expected to read any of the daemontools documentation before using djbdns. All you have to do is install the programs so that djbdns can use them.
Wdomburg
Lesson for software authors: If you want to see what features are important, watch people actually using the computer, not people speculating about how other people use the computer. Typical speculation doesn't have much to do with reality.
Think about it: what would happen to one of those message transfer agents if its own network connection failed? Answer: It would bounce every message in the queue! People who claim that it's a disaster for servers to be reachable less than 100.0000000000% of the time are forgetting that client connections are nowhere near that level of reliability.
This is just one of the issues discussed in my cost-benefit analysis of third-party DNS servers. Note that my page doesn't say that third-party DNS servers are always bad; it analyzes the costs and benefits in detail, so you can see whether you're in the rare situation where the benefits outweigh the costs.
Moen is also completely incorrect when he claims that my web page ``argues against the very notion of backup nameservers.'' On the contrary. The page clearly states, both in its title and in its introduction, that it is discussing the costs and benefits of third-party DNS servers.
In contrast, backup DNS servers are useful at many sites, just like backup HTTP servers, and my documentation specifically recommends DNS service replication at large sites. If your company has identical HTTP servers in New York and Paris, obviously you should put identical DNS servers at the same locations.
``Have zone files which someone might be able to read and make any sense of.'' No sane human-interface designer would choose BIND's
4.3.2.1.in-addr.arpa. 86400 IN PTR lion.heaven.af.mil.
lion.heaven.af.mil. 86400 IN A 1.2.3.4
(even worse, in two separate files!) over the tinydns-data equivalent:
=lion.heaven.af.mil:1.2.3.4
See the upgrade-from-BIND page, under Administration, for a list of ten time-saving features in the data format.
Even more important is that the data format is easy for programs to read and write. There are tinydns management tools supporting several different administrative tastes: MySQL, LDAP, a web interface, etc. Development of these tools was faster for tinydns than for BIND, and will remain faster, because I'm not throwing artificial barriers in the way of implementors.
www.lycos.com is the web server. The DNS servers are running djbdns. You're also wrong when you claim that this endorsement was ``tacit''; the administrator sent a testimonial to the mailing list three months ago.
Similarly, TSIG is an optional standard. I don't support it because I have better tools for the same thing: for example, IPSEC and ssh.
As for DNSSEC, the protocol isn't even finished, let alone required. Basic features are still in flux, and the system won't work without a centralized key-management system that doesn't exist.
``How many root nameservers run DJBDNS?'' None at the moment. Of course, none of them run BIND 9 either.
Funny how the BIND proponents say that BIND 8 and BIND 9 are completely different products when we're talking about security, but then suddenly forget the version number when we're talking about deployment.
Moen's source John Cowan is correct about one thing: namely, CONTU said that users ``should'' have modification rights, not that they ``do'' have modification rights. What Cowan and Moen fail to understand is that (1) CONTU was giving recommendations to Congress regarding changes to copyright law and (2) except for something that isn't relevant here, Congress followed those recommendations.
Cowan says that ``there is no evidence that the right ... was in fact added'' to copyright law. In fact, the evidence is overwhelming. (Cowan logic: if Cowan hasn't seen the evidence, the evidence must not exist.)
Cowan says that my quote from CONTU is ``misleadingly selective,'' and that my ``claim that private modifications are allowed'' is not ``credible.'' In fact, modifications are allowed. (Cowan logic: if there isn't evidence that he's wrong, then he must be right.)
Moen says that Cowan ``furnished a more-complete quotation,'' finding that it ``contradicts'' my summary and that my quote was ``distortively selective.'' In fact, my comments are entirely consistent with the CONTU report. (Moen logic: If Cowan puts the most words in quotes, Cowan must be right.)
Moen says that Cowan ``convincingly disputed'' my summary. And so on ad nauseam. It's rather amazing how tall a tower of stupidity can be built on a foundation of ignorance.
djbdns has supported client differentiation since January 2001, version 1.04.
For comparison, BIND 9.0.0 was released in September 2000. It was practically unusable. The BIND company now says that BIND 9.0.0 had more than six hundred bugs, many of them quite serious.
Are you saying that you tried djbdns two years ago, had to use BIND 9's ``views'' instead, managed to survive BIND 9's bugs, and haven't looked at djbdns since? If so, take another look. Client differentiation is substantially easier with djbdns than with BIND 9.
Or are you saying that you tried djbdns more recently, and somehow acquired the false impression that it doesn't support client differentiation? If so, how did you acquire that impression? Is there something in the documentation that could be improved?
See export.cr.yp.to for the case status, mailing-list information, background documents, where to send descriptions of your experiences, etc.
Background. To review the undisputed facts:
Carl Pomerance has pointed out that a slightly different conventional NFS implementation takes time L^(1.754...+o(1)) on a machine of size L^(1.006...+o(1)), or time L^(1.656...+o(1)) on a machine of size L^(1.104...+o(1)), but this is still vastly less cost-effective than a circuit for large numbers. The NFS cost ratio between conventional computers and circuits grows as a quite noticeable power of the cost itself.
There are two basic reasons for this improvement. First, for large numbers, using conventional computers (or TWINKLE) for NFS sieving is a bad idea, because the low-memory smoothness-testing circuits described in my paper are much more cost-effective. Second, for large numbers, using conventional computers for NFS linear algebra is a bad idea, because the linear-algebra circuits described in my paper are much more cost-effective.
3 versus 1.17: why there is a dispute. This Lenstra-Shamir-Tomlinson-Tromer paper observes, correctly, that reasonably fast low-memory smoothness-testing techniques have been known for decades. (Of course, my paper says the same thing.)
The Lenstra-Shamir-Tomlinson-Tromer paper then leaps to the incorrect conclusion that the cost-effectiveness of those techniques for large numbers was widely known before my paper.
If this fact was known before, why didn't it appear in the aforementioned Silverman and Lenstra-Shamir papers two years ago? Both of those papers were discussing the cost of state-of-the-art integer factorization.
As for the Coppersmith paper cited by Lenstra et al.: As mentioned in my paper, Coppersmith suggested ECM in a context where RAM sieving would have meant looking at many more numbers. He didn't observe that ECM was better than RAM sieving in other contexts. In fact, for the first step of his algorithm, he specifically suggested RAM sieving!
The simple fact is that papers before mine optimized their machines purely for operation count. The resulting machines are far less cost-effective than the circuits described in my paper.
The Lenstra-Shamir-Tomlinson-Tromer paper does not claim that circuits are less cost-effective (slower or larger) than stated in my paper. It also does not claim that conventional implementations are competitive. It does not claim that circuits are actually not so scary. What it claims is that we already had fairly scary circuits. This is revisionist history, not a technical dispute.
Simple versus optimized. My paper is a grant proposal. It explains a very simple circuit, enough to prove the L^(1.185...+o(1)),L^(0.790...+o(1)) result. It then briefly points out several ways that the circuit can be changed and improved. The objective of the grant is to find the most cost-effective circuit. The simplest circuit is certainly not the best one; finding the best one is a huge project.
Treating the simplest algorithm as if it were my final result, with every trivial improvement worth pointing out, is a serious misrepresentation of my work.
In particular, the use of mesh routing in this context is one of many obvious possibilities, and is already mentioned in my paper as an alternative to mesh sorting. Lenstra et al. claim that this is an ``improvement'' over my paper; that claim is false.
I described a counterclockwise mesh routing algorithm in an email message to one of those authors in mid-April, as part of explaining why conventional implementations aren't cost-effective. (On a 20x20 mesh: ``Take a batch of, say, 1000 hits generated by each processor; route the hits 19 steps down, then 19 steps right, then 19 steps up, then 19 steps left, to reach the proper memory locations. ... The point is that the time ratio grows linearly with the 20, while the cost ratio is simply 1 plus overhead. The overhead can be dramatically reduced with special-purpose circuitry, allowing the 20 to be raised by half as many orders of magnitude.'')
I am astonished that anyone would publish this obvious use of mesh routing as if it were an interesting new result.
The balance between sieving and linear algebra. There are many parameters in NFS: dials that can be adjusted to affect the speed of the algorithm in complicated ways. The most important parameter is the ``prime bound,'' usually called y.
As y increases from ``tiny'' to ``standard,'' the cost of sieving drops down to a smallest possible value, while the cost of linear algebra rises. As y increases past standard, the cost of sieving starts rising again, and keeps rising, while the cost of linear algebra also rises.
In the context of TWINKLE, Lenstra and Shamir claimed that sieving speedups had limited value, because linear algebra by itself was a bottleneck. That claim is obviously false: one can always decrease y to reduce the cost of linear algebra until sieving and linear algebra are in balance.
The Lenstra-Shamir-Tomlinson-Tromer paper now makes the opposite claim, that linear-algebra speedups have limited value, because sieving by itself is a bottleneck. That claim is also false, at least for large numbers: the optimal value of y is substantially smaller than standard, as stated in my paper, so one can increase y to reduce the cost of sieving until sieving and linear algebra are in balance.
Perhaps someday we'll discover better linear-algebra methods. Perhaps the cost of linear algebra will become unnoticeable for standard values of y; then sieving by itself will be a bottleneck. However, as stated in my paper, the current situation for large numbers is that linear algebra is relatively difficult; as a consequence, when parameters are chosen properly, sieving and linear algebra are in balance.
Large numbers versus small numbers, and the cost of sieving. Figuring out that one NFS approach is much better than another for large numbers is much easier than figuring out the situation for small numbers, such as 1024 bits or 1536 bits.
Analogy: It's easy to prove that merge sorting is much faster than insertion sorting for large arrays. You don't have to worry about all the different variations of the sorting algorithms; these changes can make big differences in speed, but those differences are unnoticeable next to the gigantic speed gap between merge sorting and insertion sorting for large arrays. It's much more difficult to figure out the fastest method for small arrays, such as arrays of size 16.
The Lenstra-Shamir-Tomlinson-Tromer paper has one paragraph (Section 5.2) on the cost of sieving for a specific input size, namely 1024 bits. That paragraph estimates that RAM sieving would take about a year on 30 million large-memory PCs. It implicitly assumes that conventional RAM sieving is the most cost-effective approach to sieving for 1024-bit numbers. In particular, it implicitly assumes that circuits (mesh sorting, mesh routing, early-abort Pollard+ECM, etc.; see my paper) wouldn't be much less expensive. It concludes that sieving by itself is a bottleneck for 1024-bit numbers.
There is no justification for these assumptions and conclusions. The authors claim to understand, and to have understood for a decade, that conventional RAM sieving is much less cost-effective than circuits for large numbers; however, when faced with 1024-bit numbers, they don't even consider the possibility of 1024 being large and of conventional RAM sieving being the wrong approach. This is a gaping hole in the Lenstra-Shamir-Tomlinson-Tromer analysis.
Maybe special-purpose circuits will have a dramatic impact on the difficulty of 1024-bit and 1536-bit and 2048-bit factorizations. Maybe they'll have no impact at all. I don't know yet. I do know that ignoring the question doesn't help us find the answer.