The big reason that I want a small Linux distribution instead of a 15-CD RedHat set is so I can run Linux on wimpy machines. I've got a number of antiques hanging around my lab doing nothing, and few of the Pentium60s and none of the 486s have CDROMs, and all of them have wimpy disk drives. Netbooting is important - it makes it possible to install the basic operating system on a small machine and get it up and running, with the disks partitioned enough to install any other software.
It's also important to have distributions that can install the basic system from one CD! (Or alternatively, at least to be able to install it from separate CDs that aren't all merged into one ftp directory.) Even most of my server machines don't have enough space to copy multiple CDs to one filesystem for FTP, so it's also really important to be able to work with separate CD images - ideally to mount the CDROM and publish it with FTP, or at least to have the different CD images stashed in different directories (which also makes it possible to do two-CD sets by storing one in ~ftp/pub/linux/cd1/ and symlinking or mounting the CDROM for the other disk.)
Gentoo is a very small Penguin
on
Gentoo 1.0 Released
·
· Score: 3, Informative
There's certainly no excuse for a digital cellphone not to know what time it is. The cell networks are broadcasting digital signals anyway, and the phones are smart devices. Only some of the cellphone networks do that (which one do you have?) but I would hope that as newer standards are developed that they'd all support time. You probably won't get much better than 1/10 sec precision without doing more work than the network really needs, but even 1 second precision is enough for most applications. It'd also be nice if cellphones with datalinks to other computers can provide timesync.
But if there's even *one* cellphone network in your area that broadcasts timesync, and if the protocols support receiving it without sending back reply packets, it should be pretty cheap to build a receiver that listens to it to incorporate in whatever device you want.
Cable modem service was *always* open - that was what really upset the other ISPs. Both the cable companies and the Enforced-Openness ISPs picked the wrong issues - the cable companies "won" by better political lobbying, and killed their industry in the process by causing several years of delay in the growth of their customer base while trying to pay off big debts and delaying their transformation into the new telephony industry. Here's what openness really did and didn't mean:
YES - Routes packets from the user to anybody on the internet. That was the real problem that upset the competing ISPs often objected to, because this is what makes their traditional model of dial-plus-mail-plus-web obsolete. The obvious implementation of cable modem service is to do routing from the head end on up, unlike DSL or dial services which fundamentally provide Physical Layer or Link Layer services between the end user and some service provider that builds IP connectivity on top of them. Some cable providers do obnoxious things like PPPoE or use 10.x addresses with NAT to give them more control over their users' access (e.g. make it easier to cut off people who don't pay their bills), but they're not necessary.
YES - Routes packets from the user to an email provider. Until the recent problems with spammers started some providers forcing Port 25 through their own relays, this was available, and they all will still allow you to fetch your email from your favorite POP/IMAP/Webmail provider. Some ISPs will only let you retrieve your email if you connect in through their dialups, but that's the ISP being closed, not the cablemodemco.
YES - Lets you retrieve your AOL mail. AOL was one of the big complainers about competition from the cablecos, but they have offered a $9.95 service for a long time that lets you use AOL services from your real ISP.
NO - Competing email service from the cable modem company. Sure, if you were an Excite@Home customer, your webmail account didn't have banner ads on the top the way the free webmail accounts did, but this isn't a real issue, and the Enforced-Openness ISPs shouldn't have tweaked on this one - there were lots of free webmail services competing with them, and providing POPmail and other good-quality email service was the way to compete.
YES - Provide big pipes to service providers that want better performance than they'd get on the open internet. I know that Excite@Home offered this, and I think some of the others did too. Most ISPs can get by with one connection into the cable network, in which case they don't need it, some need multiple connections, e.g. at the big regional peering points, and almost nobody had applications that needed to actually get down to the individual head end - the cable modem companies' regional concentration networks were adequate for that. I don't think the cable modem company lawyers who did the big Resist-Enforced-Openness-We-Paid-For-This-Network lobbying campaigns ever had a clue that they were talking out of both sides of their mouth by tweaking on this issue. Once you've got a routed network, you own the user's connection, and the rest is just implementation and pricing. They already *were* open, in the ways they were telling people it would be *way too expensive* to open up their networks, and they were too clueless to know it.
YES, THIS ONE WAS CLOSED - Decent billing systems that can handle wholesale ordering. This has two impacts - can the ISP market and sell the service to customers and get it provisioned without making the customer order it directly, and does the bill say "Your friendly neighborhood ISP" or does it say "Cable Modem Service From Your Cable TV Company"? A number of the Enforced-Openness ISPs ranted about this, but they failed to make it their major lobbying focus, even though it was the key issue and was the most fixable, and they let the Anti-Enforced-Openness cableco lobbyists lead them off into arguments about connections to the head end. This was one of the big failings of the cable modem companies - it's not strictly necessary for openness, but the big problems they had besides upgrading obsolete hardware were How To Get Customers To Buy Broadband, and wholesaling would have given them more options for finding the content and marketing plays that worked. As it was, the closest they really had to a wholesale marketing connection was Napster:-) Since it was free, they didn't care that they couldn't get the cableco to do billing, and it *was* one of the big reasons people bought broadband. This policy problem especially irked me, because AT&T Broadband's parent company AT&T *does* do wholesale billing for dial ISP services that want to do the same things with their modem service, but the billing systems for cable were totally different and the @Home marketing people were clueless.
NO - Lower prices for wholesale accounts. The Enforced-Openness ISPs did tweak on this one, and spent a lot of time whining about it instead of hitting the billing system openness issues. Yes, it's harder to compete by providing email service for more money than the free webmail at the cable co, but you can do it.
YES, THIS ONE WAS SEMI-CLOSED - Policies against users running servers or providing services on their home systems. (In an open environment, each ISP would probably be able to set separate policies about this, but that's not easy in a routed-from-the-head-end network.) This was another cluelessness on the part of the cable modem companies - they thought that by spending $6B for Excite, they could provide enough exciting content to get couch potatoes to buy their service, instead of realizing that they desperately needed compelling content and that Central Planning wasn't the way to make it appear. Sure, they had to deal with performance issues, and the no-servers policy was partly because the early cable modem systems didn't have mechanisms to limit users' upstream bandwidth, which was the technically constrained resource in the system, but in spite of all those Pac Bell DSL "NO Web Hogs" commercials, performance was never really a problem except in one of their initial test cities which turned out to have some bad hardware.
Your real problems aren't likely to be police* - they're likely to be ISPs dealing with complaints about spamming and about file/warez servers run on your network. The obvious way to protect the access-point provider from this while also protecting the roaming user from eavesdropping is to support tunnels back to a wireless access service provider's host location. That way, the service provider can do billing (if that's how you want to run it) and can do a contract with the cable modem company or DSL providers to avoid the AUPs-against-resale problems (so the cable company gets, say, $5/month to support roaming users), and the service provider gets a hook to manage any abuse issues like spamming or evil-content servers rather than the access point user being stuck with them.
* If you're somebody the police would like to entrap, *then* they might go engaging in suspicious activities on your wireless network as an excuse to get a warrant, but most people in that situation know enough to be worried....
It's still line-of-sight, so you won't be visible outside the area except for the smoke signals caused by fried birds and trees and airplanes. But you're really just talking about a microwave oven that's a bit less concerned about limiting its cooking area.
I wouldn't be bothered that if a small newspaper didn't have the technological background to avoid being snowed by this bunch of badly distilled snake oil, though the Globe and Mail is big enough that they should know better. It's important for papers to have technology writers or editors who at least know the difference between a press release, a report of a press conference, and a news article and can provide some objectivity by also interviewing one or two experts in a field to get some idea whether the company advocating their new product are really cool and clueful or whether they're selling total crockery (or both:-). Some newspapers have reporters with serious technical expertise (the NY Times and SJ Mercury News, for instance), and some make no pretense of doing objective journalism (name your favorite print-the-press-releases trade rag), and some are small enough you don't expect them to understand the technology (most small-town papers.) But even most small-town papers have local politicians and real-estate developers and used-car salescritters and ought to be able to occasionally recognize when somebody's trying to snow them.
The so-called technical white paper was one of the worst I've seen in ages.
The DeCSS break didn't depend on a licensee being careless with keys or code. Because the code is inherently contained in any software implementation, all that the 15-year-old kid who cracked it needed to do to access the critical data was decompile the code and analyze it carefully. He *may* hav violated his license in the process - it's not clear whether click-wrap licenses have any legal force in Norway at all, or even if they do, it looked pretty clear that Norway's laws about reverse-engineering override the terms of the license. The problem of obfuscating software-only implementations of code is fundamentally hard, though the DVD CSS folks could have designed a much more competent algorithm.
It's possible that the GSM crack did - I'm not sure if the pseudo-code that Ian analyzed over lunch one day, which he got off the net, was originally posted by somebody who violated his licenses in the process (or at least, how *badly* the alleged poster allegedly violated the alleged licenses:-), or whether the poster had access to the code because of a procedurally or contractually careless licensee. But even if that was the case, anybody who seriously wanted to crack the code could have probably grubbed the crypto algorithm off the chip in a phone, at the cost of a phone and a bunch of expensive chip-shredding hardware, though some of the authentication algorithms might have required examining a base station if they had been designed asymmetrically.
Oh, yeah - "We've found an electronic way of handling those complex keys, and of regenerating them dynamically so that lists of keys don't have to be stored anywhere," Mr. Kassam said. If you can regenerate the pad of keys, you have no way to limit it to one-time use. With a conventional silk or flash-paper pad distributed by spies with briefcases handcuffed to their wrists, once you use a page of the pad, you burn it so nobody can regenerate it again. Otherwise, somebody else can also regenerate the key and crack your message.
And I didn't bother pointing out that because these folks have no clue what a mathematical proof is, they didn't bother showing how their system preserves the properties of a OTP algorithm.
This product has pretty much all the signs of the classic snake oil psuedo-one-time-pad, except that if you can believe their white paper, it's weaker than most snake oil products. Here are some of the issues:
It's a proprietary secret algorithm they made up themselves. That's a bad sign already, because people who know the crypto community know that they have to be able to publish their algorithm and have it examined by (other) experts to have any credibility, and they know that any computer program can be reverse-engineered so the algorithm will leak out anyway, and anybody who doesn't know the crypto community well enough to know this hasn't read much of anything in the real literature, doesn't know the well-known attacks, much less the sneaky ones, and is probably reinventing yet another flat tire.
They worked on it for four years before it was ready for public use. Since it hasn't been peer-reviewed, it's *still* not ready for public use.:-) And they say it's "considered to be the best in the world", but since they're the only ones who've seen the algorithms, they must be the one considering it the best in the world, and as we'll see below, their taste in such matters is pretty questionable.
While grammar flames are normally considered tacky, if you can't get the syntax right in the English grammar in your press release, much less make the contents intelligible, and your crack team of engineers who've labored over this for four years can't hire somebody who *does* speak English to proof-read their press-release, I'm skeptical that they've done any better on either the syntax, structure, or quality-assurance for their programs. All your bits are belong to us! If they were from Montreal and not Toronto, you could at least blame it on Babelfish or something, but they've apparently had to do their own babbling.
Their PR says it doesn't use an algorithm, and then talks about the computer programs that produce it. "E2Sec is not structured and uses no algorithms, therefore unbreakable" That doesn't mean that it doesn't have a mathematical structure - it only means that they're not mathematicians, don't understand the structures, and aren't very good at algorithms, therefore it should be easily breakable. That also strongly implies that, since they don't know algorithms or structure, they're not only bad at math but also not very good at programming, so the implementation has a much higher chance of being cracked without even bothering to crack their incompetent algorithm.
They provide several examples of cyphertext (and the plaintext) and invite the public to break the algorithm using that, as a demonstration of their confidence that it's unbreakable. This approach is widely disparaged by the community - if they had any confidence, they'd not only publish the algorithm and invite cracking, they'd also pay some well-known cryptographer or cryptographers to analyze it for them, rather than hoping that either they'll get serious attention for free, or if they're a little brighter than that, only get unskilled amateurs trying to crack it because it's ignored by skilled professionals, leaving them free to say "See, nobody's cracked it in the TWO WHOLE WEEKS it was on the net! It must be UNBREAKABLE!!!!"
They provide a "proof", which apparently was copied or translated by somebody who doesn't speak Mathematics, and leaves out the definitions of the critical functions and the lengths of variables but makes vigorous assertions that it demonstrates unbreakability within a person's given lifetime. The only way I can see that their assertion is true is if what they mean is "You won't be able to figure the precise values out in your lifetime because we've underdetermined our example":-)"
They assert that competing systems usually only provide 128-bit security, but theirs provides 5000-10000-bit security, because that's roughly the sizes of encryption programs they pass between client and server. Yes, that's an upper bound on the possible complexity, but most of those bits are the expression of the program, not the key itself.
They pass their session encryption-pseudocode programs around using any conventional browser. This means that either it's all public, or that it's only protected by the 40-bit or 128-bit crypto used by the browser, so not only do they possibly have zero bits of strength in their own system, you might as well use your browser's encryption instead, because you can *i* get 128-bit crypto for free.
"The core code is dynamically generated at install time from a random selection of over a million unique and distinct pseudo-code each capable of generating millions of server-based code." Unfortunately, in contexts that are clearly mathematically clueless, it's difficult to evaluate whether "over a million" means "20 bits" or "more than 5" or "billions and billions" or "oh, wow, man, that's really complicated-looking!". But if we take them at face value, they are at least *saying* that it's really about a 20-bit algorithm. It's possible that when you look at the algorithm closely that the 20 bits condense to much fewer than that, or that it's really a lot stronger than their clueless press-release (excuse me, they called this a "technology white paper", didn't they) writer says it is, but it's a good hint that it might be around 20 bits strong.
Their algorithm uses "random numbers" and that they're "uniform". They don't talk about how they're generated, or how long they are. Typical random-number generation subroutines useful for game-playing or user interface decorations are linear congruential generators that are either ~16-bit or ~32-bit integers, and often the 16 bits are really just 15 bits. So maybe their 20-bit strength is really only 15. Of course, they also don't say anything about how the generator is seeded, so there's no way to tell if they've done that properly - it may be that their 15 bits of security falls apart after receiving two blocks of a message if they've done it sufficiently badly.
In addition to using random numbers of undefined quality, they also refer to using "undeterministic keys". Aside from non-deterministic constructs in English grammar, it's hard to tell if they're referring to the presumed-poor-quality random numbers they use in other parts of the program or if they're doing some kind of hardware-generated randomness, e.g. having the user wave a mouse around. But if they are, the values from that randomness can't be generated identically by the recipient of a message, so they need to be passed in the aforementioned messages, where an eavesdropper can snag them, so the strength, if any, isn't helpful.
Diffie-Hellman and El-Gamal are closely enough related to RSA that you don't get much diversity by picking them. Elliptic Curve is a nice possibility, though it's possible somebody will find the math to crack that. NTRU is a lot different - I don't know that any of the academic cryptographers are calling it really secure yet, but the people who've looked at it don't seem to be calling it "snake oil" either.
Your Visa number probably isn't worth spending a $1B to crack, so you don't need to worry. Visa, on the other hand, has to worry about millions of credit card numbers getting stolen, though it's still much easier to crack into most of the machines on the web that absorb credit card numbers, and if there's one master key that lets you steal all of Visa (I doubt there is), it's probably easier to find the people who have parts of that key and bribe them (if you're the Mafia), or subpoena them, if you're the sleazy bunch of thugs at the DoJ who just filed a "Go Fish" subpoena on Visa and American Express.
While it's not going to be on the same price curve as high-volume PC production, there are still Moore's Law effects here - the price/performance of FPGAs and ASICs keeps decreasing as technology improves, and the price of smaller-width chip design keeps improving. The real question is whether the development of this sort of machine can piggyback on other hardware development, plus how motivated is the NSA to build it as further research indicates whether or not it will be really useful...
There have been a few quantum computers developed, able to get a few bits of resolution (They've done 3 bits, and maybe they're close to 7.) This stuff is still undeveloped rocket-science. It's possible that the Feds have put billions of black-budget dollars into it, but I'd be surprised - it's probably more like small millions of dollars on open research in universities. As with computers, there are some things you can do better in secret, but usually the scale of the open market's research outruns it.
It'll really be interesting when they start to get to ~64-bits of resolution (at least if they don't run into Heisenberg uncertainty problems when the resolution approaches Planck's constant.) Will the resolution of this technology scale that far? But things don't get interesting for public-key crypto until you're at ~512 bits.
Also, there are some problems that quantum computers can accelerate and some that it can't. For instance, factoring is tractable, if you've got enough resolution, and there's a quantum computer that was able to factor the number 15 into 5 and 3. So RSA and Diffie-Hellman are toast, at least for 4-bit keys:-) Perhaps for much longer keys, if QC can be developed, but perhaps not. It's not clear whether elliptic curves can be cracked by quantum computers, but then, it's not clear that they can't be cracked by better mathematics.
Basically, if They can crack everything using public-key technology, you're back to private-key methodology like Kerberos, or traditional methods like one-time pads and guys with Kevlar briefcases handcuffed to their wrists.
It's been generally suspected that NSA has had the ability to break 512-bit RSA encryption for a while. Breaking 384-bit RSA is old hat, and breaking 512-bit has been doable even before Nicko's group made it easy on their machines, but this IS exponentially hard work - before Bernstein's hypothetical machine was hypothesized, the limit to current practice was believed to be in the low 600s. This suggests that 768-bit keys aren't trustable for more than casual work, but 1024-bit keys are still way fine.
The NSA has the advantage of occasionally being able to spend a billion dollars on chips or machine design, which says that building something like the EFF's DES $250K cracker was done at NSA long before the public got there (though "long before" has Moore's Law implications...). They also have some good mathematicians focusing on problems like this, not only because they like to crack other governments' codes but also because they need serious estimates of the strengths of the codes they use, but the general opinion in the crypto community is that they're no longer particularly far ahead of the open academic world, and in some ways they're behind because it's hard to get good peer review on secret algorithms, and it's hard to get and keep good mathematicians if you don't let them publish and don't pay them much money either. I don't believe they had the ability to crack 1024-bit RSA or Diffie-Hellman keys before Bernstein's paper came out - but they *do* have Bernstein's paper now:-)
Layering is fine, if you know what you're doing and implement it carefully enough to prevent some layers from giving away information about other layers. For instance, you could probably come up with a layering of elliptic-curve public-key encryption and RSA public-key encryption that doesn't violate any of the don't-reuse-stuff rules and is still relatively practical. The nice thing about elliptic curve is that the keys are short - the bad thing is that the math is hairy enough that nobody's quite sure that somebody won't find a way around the difficult part. By contrast, RSA uses simpler and better-explored math (and longer keys), and there's less chance of a major breakthrough making a radical change in the necessary keylength, though Bernstein's machine may turn out to be significant given further exploration.
The basic question is whether it's worth doing a two-or-three-algorithm solution as opposed to just making your keys longer. Depends a lot on your threat scenarios. Are you worried about the NSA cracking a key during your lifetime? Or are you running a bank and worried about bank robbers forging withdrawals? Or are you worrying about somebody forging your signature on an article on Slashdot?:-)
It turns out that it's easier to make signature systems use multiple algorithms than encryption systems - all you do is create a tuple of Sigalgo1(message,key1),Sigalgo2(message,key2)... as your signature (and use a representation that doesn't let the Bad Guy change how many bits of the signature string are interpreted as belonging to each algorithm) and there's none of this nesting business required that encryption systems use.
Computers, as proposed here *are* being used in conjunction with deep analysis - that's why the amount of computation required may have just dropped significantly. Reverse engineering doesn't really apply in this world, unless you're reverse engineering God's excellent job of making factoring difficult large numbers and interesting.:-) If you're doing some obscurity-based approach that requires reverse engineering, you've blown your chance at modern crypto work... Most of the public-key systems work by applying known hard algorithms in ways that let the work required to crack them be computationally infeasible, and it's understood that that's a shifting boundary - usually the crackers blow a dozen or so bits off the strength limits per year (some with faster computers, some with mathematical analysis), but the encryptors can add several hundred bits per year to the practical strength - doubling the number of key bits roughly quadruples the computation required, but you could do 512 bits conveniently enough on an 8086, so 2048 is no problem today, unless you've got packet size limitations which make that annoying, or unless you've got antique code that nobody wants to update for longer keys (particularly if the code is a silicon implementation of a bignum mulitplier), or unless you're running a web site that has to process a large number of connections per second, in which case this costs you actual money.
Use a long key - yes. Develop your own algorithm - no. Even the GSM telephone people and DVD encryption, which were theoretically developed by trained professionals, were total crockery. GSM had no excuse - the DVD folks could at least argue that the problem they were trying to solve is inherently hard and they were using double protection - a cheapo algorithm and expensive lawyers to run the DVDCSS lawsuits. But the GSM folks were working in well-established territory for which there are straightforward commercial-quality solutions available.
Dr. Zowie's description of the problem sounded like something that can be worked around, at least for some cases - which is why he may need to work with the transparent-proxy's vendor and not just the ISP. The two big problems are using the correct DNS lookup, and having old data in caches. Cache aging strategy is a standard problem - some systems do better or worse jobs of managing it, and some give you workarounds. (For instance, the proxy I use at work seems to respond to "Reload" requests from the browser and refresh its contents.) DNS lookup problems are really a bug - if the browser sends an http request to 192.9.200.1 for foo.bar.altroot/zap.html, it's certainly easier to implement by having the proxy forget the original packet's IP address, see if they have the page cached, and re-resolve the URL if not, but it's also a bug - they could keep track of the IP address as well as the URL. The bugginess of the dumb approach is most apparent with alternate-roots, but it can also be a problem for URLs at domains with round-robin DNS, where requests can go to any of the IPs in the group, but multiple requests need to all go to the same server for consistency, either because of stateful requests or because the servers aren't running with identical content names (e.g. for dynamic pages.) (One can argue that the servers are buggy in that case, but that doesn't mean that the caching proxy's behaviour isn't also buggy.)
Yes, you can use a proxy server outside your firewall that will fetch things for you, but you *still* have the problem that if you don't control the configuration of the proxy server, it might not do what you want - you're just choosing between differently configured proxies, one of which might do most of what you want.
If you can use a tunnel server, like IPSEC or PPTP or SSH, which lets you pick the IP address to send your IP packets to but doesn't interpret the packets itself, you'll mostly be ok (you'll still have to make sure to do your own DNS if you want to resolve on alternate roots.)
In one of the cases discussed here, the spammer got really upset about being dragged into discovery about his spamming. But many ISPs keep SMTP forwarding logs. Can you use discovery subpoenas to get *them* to produce their log files for a small claims case? That would be an interesting way to go after the spammers who are their customers, if their abuse people aren't helpful enough.
Do you know what brand of attempting-to-be-transparent proxy cache server they're using? Proxy caching is an important performance enhancer for ISPs, corproate firewalls, and other bottleneck network environments, and "transparent" proxies are less trouble for the ISP and for the users as well (especially since many users wouldn't bother configuring their browsers for them unless either they're pre-configured by the ISP or forced to use the proxy by firewall rules that block non-proxy access.)
Of course, the problem with transparent servers is when they're not, and your ISP seems to have one that isn't. Is it possible to find out what kind it is, either by telnetting to the thing and looking at headers or by asking the ISP, and can you do bug reports to the vendor to get them to fix their product?
I've been thinking about the spam problem and how to discourage attacks from open relays. Are there mail systems that don't do loop detection, or aren't good at detecting if mail is really addressed to their machine? For instance, what do the popular mailers do if they get mail for spambait.example.com and dns resolves the name to 127.0.0.1 or 127.0.0.2 or 255.255.255.255? Do they decide it's for them, or do they think it's for somebody else and send it back to themselves? Or if you set your DNS to tell spam-relay-1.com.kr that spambait.example.com's IP address is the address of spam-relay-2.com.kr and vice versa - will they end up in an endless mail loop the next time somebody sends mail to harvestme@spambait.example.com, or will they decide (at least after one or two iterations) that they've seen the message twice so they'll drop it or try to send bouncemail to the original (presumably fake) spammer's address?
Of course, even if you can't get the spammers in a strict loop, telling relay1 to that your machine's ip address is that of relay 2, relay2 that it's relay3, relay3 that it's relay4,..., should at least leave the Korean Spam Relays talk to each other and slowing down the number of messages they can send to real people.
The various Privacy Acts limit what the Feds can do with your SSN (not very effectively), and also limit what the states can do (also not very effectively). There are states that put your SSN on your driver's license, either as the DL# or as additional information. In some of those states you can bully them into using a different number, if you're willing to escalate through N bureaucrats (you still have to provide the SSN, but it doesn't have to go on the card.) This used to be optional, but in the mid-80s the Feds allowed states to make providing the SSN mandatory, and since then they've generally used Federal highway pork-barrel money as leverage to get the states to require it even if they don't need it themselves (not only makes it more useful as a National ID, but makes it harder for people to get multiple licenses simultaneously, and to make it harder for people who lose their license in one state to get another license in another state.)
Any grocery store that I've been in which had club cards also had a cash machine. The only time I've had information crossover issues there was when the cash machine was down and I happened to be low on cash. Otherwise there's no correlation between a transaction that I might have made with Wells Fargo and the grocery purchase the same night that John Doe made, but the grocery store still gets to correlate whether the John Doe who buys tofu and vegetables also buys cheap beer, good beer, or white wine, and whether the heavily advertised sale on red meat has any correlation with John Doe's purchases of tortillas or charcoal or potato chips or Wired Magazine.
Slashdot Mirror
The big reason that I want a small Linux distribution instead of a 15-CD RedHat set is so I can run Linux on wimpy machines. I've got a number of antiques hanging around my lab doing nothing, and few of the Pentium60s and none of the 486s have CDROMs, and all of them have wimpy disk drives. Netbooting is important - it makes it possible to install the basic operating system on a small machine and get it up and running, with the disks partitioned enough to install any other software.
It's also important to have distributions that can install the basic system from one CD! (Or alternatively, at least to be able to install it from separate CDs that aren't all merged into one ftp directory.) Even most of my server machines don't have enough space to copy multiple CDs to one filesystem for FTP, so it's also really important to be able to work with separate CD images - ideally to mount the CDROM and publish it with FTP, or at least to have the different CD images stashed in different directories (which also makes it possible to do two-CD sets by storing one in ~ftp/pub/linux/cd1/ and symlinking or mounting the CDROM for the other disk.)
use Google to look for Penguins and skip over all that Linux stuff. You'll get to things like Pete and Barbara's Penguin Pages
But if there's even *one* cellphone network in your area that broadcasts timesync, and if the protocols support receiving it without sending back reply packets, it should be pretty cheap to build a receiver that listens to it to incorporate in whatever device you want.
"Drive-by-spamming" has been the common term for this - because it is an obvious risk.
* If you're somebody the police would like to entrap, *then* they might go engaging in suspicious activities on your wireless network as an excuse to get a warrant, but most people in that situation know enough to be worried....
It's still line-of-sight, so you won't be visible outside the area except for the smoke signals caused by fried birds and trees and airplanes. But you're really just talking about a microwave oven that's a bit less concerned about limiting its cooking area.
The so-called technical white paper was one of the worst I've seen in ages.
It's possible that the GSM crack did - I'm not sure if the pseudo-code that Ian analyzed over lunch one day, which he got off the net, was originally posted by somebody who violated his licenses in the process (or at least, how *badly* the alleged poster allegedly violated the alleged licenses :-), or whether the poster had access to the code because of a procedurally or contractually careless licensee. But even if that was the case, anybody who seriously wanted to crack the code could have probably grubbed the crypto algorithm off the chip in a phone, at the cost of a phone and a bunch of expensive chip-shredding hardware, though some of the authentication algorithms might have required examining a base station if they had been designed asymmetrically.
And I didn't bother pointing out that because these folks have no clue what a mathematical proof is, they didn't bother showing how their system preserves the properties of a OTP algorithm.
Diffie-Hellman and El-Gamal are closely enough related to RSA that you don't get much diversity by picking them. Elliptic Curve is a nice possibility, though it's possible somebody will find the math to crack that. NTRU is a lot different - I don't know that any of the academic cryptographers are calling it really secure yet, but the people who've looked at it don't seem to be calling it "snake oil" either.
Your Visa number probably isn't worth spending a $1B to crack, so you don't need to worry. Visa, on the other hand, has to worry about millions of credit card numbers getting stolen, though it's still much easier to crack into most of the machines on the web that absorb credit card numbers, and if there's one master key that lets you steal all of Visa (I doubt there is), it's probably easier to find the people who have parts of that key and bribe them (if you're the Mafia), or subpoena them, if you're the sleazy bunch of thugs at the DoJ who just filed a "Go Fish" subpoena on Visa and American Express.
While it's not going to be on the same price curve as high-volume PC production, there are still Moore's Law effects here - the price/performance of FPGAs and ASICs keeps decreasing as technology improves, and the price of smaller-width chip design keeps improving. The real question is whether the development of this sort of machine can piggyback on other hardware development, plus how motivated is the NSA to build it as further research indicates whether or not it will be really useful...
It'll really be interesting when they start to get to ~64-bits of resolution (at least if they don't run into Heisenberg uncertainty problems when the resolution approaches Planck's constant.) Will the resolution of this technology scale that far? But things don't get interesting for public-key crypto until you're at ~512 bits.
Also, there are some problems that quantum computers can accelerate and some that it can't. For instance, factoring is tractable, if you've got enough resolution, and there's a quantum computer that was able to factor the number 15 into 5 and 3. So RSA and Diffie-Hellman are toast, at least for 4-bit keys :-) Perhaps for much longer keys, if QC can be developed, but perhaps not. It's not clear whether elliptic curves can be cracked by quantum computers, but then, it's not clear that they can't be cracked by better mathematics.
Basically, if They can crack everything using public-key technology, you're back to private-key methodology like Kerberos, or traditional methods like one-time pads and guys with Kevlar briefcases handcuffed to their wrists.
The NSA has the advantage of occasionally being able to spend a billion dollars on chips or machine design, which says that building something like the EFF's DES $250K cracker was done at NSA long before the public got there (though "long before" has Moore's Law implications...). They also have some good mathematicians focusing on problems like this, not only because they like to crack other governments' codes but also because they need serious estimates of the strengths of the codes they use, but the general opinion in the crypto community is that they're no longer particularly far ahead of the open academic world, and in some ways they're behind because it's hard to get good peer review on secret algorithms, and it's hard to get and keep good mathematicians if you don't let them publish and don't pay them much money either. I don't believe they had the ability to crack 1024-bit RSA or Diffie-Hellman keys before Bernstein's paper came out - but they *do* have Bernstein's paper now :-)
The basic question is whether it's worth doing a two-or-three-algorithm solution as opposed to just making your keys longer. Depends a lot on your threat scenarios. Are you worried about the NSA cracking a key during your lifetime? Or are you running a bank and worried about bank robbers forging withdrawals? Or are you worrying about somebody forging your signature on an article on Slashdot? :-)
It turns out that it's easier to make signature systems use multiple algorithms than encryption systems - all you do is create a tuple of Sigalgo1(message,key1),Sigalgo2(message,key2)... as your signature (and use a representation that doesn't let the Bad Guy change how many bits of the signature string are interpreted as belonging to each algorithm) and there's none of this nesting business required that encryption systems use.
Computers, as proposed here *are* being used in conjunction with deep analysis - that's why the amount of computation required may have just dropped significantly. Reverse engineering doesn't really apply in this world, unless you're reverse engineering God's excellent job of making factoring difficult large numbers and interesting. :-) If you're doing some obscurity-based approach that requires reverse engineering, you've blown your chance at modern crypto work... Most of the public-key systems work by applying known hard algorithms in ways that let the work required to crack them be computationally infeasible, and it's understood that that's a shifting boundary - usually the crackers blow a dozen or so bits off the strength limits per year (some with faster computers, some with mathematical analysis), but the encryptors can add several hundred bits per year to the practical strength - doubling the number of key bits roughly quadruples the computation required, but you could do 512 bits conveniently enough on an 8086, so 2048 is no problem today, unless you've got packet size limitations which make that annoying, or unless you've got antique code that nobody wants to update for longer keys (particularly if the code is a silicon implementation of a bignum mulitplier), or unless you're running a web site that has to process a large number of connections per second, in which case this costs you actual money.
Use a long key - yes. Develop your own algorithm - no. Even the GSM telephone people and DVD encryption, which were theoretically developed by trained professionals, were total crockery. GSM had no excuse - the DVD folks could at least argue that the problem they were trying to solve is inherently hard and they were using double protection - a cheapo algorithm and expensive lawyers to run the DVDCSS lawsuits. But the GSM folks were working in well-established territory for which there are straightforward commercial-quality solutions available.
Dr. Zowie's description of the problem sounded like something that can be worked around, at least for some cases - which is why he may need to work with the transparent-proxy's vendor and not just the ISP. The two big problems are using the correct DNS lookup, and having old data in caches. Cache aging strategy is a standard problem - some systems do better or worse jobs of managing it, and some give you workarounds. (For instance, the proxy I use at work seems to respond to "Reload" requests from the browser and refresh its contents.) DNS lookup problems are really a bug - if the browser sends an http request to 192.9.200.1 for foo.bar.altroot/zap.html, it's certainly easier to implement by having the proxy forget the original packet's IP address, see if they have the page cached, and re-resolve the URL if not, but it's also a bug - they could keep track of the IP address as well as the URL. The bugginess of the dumb approach is most apparent with alternate-roots, but it can also be a problem for URLs at domains with round-robin DNS, where requests can go to any of the IPs in the group, but multiple requests need to all go to the same server for consistency, either because of stateful requests or because the servers aren't running with identical content names (e.g. for dynamic pages.) (One can argue that the servers are buggy in that case, but that doesn't mean that the caching proxy's behaviour isn't also buggy.)
If you can use a tunnel server, like IPSEC or PPTP or SSH, which lets you pick the IP address to send your IP packets to but doesn't interpret the packets itself, you'll mostly be ok (you'll still have to make sure to do your own DNS if you want to resolve on alternate roots.)
In one of the cases discussed here, the spammer got really upset about being dragged into discovery about his spamming. But many ISPs keep SMTP forwarding logs. Can you use discovery subpoenas to get *them* to produce their log files for a small claims case? That would be an interesting way to go after the spammers who are their customers, if their abuse people aren't helpful enough.
Of course, the problem with transparent servers is when they're not, and your ISP seems to have one that isn't. Is it possible to find out what kind it is, either by telnetting to the thing and looking at headers or by asking the ISP, and can you do bug reports to the vendor to get them to fix their product?
Of course, even if you can't get the spammers in a strict loop, telling relay1 to that your machine's ip address is that of relay 2, relay2 that it's relay3, relay3 that it's relay4, ..., should at least leave the Korean Spam Relays talk to each other and slowing down the number of messages they can send to real people.
Any grocery store that I've been in which had club cards also had a cash machine. The only time I've had information crossover issues there was when the cash machine was down and I happened to be low on cash. Otherwise there's no correlation between a transaction that I might have made with Wells Fargo and the grocery purchase the same night that John Doe made, but the grocery store still gets to correlate whether the John Doe who buys tofu and vegetables also buys cheap beer, good beer, or white wine, and whether the heavily advertised sale on red meat has any correlation with John Doe's purchases of tortillas or charcoal or potato chips or Wired Magazine.