A list of patches for various name servers can be found here.
Unfortunately the djbdns patch at that URL is not as elegant as the official patch from ISC for BIND. Unlike the ISC BIND patch, the djbdns patch does not support the declaration of "delegation-only" zones. Instead, it adds support for the rather crude technique of converting an A record response containing an operator specified IP address (which you would currently set to 64.94.110.11) into a NXDOMAIN response.
While the Nomad Zen is certainly a nice MP3 player with an excellent set of features, I think it is an exaggeration to say that it is only "slightly larger" than the 30GB iPod. Look at the specs for the 30GB iPod and the Nomad Zen. The Nomad Zen weighs 50% more than the 30GB iPod (268g vs. 176g). The volume of the Nomad Zen is more than 75% larger then the 30GB iPod (209 cm^3 vs. 118 cm^3).
Is the difference all that important? Maybe not, but of the two the Apple iPod is certainly the sleeker, and that will matter to some customers.
With regard to quantum computers, it is my understanding that with suitable modifications, Shor's algorithm can be applied to ECC. It is unclear if quantum computers sufficiently large to attack cryptographic systems are at all feasible, but if they could be built then all of today's popular asymmetric cryptosystems would be insecure. However, I don't expect a quantum computer sufficiently large to attack 163-bit ECC will be built before 163-bit ECC falls to a more conventional attack.
The most efficient method published to attack ECC is Pollard's parallelizable rho method, with an expected run time on order of the square root of q group operations. So, while the run time of an attack against ECC is exponential in the size of q, it doesn't grow as fast as an exhaustive search attack against a symmetric key cryptosystem. As a rule of thumb, an ECC key is approximately as strong as a symmetric key with half as many bits, so a 163-bit ECC key is roughly equivalent to an 80-bit symmetric key.
Since a 163-bit key is 2^54 times more complex than a 109-bit key, and it took 4 years for the 109-bit key, aren't we looking at at least 4 * 2^53 years, not even figuring in the elliptical complexity (which I admit I would need to read up on)?
Recovering a 163-bit ECC key is estimated to require 2^27 times as much effort as a 109-bit ECC key. Current recommendations are that 163-bit ECC keys should be safe to use until 2011, although I don't think we'll see public key-recovery efforts succeed against 163-bit ECC until 2020 or so.
The following is one of the better articles on this subject:
This is particularly true in an environment like the central California valley, where two points of land on either side of a fault line can shift as much as a foot in either direction over the course of a year or so, and that's without an earthquake.
One foot a year is too high. The actual figure for the velocity of deformation near active faults in California is more like 40mm/year. If you are curious, both the Northern California Earthquake Data Center (NCEDC) in Berkeley and the Southern California Earthquake Center (SCEC) in Los Angeles have reports on this subject. Here are two links that might be of interest:
The PanIP Defendants web site mentioned in the article has a list of the 50 companies that have so far been sued by PanIP. Interestingly, despite the large number of e-commerce companies in California, none of the defendants are located in California.
Since the patent holder, PanIP, is located in San Diego the cases are taking place in the U.S. District Court for the Southern District of California. Since all of the companies being targeted are small out-of-state companies they are unlikely to already have an established relationship with an attorney licensed to practice in California. I wonder if PanIP is specifically targeting companies that are not in California, perhaps on the theory that out-of-state companies will be more likely to settle when faced with having to litigate a case far from home?
Somebody go get a bunch of patents on anti-piracy googaws and then claim prior-art on all the companies attempting to put stuff like this in place.
Actually, the cryptographer Lucky Green has already done this with respect to Palladium and software piracy. At a panel on Palladium at the USENIX Security Conference in August the Microsoft Palladium team claimed that Palladium couldn't and thus wouldn't be used to combat software piracy. However, Lucky Green was able to think of several methods to use Palladium / TCPA in the enforcement of software licenses, so in response has applied for patents on all of the methods he could think of in an effort to thwart any such use.
For more information, see the following posts (August 8th and August 10th) to the Cryptography mailing list.
To dissipate the heat, cooling loops will be employed to take heat from the laser system and transfer it into the aircraft's fuel tank, where it can be burned away. ... "If you think about the amount of fuel onboard a jet aircraft, if you put all that heat in the fuel, you might raise it by a degree, something on that order," he said.
Unless, of course, the aircraft has expended 99% of its fuel - in which case the temperature of the remaining 1% of the fuel would raise by 100 degrees. Ouch.
One would think that with all that LEAD lying all over the place, cosmic ray showers wouldn't be such an issue...
While I am sure you meant your comment to be facetious, I felt it deserved a reply due to the assumption that underlies it.
When a cosmic ray hits the atmosphere it produces many secondary particles, it is these particles which cause soft errors in computer memory. For computer memory the worst secondary cosmic rays are the hadrons (protons, neutrons and pions). Neutrons are particularly troublesome since these are responsible for more than half of the terrestrial soft errors. In order to affect the computer memory these neutrons have already had to pass through kilometers of atmosphere, through the building, and through the computer housing - a little lead isn't likely to stop them. In fact, surrounding your computer with lead could even make things worse. Cosmic rays are often counted with a neutron monitor and it is not uncommon for neutron monitors to be deliberately constructed with a lead casing. The lead casing increases the neutron count by producing more neutrons as it is bombarded by cosmic rays.
Radiation(white noise) was always a problem with RAM, much more so at higher elevations(Colorado gets about 100x more ram errors than sealevel does, necessitating ECC ram)
Actually, the increased RAM failure rate due to the greater cosmic ray intensities at higher altitudes isn't as bad as you describe.
For example, the expected soft-fail rate of a computer memory system in Denver, Colorado is about 4 times greater than the rate expected at a city it sea level (such as New York City). Even in Leadville, Colorado (which is located at 10,151 feet) the expected failure rate is only about 13 times greater than in NYC. No location in Colorado even approaches 100x.
For more information, see the following paper:
J. F. Ziegler, "Terrestrial cosmic ray intensities", IBM Journal of Research and Development, Vol. 42, No. 1, 1998.
I read somewhere that if you have a major computational problem ("major" meaning "I'm buying a big honkin' cluster that's going to hammer away at it for years") then the cheapest and fastest way to solve it is to figure out how long it would take a currently available setup to solve the problem, and sit back until at least half that time has elapsed before buying the hardware.
I encourage you to take a look at the following paper:
C. Gottbrath, J. Bailin, C. Meakin, T. Thompson and J. Charfman, "The Effects of Moore's Law and Slacking on Large Computations," manuscript, Astrophysics ePrint archive, 1999.
A PDF or postscript version can be downloaded from here. An HTML version is online here.
While the paper is written more as an exercise in humor than as a serious scientific endeavor, all of the math is correct. The authors calculate that the optimal strategy for quickly finding the solution to large computational problems with a fixed budged is: defer your purchase of a computer until you can purchase a computer that will solve the problem in about 26 months. As a corollary to this, any calculation that currently takes less than 26 months will finish earliest if started immediately.
A driver's license without picture or signature?
on
Distributed Security
·
· Score: 3, Insightful
The article briefly mentions the following:
A few years ago Schneier devoted considerable effort to persuading the State of Illinois to issue him a driver's license that showed no picture, signature, or Social Security number.
I haven't heard that story before. Can somebody point me to a source with more details?
Apple has a policy of NOT paying for product placement. If you want to use their hardware as props, you can buy them at the store like everyone else.
While I don't know if Apple has a policy of not paying for product placement, it certainly is not the case that those who want to use an Apple computer as a movie prop have to buy them from the store like everyone else.
Apple definitely has a product placement program. Read more about it here.
The last time Forgent's patent (actually Concurrent Labs) was discussed, one poster said that he had been involved with JPEG, and Concurrent Labs was a member in 1992-95 (IIRC).
Surely you meant to say Compression Labs, not Concurrent Labs. It was Compression Labs Inc. that was an early member of the Joint Photographic Experts Group ("JPEG").
A Google search on IOkit gave a lot of results, but I had a hard time finding any basic information on what it is. Can you recommend a place to go to find out what it's about?
One of the best starting places for learning about I/O Kit is, unsurprisingly, on Apple's developer web site. Try here.
Well, considering that the PCI bus you're hooking up the GB adaptor to has a 264MBps max throughput (32bit 66MHz on the Mac), factoring in overhead and such, it's not surprising that GigaE runs at 200MBps...
I think you are confusing bytes/second and bits/second. A 32-bit 66MHz PCI bus has a data rate of 266 Megabytes/second, which is more than twice the data rate of Gigabit Ethernet.
Then factor the fact that there are 2 CPUs and two GigaE boards means if they share one PCI bus, then the bottleneck is neither the CPU nor the cards... here's to hoping that each board sits on a separate PCI bus:)
In the Xserve the primary Gigabit Ethernet port is on the logic board and controlled directly by Apple's custom memory controller/north bridge ASIC. It doesn't occupy any expansion slots and doesn't consume any PCI bus bandwidth.
The other Gigabit Ethernet port is on a PCI card that is installed, in the standard configuration, in the Xserve's combination PCI/AGP 4X half-length slot. This bus should have adequate bandwidth for Gigabit Ethernet as no other slots are connected to this bus.
The other two full-length slots are on a different bus. They are served by a single 64-bit 66MHz PCI bus with a data rate of 533 Megabytes/second. In the standard configuration one of these slots is filled by a VGA graphics card. The four ATA/100 busses are connected to this PCI bus, so intensive disk I/O could interfere with the performance of cards in these two slots.
seems rather an inelegant way to make a general proof; general proof for n>=5, the seperate proofs for n=1, n=2, n=3 and n=4. Does this new proof just do n=3, or is it a _nice_ general proof?
M.J.Dunwoody's proof is restricted to the n = 3 case.
...it would boil down to, worst case, factoring n. Which isn't trivial, but the important thing here is that it's constant. One person needs to do it on one machine. Once. Then, you make a wonderful keygen, and it's all over.
If you know of a way to factor the kinds of numbers used in public keys then don't waste your time cracking software registration keys, instead factor the The RSA Challenge Numbers. Not only will RSA Security will award you $635,000 but you will win the acclaim of the cryptographers worldwide!
It is not uncommon to use truncation to transform the output of a Message Authentication Code (MAC) in these circumstances. In fact, Preneel and van Oorschot have found some advantages in truncating the output of a hash-based MAC, although their results do not seem to extend to an overall security advantage for truncation [1]. The advantage stems from the fact that less information on the hash result is available to the attacker, but a disadvantage is that there are less bits for the attacker to predict. If you are going to truncate an n bit hash to m bits then I suggest that m should be not less than half of n. The value of m should also be large enough to be a suitable lower bound on the number of bits that need to be predicted by an attacker. While this lower bound is probably around 80 for most applications, since registration code applications are vulnerable to direct attack on the application you only need it to be stronger than the effort it takes to crack the application. I'd suggest that 64 bit truncation of a 128 bit hash such as MD5 is just fine.
Your guess about Windows Terminal Server is spot on. The article in German mentions that the Philips monitor is based on Microsoft's Mira technology, Mira relies on Microsoft's Terminal Server and Microsoft Terminal Server uses the Remote Desktop Protocol (RDP).
Yes, the monitor communicates with the PC via IEEE 802.11b at 11 Mbits/s. This isn't really adequate for anything that refreshes the screen a lot, especially since I doubt the communications protocol between the monitor and the PC is as high-level as the communication between an X client and an X server.
The philips page here gives more details. I don't know why the Slashdot article links to the Philips home page instead of the Philips page that discusses the monitor.
Consider using the myprivacy.ca whois-harvester-buster. Create a free @myprivacy.ca e-mail address, and then use it in your whois information. If you've registered your domain from (and admittedly small set) of participating ICANN registrars any mail from the registrar will be forwarded to you automatically, but if someone else sends e-mail to the myprivacy.ca e-mail address they have to answer a simple confirmation e-mail before their e-mail will be forwarded to you.
Of course, this doesn't help if the registrar decides to send you spam...
I might point out that the Mac option is dicey anyway -- the prime advantage of a Mac cluster is the weak multitasking in Classic so that you can beat the OS into submission and take over the system with your code.
While you might be correct in general, Apple hardware doesn't always come up short in price/performance ratio. I recently participated in a clustering project in which we did performance testing with several different architectures. Our budget was fixed, but we ended up building the full-scale cluster using Apple machines running MacOS X. We found that we got better bang for our buck using fewer Apple machines rather than more commodity PCs.
However, our situation may have been unique. Our communication bandwidth needs were rather high, so the Apple machines having motherboard gigabit ethernet turned out to be an advantage instead of unnecessarily pulling down their price/performance ratios. Second, for our problem it was possible to utilize the AltiVec vector processor in the G4 PowerPC processor. While the vector execution unit is only 128-bits wide, it was wide enough for our problem and significantly superior to the "vector" units in the Intel and AMD chips.
Slashdot Mirror
- A technical description that sounds like dialog on Star Trek Voyager.
- No phone number anywhere on the batmax.com site.
- The terms & conditions instruct you to send returns to an incomplete address:
- They used an anonymous domain proxy service to register their domain:
Come to your own conclusions.BatMax Corporation
Miami FL
USA
Unfortunately the djbdns patch at that URL is not as elegant as the official patch from ISC for BIND. Unlike the ISC BIND patch, the djbdns patch does not support the declaration of "delegation-only" zones. Instead, it adds support for the rather crude technique of converting an A record response containing an operator specified IP address (which you would currently set to 64.94.110.11) into a NXDOMAIN response.
While the Nomad Zen is certainly a nice MP3 player with an excellent set of features, I think it is an exaggeration to say that it is only "slightly larger" than the 30GB iPod. Look at the specs for the 30GB iPod and the Nomad Zen. The Nomad Zen weighs 50% more than the 30GB iPod (268g vs. 176g). The volume of the Nomad Zen is more than 75% larger then the 30GB iPod (209 cm^3 vs. 118 cm^3).
Is the difference all that important? Maybe not, but of the two the Apple iPod is certainly the sleeker, and that will matter to some customers.
This article is a duplicate of one posted on March 19 back when the CDT report was released:
CDT Releases New Report on Origins of Spam
With regard to quantum computers, it is my understanding that with suitable modifications, Shor's algorithm can be applied to ECC. It is unclear if quantum computers sufficiently large to attack cryptographic systems are at all feasible, but if they could be built then all of today's popular asymmetric cryptosystems would be insecure. However, I don't expect a quantum computer sufficiently large to attack 163-bit ECC will be built before 163-bit ECC falls to a more conventional attack.
The most efficient method published to attack ECC is Pollard's parallelizable rho method, with an expected run time on order of the square root of q group operations. So, while the run time of an attack against ECC is exponential in the size of q, it doesn't grow as fast as an exhaustive search attack against a symmetric key cryptosystem. As a rule of thumb, an ECC key is approximately as strong as a symmetric key with half as many bits, so a 163-bit ECC key is roughly equivalent to an 80-bit symmetric key.
The following is one of the better articles on this subject:
A. Lenstra and E. Verheul, "Selecting Cryptographic Key Sizes,"
Journal of Cryptography, v. 14, 2001, pp. 255-293.
A PDF file of the article can be downloaded here.
Horizontal Deformation Velocity Map, Version 2.0, Crustal Deformation Working Group 1, Southern California Earthquake Center, 1998.
Modeling broadscale deformation in Northern California and Nevada from plate motions and elastic strain accumulation, Murray and Segall, 2001.
The PanIP Defendants web site mentioned in the article has a list of the 50 companies that have so far been sued by PanIP. Interestingly, despite the large number of e-commerce companies in California, none of the defendants are located in California.
Since the patent holder, PanIP, is located in San Diego the cases are taking place in the U.S. District Court for the Southern District of California. Since all of the companies being targeted are small out-of-state companies they are unlikely to already have an established relationship with an attorney licensed to practice in California. I wonder if PanIP is specifically targeting companies that are not in California, perhaps on the theory that out-of-state companies will be more likely to settle when faced with having to litigate a case far from home?
For more information, see the following posts (August 8th and August 10th) to the Cryptography mailing list.
When a cosmic ray hits the atmosphere it produces many secondary particles, it is these particles which cause soft errors in computer memory. For computer memory the worst secondary cosmic rays are the hadrons (protons, neutrons and pions). Neutrons are particularly troublesome since these are responsible for more than half of the terrestrial soft errors. In order to affect the computer memory these neutrons have already had to pass through kilometers of atmosphere, through the building, and through the computer housing - a little lead isn't likely to stop them. In fact, surrounding your computer with lead could even make things worse. Cosmic rays are often counted with a neutron monitor and it is not uncommon for neutron monitors to be deliberately constructed with a lead casing. The lead casing increases the neutron count by producing more neutrons as it is bombarded by cosmic rays.
For example, the expected soft-fail rate of a computer memory system in Denver, Colorado is about 4 times greater than the rate expected at a city it sea level (such as New York City). Even in Leadville, Colorado (which is located at 10,151 feet) the expected failure rate is only about 13 times greater than in NYC. No location in Colorado even approaches 100x.
For more information, see the following paper:It can be found online here.
A PDF or postscript version can be downloaded from here. An HTML version is online here.
While the paper is written more as an exercise in humor than as a serious scientific endeavor, all of the math is correct. The authors calculate that the optimal strategy for quickly finding the solution to large computational problems with a fixed budged is: defer your purchase of a computer until you can purchase a computer that will solve the problem in about 26 months. As a corollary to this, any calculation that currently takes less than 26 months will finish earliest if started immediately.
I haven't heard that story before. Can somebody point me to a source with more details?
Apple definitely has a product placement program. Read more about it here.
The other Gigabit Ethernet port is on a PCI card that is installed, in the standard configuration, in the Xserve's combination PCI/AGP 4X half-length slot. This bus should have adequate bandwidth for Gigabit Ethernet as no other slots are connected to this bus.
The other two full-length slots are on a different bus. They are served by a single 64-bit 66MHz PCI bus with a data rate of 533 Megabytes/second. In the standard configuration one of these slots is filled by a VGA graphics card. The four ATA/100 busses are connected to this PCI bus, so intensive disk I/O could interfere with the performance of cards in these two slots.
[1] B. Preneel and P. van Oorschot, "MDx-MAC and building fast MACs from hash functions," Advances in Cryptology - CRYPTO'95, LNCS 963, Springer-Verlag, 1995, pp. 1-14.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/preneel/m
Your guess about Windows Terminal Server is spot on. The article in German mentions that the Philips monitor is based on Microsoft's Mira technology, Mira relies on Microsoft's Terminal Server and Microsoft Terminal Server uses the Remote Desktop Protocol (RDP).
Yes, the monitor communicates with the PC via IEEE 802.11b at 11 Mbits/s. This isn't really adequate for anything that refreshes the screen a lot, especially since I doubt the communications protocol between the monitor and the PC is as high-level as the communication between an X client and an X server.
The philips page here gives more details. I don't know why the Slashdot article links to the Philips home page instead of the Philips page that discusses the monitor.
Consider using the myprivacy.ca whois-harvester-buster. Create a free @myprivacy.ca e-mail address, and then use it in your whois information. If you've registered your domain from (and admittedly small set) of participating ICANN registrars any mail from the registrar will be forwarded to you automatically, but if someone else sends e-mail to the myprivacy.ca e-mail address they have to answer a simple confirmation e-mail before their e-mail will be forwarded to you.
Of course, this doesn't help if the registrar decides to send you spam...
However, our situation may have been unique. Our communication bandwidth needs were rather high, so the Apple machines having motherboard gigabit ethernet turned out to be an advantage instead of unnecessarily pulling down their price/performance ratios. Second, for our problem it was possible to utilize the AltiVec vector processor in the G4 PowerPC processor. While the vector execution unit is only 128-bits wide, it was wide enough for our problem and significantly superior to the "vector" units in the Intel and AMD chips.