Back in the early-mid 90s (when I was last paying attention to the issue), Indian universities used to use Unix a lot. Perhaps the PC has crowded out that tradition, but we were well-positioned there for a while. Perhaps we can get that back.
Everybody's OS is RAM-greedy these days, even most Linux versions (or more to the point, most X Windows environments.) RAM is cheap, as long as your machine is new enough (except for the latest cutting-edge speeds), and you should buy more of it.
I had WinMe at home for a couple of years, and it was pretty similar to Win98 in reliability - occasionally I'd have to scrape&reinstall, but pretty rarely. (On the other hand, the features that led me to by Win98SE and WinME didn't work very well.) But the Compaq version on my mother-in-law's PC was a disaster.
We had to install XP on my mother-in-law's machine because it just wasn't worth cleaning up WinME Yet One More Time (especially with all the Helpful CompaQ Recovery Software). If AOL could run from a LiveCD, it would be the ideal environment for her.
Channel-based systems are easy to tap. Spread-spectrum is much harder. (It'd be basically impossible, except that US eavesdropping laws limit the frequency-hopping rates to something the Feds can tap, but that's still beyond your average advanced hobbyist.)
Yup. You can get phones in the 900 MHz or 2400 MHz bands, so pick the one with less interference (and they're usually spread-spectrum, which is already a good start.) Just be careful about battery charging - my home Panasonics have really bad batteries for an otherwise nice 5-handset network.
If you got the card at a store that says "we'll never use this information to spam you", then it's at least arguable, but they probably did the right thing - it's a reasonable use of a business relationship.
If you got the card at a store that says "We're using this card to give you Great Discounts in return for being a Great Customer", well, spam away, baby, there's no privacy promise there.
If the card is also a check approval card (does anybody still use checks?) it's a bit dodgy.
If they somehow tracked down the fingerprints on "John Doe, General Delivery, Beverly Hills 90210"'s grocery card application, came to my door, and rang my doorbell, yes, that would be privacy invasion. But that didn't happen to me, errr, ummm., to John Doe. Because they respect John Doe's privacy, at least enough not to do that kind of work to violate it.
If next week when I'm at the checkout line, they say "Mr. Doe? You bought some beef last week? I hope you didn't eat any of it...", well, that would be kind of weird.
First of all, you're a troll. But aside from that, most of the store chains don't care if you're providing them real information or not (except the ones where the card is also a check approval card.) I've been John Doe several times, address "General Delivery", real city, real zip code - that lets them track whether running a sale on chicken boosts the sales of bbq sauce or tortillas or white wine (I'm a vegie, so no:-) and gets me my discounts. Obviously I won't get my personally-targeted Mad Cow ads, but they seem to stuff my mailbox full of supermarket ads addressed to "Occupant" anyway.
I've also gotten cards as "Illegible scrawl" at some stores, depending on their procedures for trading the card for the paper.
Actually, there's a rather nice hosts.txt at www.mvps.org.
All the IP addresses are 127.0.0.1, and the domain names are a collection of spammers, popup sites, banner dealers, etc., most of whom you'd rather not talk to. (Of course, that works better if you've got a web server that rejects everything, or sends back blank 1x1 GIFs.)
The Root Zone is really small - a few global TLDs, a couple hundred CCTLDs. It's about 10KB. Even if they added DNSSEC to the whole root zone it'd be under a meg. Might as well get a copy.
The equivalent for.com is obviously much bigger - I think there are ~35 million names (maybe that includes.net). But that's still about 5GB of highly compressible data - probably about 1GB if you sort it appropriately first. That's about the size of a Linux distribution - use BitTorrent. That's about 3 hours on a T1 line, and most of the people who need it are ISPs anyway (so it's about 10 minutes on a T3.) Probably doesn't change by more than 20% a month, or 1% a day.
The Root Server DDOS was October 20-22, 2002. It wasn't totally successful at shutting them down, but it made a serious dent in several of the systems for a while. We still don't know who did it, whether it was some craX0r k1dd13 looking for bragging rights or the Department of Homeland Security trying to get more funding or trying to get official bureaucratic authority over the root servers. And a measurement shortly before that event found that 98% of the queries to the root servers are bogus (repeats, bogus TLDs like.localhost, reverse-DNS lookups for RFC1918 addrs, etc.)
Most of the anycast deployment has been since then, and Verisign has put out lots of PR about how they're less vulnerable, but the real critical issues are making sure the Tier 1 ISPs get some kind of secure feed to the data so the root servers are less important.
(Oh, and I *could* tell you what the Department of Homeland Insecurity was *really* trying to do, but then I'd have to DDOS you and null-route your address space.)
According to an October 2002 study, 98% of queries to the F Root Server (and therefore probably to the other root servers) are unnecessary. Either they're duplicates (75%) or they're for bogus TLDs (.localhost,.elvis,.corp, etc.) or they're in-addr.arpa queries for RFC1918 addresses, or they're some other bogus query, and they should have been served out of cache or handled by some ISP's DNS instead of bothering the roots. Maybe the A Root has some important functions, but they aren't what it spends its time on. And 50% of the queries come from about 220 servers - they should either be caching responses, or be shuffled off to some server that handles them (I guess anycast will help with this...) as well as cleaning up their act if they're broken, which some of them are.
Anycast is a good approach for some kinds of problems, but fundamentally the A Root and the other rootservers are a more fragile environment than they should be because they're not using the hierarchichal nature of the DNS system appropriately. Last year's DDoS attack on them demonstrated some of this vulnerability. The Root Servers have three main jobs:
Distributing the database to major servers (at least one machine from each of the 13 often-virtual root servers, plus the master DNS servers at the Tier 1 ISPs, the CCTLD servers, and some small number of other sites
Answering DNS queries from the major servers
Answering DNS queries from any random machine on the Internet
The system becomes performance-critical to lots of people because too many machines send queries to the root servers (or the.com and.net servers) instead of querying their ISP's DNS server, and too many small ISPs are also querying the root servers instead of their upstream's DNS server. DNS scales well because most information can live near the bottom of the net, and almost all queries can be resolved locally or nearby without have to go ask Jon Postel's ghost for the authoritative answer.
The root zone itself is probably under 10KB of data that doesn't change every day - if you provide a separate server for zone transfers and let 1000 other DNS servers have access to it (firewalled to prevent any other IP traffic), that's about half an hour on a 56kbps modem. Remember that all it's doing is answering good questions like "Where are.com's name servers?" "Where are.za's name servers", bad questions like "Where are.example,com's name servers?", "Where is 10.in-addr.arpa?" and ugly questions like "Where is Ping of Death?". Let the major servers handle most of the work, absorb the ugly packets and do some queries for bad packets, and let the general public query those anycast machines - they should be querying their ISPs' servers, or their upstreams', which cache the real information, and even when their queries aren't bogus, they shouldn't be blocking the internet-stability-critical traffic.
The.net,.com, and.org domains are a similar problem, except of course they aren't served by the root servers. The zones are much bigger, a few gigabytes size, but probably only 10% of it changes in any given month, or 99.9999% of the existing domains, which ought to be enough to call the Internet stable, using about 1 Mbps (10GB * 1%/day * 8 bits/byte / 24*60*60 ), and again, keep the public query traffic separate from the zone transfer traffic, and maybe offer a third set of DNS servers to answer queries from the big ISPs to handle things like newly created domain names. The reason to keep that kind of query traffic separate is to avoid attacks like "query bogus00001.com" "query bogus00002.com"... etc.
Obvious flame-attracting discussion points:
What about the Alternate Roots? They argued that there's no excuse for ICANN/versign/etc. to own the TLD space and PROFIT from selling names like *.sex. Fine - they can use my ideas for free:-)
DJB likes rsync+ssh better. He might be right, but I'm trying to look at the small incremental change approach.
This makes nic.big-ISP.net a much bigger target! It's already a target. They can apply the same approach recursively, plus their users can still query the roots, and they probably have a somewhat distributed architecture already.
But the Internet is supposed to be any-to-any and this sounds like hierarchical corporate hegemony! Alas, too late for that, and if a 56kbps line can handle 1000 root zone transfers in half an hour, a T1 line should be able to handle 50,000 ok. Meanwhile, even covering the top 100 ISPs covers most of the Internet's users for stability.
I just loaded the 2003-12-31 cooker on a new machine, and now 10.0 beta comes out:-) Does anybody know what the differences are? Should I let Bittorrent run for the next 126 hours to get a copy and install that instead? I haven't actually had time to see what was in cooker yet:-)
They also missed 127.0.0.1, which has a great FTP archive.
--
If you don't recognize the reference, the Scientology Mafia's lawyers got taken in by a joking discussion on a.r.s about there being a copy of all the S33kr1t Docum3ntz on ftp://127.0.0.1 and spent a while grilling Keith Henson about it in court (transcript).
For the last decade or two, Telstra has held the record for "Most clueless telco/ISP in a developed country". They're not quite in the same league as India's VSNL, but they're dumber and ruder than AT&T's Comcast cable modem people, and Comcast has been trying hard to learn things from Telstra, like bandwidth caps.
When Global Crossing built huge amounts of modern fiber technology across the oceans, and bankrupted themselves in the process, the cost of bandwidth across the Pacific started dropping rapidly. Southern Cross deployed their cables from the US to Australia in 2001 at 20 Gbps, and they've gradually cranked up the optics, to 240 Gbps last year and potentially 480-640 Gbps. That means that they've currently deployed about 12 Mbps per Australian, and that doesn't count the bandwidth of the other cable systems, like APCN or SEA-ME-WE-3.
Disclaimer: I'm a Comcast stockholder, so this is about 1 ten-millionth of an official policy statement from Comcast.
I haven't had UPSs to deal with, but back when computers were big and needed air conditioners, I had a computer room that would deadlock on temperature. If we had a power hit (thunderstorms, etc.), the Vax would wake up and start heating up the room (and maybe boot, if it was running BSD, or sit around in single-user waiting for you to run fsck, under System V), but the air conditioner would sit there beeping to tell a human to hit the On switch. This was a "feature", because big hulking air conditioners draw enough power that you don't want them to all fire up their motors at once when the power comes back on. On weekdays, this was no problem - we'd press the button and they'd start. But if the power went out on a weekend, it meant that the room kept getting warmer and warmer for a couple of days -- or until it reached 130 degrees F, that is, at which point the power controller system decided that there might be a fire or at least it was too hot to safely run computers, so it would shut down until the room cooled down. But of course the room wouldn't cool down, because we couldn't turn on the air conditioners:-) So we'd have to open the back doors and maybe steal some desk fans and wait till the room cooled down a few degrees and we could restart the AC.
This was also the days when video projectors were big ceiling-mounted things that cost a lot of money. Ours was in the conference room attached to the computer room, and you were supposed to turn it off when you weren't using it. Usually no big deal, but somebody once forgot that after a Friday meeting and we had a Saturday power hit, so Monday morning when we came in, the projector's cooling fan was blowing 140-degree air through itself to cool itself down, and there was a puddle of oil on the table....
Once when I was a newbie (i.e. using a time-sharing machine) I must have accidentally created a file named "*". So I removed it. After hitting the key I realized that that had been a stupid thing to do:-) Fortunately, the machine had administrators who did nightly backups.
On the other hand, a coworker and I were doing some work on one of the Bell Labs Murray Hill machines that did weather, and I did a typo when removing something, and trashed some of the files that made our internal weather-report processing system work. It was in some directory like/usr/local, and we found that nobody had backed it up in five years, and the stuff was really gone. Nothing we could do about it except apologize.
A much smaller 224-bit ECC key offers the same level of encryption as 2048-bit key in the competing RSA format. In other words, a company would need 16 times stronger encryption to get the same level of protection that Certicom offers in the ECC format.
No, it doesn't make sense, which suggests that the author either doesn't get it at all or else got confused during a cut&paste. (For instance, there's a table on certicom's site that says the key length difference is 1:6 for 163-bit ECC vs equivalent 1024-bit RSA...)
Anyway, if you need adequately-strong keys, that's typically 224 bits for ECC vs. 2048 bits for RSA, and there are applications where it's easy to fit 224 bits and annoying to use 2048, such as DNS security or smart cards or email signatures. If your threat model is more relaxed, you might get away with 163-bit ECC or 1024-bit RSA, but you've got more risk that somebody's going to do interesting theoretical attacks on ECC and erode a few bits from the strength. For symmetric-key applications, you'd typically use 128-bit strength (or triple-DES at 112 bit strength, either with 2 or 3 keys.)
"Better security per key-bit" is a silly measure. "Conveniently short keys that are adequately strong" is a more realistic measurement. RSA and Diffie-Hellman keys need to be at least 1024 bits long, and many people are sufficiently paranoid that they'd prefer 2048 instead, and there are applications for which this is a problem - Secure DNS, for instance, which has to fit many kinds of messages in 512-byte packets (576 including headers). The Certicom people say that 224-bit long ECC keys are equivalent to 2048-bit RSA, and 163-bit ECC to 1024-bit RSA, and there are applications where those 20-30-byte keys are really much more convenient.
In particular, short keys make it natural to pass around the actual key, instead of some KeyID record like PGP does with RSA keys, which not only reduces the chances of Bad Things happening in your protocols, but also means you're much less dependent on keyservers; you can print the key on your business card, or include it in hex in your email signature line (see James Donald's Crypto Kong program for a nice example.)
The risk with ECC isn't brute force crackers (so the contest is mostly silly.) It's theoretical math breakthroughs - precisely because we haven't had the same depth of math concentration on ECC that we've had on factoring in the last 20 years.
Slashdot Mirror
Back in the early-mid 90s (when I was last paying attention to the issue), Indian universities used to use Unix a lot. Perhaps the PC has crowded out that tradition, but we were well-positioned there for a while. Perhaps we can get that back.
Soekris makes a variety of little boxes and boards, mostly for low-power small applications. Based in Santa Cruz California.
The Linksys not only has a faster CPU, it avoids the delay of shipping your packets to Mars and back....
I had WinMe at home for a couple of years, and it was pretty similar to Win98 in reliability - occasionally I'd have to scrape&reinstall, but pretty rarely. (On the other hand, the features that led me to by Win98SE and WinME didn't work very well.) But the Compaq version on my mother-in-law's PC was a disaster.
We had to install XP on my mother-in-law's machine because it just wasn't worth cleaning up WinME Yet One More Time (especially with all the Helpful CompaQ Recovery Software). If AOL could run from a LiveCD, it would be the ideal environment for her.
Sid gives the guy a new version of BadgerBadgerBadger that does HasturHastur...
Channel-based systems are easy to tap. Spread-spectrum is much harder. (It'd be basically impossible, except that US eavesdropping laws limit the frequency-hopping rates to something the Feds can tap, but that's still beyond your average advanced hobbyist.)
Yup. You can get phones in the 900 MHz or 2400 MHz bands, so pick the one with less interference (and they're usually spread-spectrum, which is already a good start.) Just be careful about battery charging - my home Panasonics have really bad batteries for an otherwise nice 5-handset network.
It's not a smooth linear or exponential thing - it's random and bursty. That's why I padded the numbers up.
I've also gotten cards as "Illegible scrawl" at some stores, depending on their procedures for trading the card for the paper.
All the IP addresses are 127.0.0.1, and the domain names are a collection of spammers, popup sites, banner dealers, etc., most of whom you'd rather not talk to. (Of course, that works better if you've got a web server that rejects everything, or sends back blank 1x1 GIFs.)
The equivalent for .com is obviously much bigger - I think there are ~35 million names (maybe that includes .net). But that's still about 5GB of highly compressible data - probably about 1GB if you sort it appropriately first. That's about the size of a Linux distribution - use BitTorrent. That's about 3 hours on a T1 line, and most of the people who need it are ISPs anyway (so it's about 10 minutes on a T3.) Probably doesn't change by more than 20% a month, or 1% a day.
Most of the anycast deployment has been since then, and Verisign has put out lots of PR about how they're less vulnerable, but the real critical issues are making sure the Tier 1 ISPs get some kind of secure feed to the data so the root servers are less important.
(Oh, and I *could* tell you what the Department of Homeland Insecurity was *really* trying to do, but then I'd have to DDOS you and null-route your address space.)
According to an October 2002 study, 98% of queries to the F Root Server (and therefore probably to the other root servers) are unnecessary. Either they're duplicates (75%) or they're for bogus TLDs (.localhost, .elvis, .corp, etc.) or they're in-addr.arpa queries for RFC1918 addresses, or they're some other bogus query, and they should have been served out of cache or handled by some ISP's DNS instead of bothering the roots. Maybe the A Root has some important functions, but they aren't what it spends its time on. And 50% of the queries come from about 220 servers - they should either be caching responses, or be shuffled off to some server that handles them (I guess anycast will help with this...) as well as cleaning up their act if they're broken, which some of them are.
- Distributing the database to major servers (at least one machine from each of the 13 often-virtual root servers, plus the master DNS servers at the Tier 1 ISPs, the CCTLD servers, and some small number of other sites
- Answering DNS queries from the major servers
- Answering DNS queries from any random machine on the Internet
The system becomes performance-critical to lots of people because too many machines send queries to the root servers (or theThe root zone itself is probably under 10KB of data that doesn't change every day - if you provide a separate server for zone transfers and let 1000 other DNS servers have access to it (firewalled to prevent any other IP traffic), that's about half an hour on a 56kbps modem. Remember that all it's doing is answering good questions like "Where are .com's name servers?" "Where are .za's name servers", bad questions like "Where are .example,com's name servers?", "Where is 10.in-addr.arpa?" and ugly questions like "Where is Ping of Death?". Let the major servers handle most of the work, absorb the ugly packets and do some queries for bad packets, and let the general public query those anycast machines - they should be querying their ISPs' servers, or their upstreams', which cache the real information, and even when their queries aren't bogus, they shouldn't be blocking the internet-stability-critical traffic.
The .net, .com, and .org domains are a similar problem, except of course they aren't served by the root servers. The zones are much bigger, a few gigabytes size, but probably only 10% of it changes in any given month, or 99.9999% of the existing domains, which ought to be enough to call the Internet stable, using about 1 Mbps (10GB * 1%/day * 8 bits/byte / 24*60*60 ), and again, keep the public query traffic separate from the zone transfer traffic, and maybe offer a third set of DNS servers to answer queries from the big ISPs to handle things like newly created domain names. The reason to keep that kind of query traffic separate is to avoid attacks like "query bogus00001.com" "query bogus00002.com" ... etc.
Obvious flame-attracting discussion points:
What Bush actually said was "The Moon is MINE! Mine mine mine all mine!"
I just loaded the 2003-12-31 cooker on a new machine, and now 10.0 beta comes out :-) Does anybody know what the differences are? Should I let Bittorrent run for the next 126 hours to get a copy and install that instead? I haven't actually had time to see what was in cooker yet :-)
--
If you don't recognize the reference, the Scientology Mafia's lawyers got taken in by a joking discussion on a.r.s about there being a copy of all the S33kr1t Docum3ntz on ftp://127.0.0.1 and spent a while grilling Keith Henson about it in court (transcript).
D'oh! Yes, of course I know AT&T sold their cable modem people to Comcast... traded clunky for vicious...
When Global Crossing built huge amounts of modern fiber technology across the oceans, and bankrupted themselves in the process, the cost of bandwidth across the Pacific started dropping rapidly. Southern Cross deployed their cables from the US to Australia in 2001 at 20 Gbps, and they've gradually cranked up the optics, to 240 Gbps last year and potentially 480-640 Gbps. That means that they've currently deployed about 12 Mbps per Australian, and that doesn't count the bandwidth of the other cable systems, like APCN or SEA-ME-WE-3.
Disclaimer: I'm a Comcast stockholder, so this is about 1 ten-millionth of an official policy statement from Comcast.
This was also the days when video projectors were big ceiling-mounted things that cost a lot of money. Ours was in the conference room attached to the computer room, and you were supposed to turn it off when you weren't using it. Usually no big deal, but somebody once forgot that after a Friday meeting and we had a Saturday power hit, so Monday morning when we came in, the projector's cooling fan was blowing 140-degree air through itself to cool itself down, and there was a puddle of oil on the table....
On the other hand, a coworker and I were doing some work on one of the Bell Labs Murray Hill machines that did weather, and I did a typo when removing something, and trashed some of the files that made our internal weather-report processing system work. It was in some directory like /usr/local, and we found that nobody had backed it up in five years, and the stuff was really gone. Nothing we could do about it except apologize.
No, it doesn't make sense, which suggests that the author either doesn't get it at all or else got confused during a cut&paste. (For instance, there's a table on certicom's site that says the key length difference is 1:6 for 163-bit ECC vs equivalent 1024-bit RSA...)
Anyway, if you need adequately-strong keys, that's typically 224 bits for ECC vs. 2048 bits for RSA, and there are applications where it's easy to fit 224 bits and annoying to use 2048, such as DNS security or smart cards or email signatures. If your threat model is more relaxed, you might get away with 163-bit ECC or 1024-bit RSA, but you've got more risk that somebody's going to do interesting theoretical attacks on ECC and erode a few bits from the strength. For symmetric-key applications, you'd typically use 128-bit strength (or triple-DES at 112 bit strength, either with 2 or 3 keys.)
In particular, short keys make it natural to pass around the actual key, instead of some KeyID record like PGP does with RSA keys, which not only reduces the chances of Bad Things happening in your protocols, but also means you're much less dependent on keyservers; you can print the key on your business card, or include it in hex in your email signature line (see James Donald's Crypto Kong program for a nice example.)
The risk with ECC isn't brute force crackers (so the contest is mostly silly.) It's theoretical math breakthroughs - precisely because we haven't had the same depth of math concentration on ECC that we've had on factoring in the last 20 years.