Again, why is I have to come to slashdot to find a d.net URL? Why is there no reference (as of 2:08am ET Sunday 1/16/2000) on the main web page, the main CSC page, the CSC stats page, anyone's.plan, and nothing CSC related in sight in/pressroom?
This makes me wonder what else may be hiding in their html directory.
Their "security" doesn't stand up to even the simplest analysis. No debugger or disassembly is required to figure out how the blocks are being scrambled. Unfortunately, DCTI's existance depends on that scrambling remaining a secret. Once the world knows how it works, DCTI is doomed. There's no way they could prevent cheating. And there's no way they could replace the technology fast enough to keep a user base. (Plus, that would necessitate replacing every client in existance.)
The more code they release, the easier it gets to recover the block scrambler technology. That not withstanding, there's a lot of code they are sitting on that could be released. The only file(s) that must be protected are those linked with block scrambling.
PS: The "scambler technology" was written by Duncan (Adam Beberg) years ago -- long before DCTI existed. Yet, DCTI claims ownership of those few dozen lines of code.
Yes, "people" make mistakes. However, most people fix their mistakes and don't hide behind them. DCTI has had numerous events of this nature (tho' most aren't this severe.) It's become an almost defacto standard to cover everything up. How many remember the bug found in the RC5 ultra core? I cannot find any mention of it at all in the.plans despite Remi talking about it. [It was converted from the alpha core and there was a slight error that caused it to increment keys incorrectly with the net result of part of the key block having never been checked. Every block submitted by a client that _could_ have been affected got reprocessed. Unfortunately, that meant throughing away the work of _every_ sparc of that version -- even those that didn't use that core as there was no way to tell if it was an ultra or non-ultra client.]
So, how much other shit have they not told anyone about?
Oh please. DNET is a dying cow for various reasons. Their biggest problem is their lack of speed in getting anything done. They had a CSC core long before they deployed it. They've been working on OGR for two years (I was the first person to work on it.) They've had very simple solutions to prevent "cheating" for years yet they've done nothing. It's taken how long to get updated clients and some still haven't been updated? They want their name plastered all over everything but they fail to give credit to those who have contributed to their work. I did some work to retool the stats processing, but I guess it made nugget look too bad as no one ever looked at it -- a full days run can be done in less than 15 minutes and not require gigs of "temp" space; in fact, sans ranking, it could be near real-time. And to make matters worse, they "secretly" harrass their founder and former president for several months over a domain name they never used and never will. I bet you didn't know DCTI filed three suits against Adam L. Beberg, Mithral Communications and Design, Inc., and "those in concert therewith" a few weeks ago -- right before Christmas.
Bovine's explaination of netrek only shows his lack of understand of how "blessed binaries" work(ed). There is no "date" in the key itself. Expiration is completely artificially added by the key service agent along with other bits of data -- it was not to prevent people from recovering the secret key but more to push people to upgrade their client(s). Netrek uses (used) 128bit RSA numbers ("secret key", "private key", and "public key"). In the modern world, factoring a 128bit RSA number is not difficult. Recovering the secret key embeded in the client is _NOT_ easy. Unlike Xing, the key is not in one place; it's randomly scattered throughout a very large static binary. (The key is generated and destroyed by the build.) In ten years of working with netrek, I've never known of anyone to recover the key from the client. I have personally regenerated the secret key by factoring the public data, but that was (at the time) a very non-trivial task.
I must admit, I'm starting to truely dislike DCTI and their current attitude. The CSC clients are duplicating work. They don't tell anyone this until it's obvious -- over 100% of the blocks have been checked in. They continue to have trouble with stats -- two years and counting now.
What's this about "have to patch my kernel twice"?
DevFS was doomed to failure from day one. How do you expect the kernel to know what devices will _ever_ be available? It certainly easy enough for loaded and/or active drivers, but what about modules? For a module to be automatically loaded, the device node will have to already exist. Maybe _I_ want weird names for my devices?
That stupid law (or interpretation of it) only applies to ENCRYPTION not DECRYPTION. That being said, I don't think the problem is US law. I would venture it's a matter of laws in other contries and the amount of processing power necessary for more powerful cryptographic systems.
For the record, CSS is not "encryption" any more than ROT13 can be called encryption. The keys for the whole mess is right there on the disk. Hardware players don't go through any of this mess; they read the "key" right off the disk and get on with it.
Ya' know, that's interesting. Where can one buy tampons these days?
Grocery stores
Drug stores
"Super Stores" -- Wal-Mart, K-Mart, et. al.
Sam's Club(??)
When you think about it, there are very few places to buy feminine hygiene products. Should we form a petition to have Fry's stock feminine hygiene products?
I would venture a guess that they want to show people what a cluster of Alphas can do -- we know what a farm of alphas can do (see also: Digital Domain -- they did some of the Titanic rendering)
Well, I'd look at any BeOS numbers with a bit of disregaurd... BeOS was never designed to be the end-all-be-all server OS. The vast majority of people running BeOS turn their machine off when they're done "playing."
As for my own BeOS usage... I've seen BeOS (4.5.2) get messed up to the point I had to reboot -- NetPositive did something "very wrong" and none of it's windows would ever go away even when it wasn't running. The BeOS is alot like UNIX in many respects; if something crashes, start it back up again -- the "kernel" is a very sound creature.
It's marketing "buzz"... if one schmuck can duplicate a 10$ DVD, the DVD industry shits a kitten despite the fact that it cost the "pirate" 30$ a disk plus a few hundred (or thousand) dollars for the burner. End users copying DVD movies to a hard drive is such a microscopic spec on the profit margins of the DVD industry that it makes no sense for them spend this much time and money preventing it.
It's the people with the technology and man-power to reconstruct a DVD master and cut thousands of disks a day that pose a threat. The CSS bullshit does absolutely nothing to prevent this kind of large scale piracy. This type of thing already exists in the CD audio world -- and in a form in the VHS tape world.
The release of DeCSS has not hurt the DVD industry; it's actually done the opposite. DeCSS has allowed a wider market of users to play their DVDs. The intent is, was, and always will be to play the damned movieNOT duplicate, mass produce, or "pirate" DVD movies. Unless DVD CCA can produce some hard, provable figures for the damage to the DVD industry, I'd say kick their ass out of the court room and fine them for wasting my tax dollars.
This is especially true for those (few) of us who can "read" byte code. I guess looking at the hex dump of a program is illegal now? What's next, paying a few to read road signs?
Companies need to get this through their micro-brain: Trade Secrets are not protected by the law.
It is the resposibility of the company to take steps to protect their properties -- both disclosed and non-disclosed. This is done by legally binding contracts -- NDA agreements, employment contracts, copyright, trademarks, patents, etc.
In the case of CSS -- which is not encryption but merely scrambling -- the methods for scrambling the data on the DVD as well as authenticating one self to the drive to merely access the protected data were not disclosed by the DVD Forum to anyone not bound by NDA -- and certainly NOT for free. The only ones who can be held legally resposible for "leaking" the CSS methods are those bound by the NDA. No one listed on the DVD CCA order is bound by such an agreement.
This then becomes a matter of putting the smoke back in the chip -- so to speak. The "secret" held by the DVD Forum and licensed by DVD CCA is no longer a secret. As the information was gained by the reverse engineering of a software product by individuals outside the jurisdiction of US law, I don't see how a US court can prevent the disclosure of this worthless "copy protection."
The only true and relevant point-of-fact in the court filing is that the DVD CCA's "business" is harmed by this disclosure. HOWEVER, DVD CCA is a not-for-profit agent of the DVD Forum (a for lots of profit org). If CSS is the only thing they sell, then their business plan is flawed -- read: doomed to fail from the beginning. The claims made by DVD CCA (and the entire DVD Forum) are unfounded and unsupportable; no proof exists to support most of their claims.
Yes, it's insane. However, seeing as the netscape source code is 127M!... If one installs everything on the Redhat 6.1 x86 CD, you'd lose about 1.3GB. I've never installed the entire source code, but I'm venturing a guess that it'd be around 4x that size. The Linux kernel is an enormous snowball of code -- there's what, nine arch's in the tarball? Glibc... I'm not gonna go there. [I'll give it a go tonight if the AccelRAID 150 doesn't lock up again #$%@$]
As for "just type make"... nothing is ever that simple. Someone/thing has to install the source code first. "rpm --rebuild" isn't that much different, but it is a redhat-ism. As it was explained to me a year ago, the FreeBSD "make world" will download the missing source code (via cvs.)
But this still doesn't answer my previous question: Why would you want to rebuild your entire distribution?
All I can say is the first linux system I installed back in '91 was from a single floppy download. It ftp'ed everything it needed to install and went on it's merry way.
If this is true, why isn't it documented somewhere obvious?
Actually, that "fucking RPM crap" just wraps up the original source tarball and all the bugs^Wchanges done by Redhat (etc.)
The RPM crap is mostly a Redhat-ism. Other dists have started using it, but some don't. As I recall, slackware is all tarballs and yes, you can do a "make world"-ish rebuild everything.
This begs the question, "why would you want to?" How often do you have the need to rebuild everything on your hard drive?
Redhat (assuming you have a few spare gigs of HD for all the source)...
rpm --rebuild
REBUILD AND RECOMPILE OPTIONS There are two other ways to invoke rpm:
rpm --recompile +
rpm --rebuild +
When invoked this way, rpm installs the named source pack- age, and does a prep, compile and install. In addition, --rebuild builds a new binary package. When the build has completed, the build directory is removed (as in --clean) and the the sources and spec file for the package are removed.
Being someone who owns OS-9/6809 and OS-9/68k (granted old as hell versions, but...), I can say it _is_ causing confusion. They lost on a technicallity... there's a perceived difference between a "Consumer OS" and an "RTOS". I used OS-9 as my "desktop" for 10 years! It's a great little OS.
Personally, I think it stinks that Microware lost. They've had a trademark on "OS-9" for over 25 years. I personally know several of the people who wrote the original OS-9/6809.
"A 29 byte udp packet still uses 1500 bytes of bandwidth." Please read some documents on ethernet before you say such things. This is 100% not true. "Frame"s are variable sized; "Cell"s are fixed sized.
The MINIMUM size for an ethernet frame is 64bytes. The MAXIMUM size for an ethernet frame is somewhere over 1500bytes (1514 I think.) The number "1500" is the maximum MTU (Maximum Transmit Unit -- the largest amount of data to be place in a single packet) for the OSes networking layer -- it can be set lower.
The OS generally handles the 64byte min. by padding the packet to 64bytes before handing it to the ethernet hardware. The lower limit is there to handle collision detection with maximum cable lengths. Basically, the transmitter needs to still be active when the signal reaches the end of the cable to be able to detect a collision. Of course, that only makes sense (to me at least) in the 10base-2 (coax) world where collisions are detected by the current placed on the wire.
As for what goes on inside the cable modem network, your guess is about as good as mine. I would assume the technology is somewhat like ATM, but I have no idea. Anyone know how the cable modem works?
This is an "MTU Path Discovery" exploit. When one machine wants to talk to another machine it's best to know how big a packet each can send without it being fragmented (broken into smaller packets to cross any given link.) The MTU for ethernet is 1500 -- you can set it lower if you want, but larger is good way to crash your machine. Not all router links in the world can handle a 1500 byte packet without fragmentation.
SO, at the beginning of a connection, the computers at the endpoints attempt to determine the largest packet they can send without fragmentation. This is done by setting the "DF" (do not fragment) bit in the IP header. They then "listen" for ICMP messages indicating the packet would have to have been fragmented to get there. The packet would then be retransmitted with less data in it.
This packet is usually generated by a router somewhere in between. It would appear there is a way to "trick" MacOS 9 into sending out a 1500byte packet to "do an MTU discovery". Personally, this sounds like a cut-n-dry ("oops") bug... 1500 byte ICMP packets would likely be dropped by any number of routers (see RFC1122 and RFC1812 for the rules governing ICMP messaging) AND, the report doesn't say anything about which ICMP message was being generated (there are 15 types of ICMP messages defined under Solaris 2.6 -- 13 under linux)
Disclaimer: I've never used MacOS 9 nor have I seen any of it's network code. The above explaination is "in theory" only and does not necessarily indicate how any OS actually handles MTU path discovery.
Slashdot Mirror
Again, why is I have to come to slashdot to find a d.net URL? Why is there no reference (as of 2:08am ET Sunday 1/16/2000) on the main web page, the main CSC page, the CSC stats page, anyone's .plan, and nothing CSC related in sight in /pressroom?
This makes me wonder what else may be hiding in their html directory.
C++ actually.
Their "security" doesn't stand up to even the simplest analysis. No debugger or disassembly is required to figure out how the blocks are being scrambled. Unfortunately, DCTI's existance depends on that scrambling remaining a secret. Once the world knows how it works, DCTI is doomed. There's no way they could prevent cheating. And there's no way they could replace the technology fast enough to keep a user base. (Plus, that would necessitate replacing every client in existance.)
The more code they release, the easier it gets to recover the block scrambler technology. That not withstanding, there's a lot of code they are sitting on that could be released. The only file(s) that must be protected are those linked with block scrambling.
PS: The "scambler technology" was written by Duncan (Adam Beberg) years ago -- long before DCTI existed. Yet, DCTI claims ownership of those few dozen lines of code.
Yes, "people" make mistakes. However, most people fix their mistakes and don't hide behind them. DCTI has had numerous events of this nature (tho' most aren't this severe.) It's become an almost defacto standard to cover everything up. How many remember the bug found in the RC5 ultra core? I cannot find any mention of it at all in the .plans despite Remi talking about it. [It was converted from the alpha core and there was a slight error that caused it to increment keys incorrectly with the net result of part of the key block having never been checked. Every block submitted by a client that _could_ have been affected got reprocessed. Unfortunately, that meant throughing away the work of _every_ sparc of that version -- even those that didn't use that core as there was no way to tell if it was an ultra or non-ultra client.]
So, how much other shit have they not told anyone about?
Oh please. DNET is a dying cow for various reasons. Their biggest problem is their lack of speed in getting anything done. They had a CSC core long before they deployed it. They've been working on OGR for two years (I was the first person to work on it.) They've had very simple solutions to prevent "cheating" for years yet they've done nothing. It's taken how long to get updated clients and some still haven't been updated? They want their name plastered all over everything but they fail to give credit to those who have contributed to their work. I did some work to retool the stats processing, but I guess it made nugget look too bad as no one ever looked at it -- a full days run can be done in less than 15 minutes and not require gigs of "temp" space; in fact, sans ranking, it could be near real-time. And to make matters worse, they "secretly" harrass their founder and former president for several months over a domain name they never used and never will. I bet you didn't know DCTI filed three suits against Adam L. Beberg, Mithral Communications and Design, Inc., and "those in concert therewith" a few weeks ago -- right before Christmas.
Bovine's explaination of netrek only shows his lack of understand of how "blessed binaries" work(ed). There is no "date" in the key itself. Expiration is completely artificially added by the key service agent along with other bits of data -- it was not to prevent people from recovering the secret key but more to push people to upgrade their client(s). Netrek uses (used) 128bit RSA numbers ("secret key", "private key", and "public key"). In the modern world, factoring a 128bit RSA number is not difficult. Recovering the secret key embeded in the client is _NOT_ easy. Unlike Xing, the key is not in one place; it's randomly scattered throughout a very large static binary. (The key is generated and destroyed by the build.) In ten years of working with netrek, I've never known of anyone to recover the key from the client. I have personally regenerated the secret key by factoring the public data, but that was (at the time) a very non-trivial task.
I must admit, I'm starting to truely dislike DCTI and their current attitude. The CSC clients are duplicating work. They don't tell anyone this until it's obvious -- over 100% of the blocks have been checked in. They continue to have trouble with stats -- two years and counting now.
What's this about "have to patch my kernel twice"?
DevFS was doomed to failure from day one. How do you expect the kernel to know what devices will _ever_ be available? It certainly easy enough for loaded and/or active drivers, but what about modules? For a module to be automatically loaded, the device node will have to already exist. Maybe _I_ want weird names for my devices?
That stupid law (or interpretation of it) only applies to ENCRYPTION not DECRYPTION. That being said, I don't think the problem is US law. I would venture it's a matter of laws in other contries and the amount of processing power necessary for more powerful cryptographic systems.
For the record, CSS is not "encryption" any more than ROT13 can be called encryption. The keys for the whole mess is right there on the disk. Hardware players don't go through any of this mess; they read the "key" right off the disk and get on with it.
Grocery stores
Drug stores
"Super Stores" -- Wal-Mart, K-Mart, et. al.
Sam's Club(??)
When you think about it, there are very few places to buy feminine hygiene products. Should we form a petition to have Fry's stock feminine hygiene products?
They FedEx'ed me a "JAVA" license plate -- what a rip off :-) I guess they ran out?
I would venture a guess that they want to show people what a cluster of Alphas can do -- we know what a farm of alphas can do (see also: Digital Domain -- they did some of the Titanic rendering)
Well, I'd look at any BeOS numbers with a bit of disregaurd... BeOS was never designed to be the end-all-be-all server OS. The vast majority of people running BeOS turn their machine off when they're done "playing."
As for my own BeOS usage... I've seen BeOS (4.5.2) get messed up to the point I had to reboot -- NetPositive did something "very wrong" and none of it's windows would ever go away even when it wasn't running. The BeOS is alot like UNIX in many respects; if something crashes, start it back up again -- the "kernel" is a very sound creature.
(BeOS isn't multi-user, however.)
Guys, you forgot kitty-litter!
It's marketing "buzz"... if one schmuck can duplicate a 10$ DVD, the DVD industry shits a kitten despite the fact that it cost the "pirate" 30$ a disk plus a few hundred (or thousand) dollars for the burner. End users copying DVD movies to a hard drive is such a microscopic spec on the profit margins of the DVD industry that it makes no sense for them spend this much time and money preventing it.
It's the people with the technology and man-power to reconstruct a DVD master and cut thousands of disks a day that pose a threat. The CSS bullshit does absolutely nothing to prevent this kind of large scale piracy. This type of thing already exists in the CD audio world -- and in a form in the VHS tape world.
The release of DeCSS has not hurt the DVD industry; it's actually done the opposite. DeCSS has allowed a wider market of users to play their DVDs. The intent is, was, and always will be to play the damned movie NOT duplicate, mass produce, or "pirate" DVD movies. Unless DVD CCA can produce some hard, provable figures for the damage to the DVD industry, I'd say kick their ass out of the court room and fine them for wasting my tax dollars.
This is especially true for those (few) of us who can "read" byte code. I guess looking at the hex dump of a program is illegal now? What's next, paying a few to read road signs?
Companies need to get this through their micro-brain: Trade Secrets are not protected by the law.
It is the resposibility of the company to take steps to protect their properties -- both disclosed and non-disclosed. This is done by legally binding contracts -- NDA agreements, employment contracts, copyright, trademarks, patents, etc.
In the case of CSS -- which is not encryption but merely scrambling -- the methods for scrambling the data on the DVD as well as authenticating one self to the drive to merely access the protected data were not disclosed by the DVD Forum to anyone not bound by NDA -- and certainly NOT for free. The only ones who can be held legally resposible for "leaking" the CSS methods are those bound by the NDA. No one listed on the DVD CCA order is bound by such an agreement.
This then becomes a matter of putting the smoke back in the chip -- so to speak. The "secret" held by the DVD Forum and licensed by DVD CCA is no longer a secret. As the information was gained by the reverse engineering of a software product by individuals outside the jurisdiction of US law, I don't see how a US court can prevent the disclosure of this worthless "copy protection."
The only true and relevant point-of-fact in the court filing is that the DVD CCA's "business" is harmed by this disclosure. HOWEVER, DVD CCA is a not-for-profit agent of the DVD Forum (a for lots of profit org). If CSS is the only thing they sell, then their business plan is flawed -- read: doomed to fail from the beginning. The claims made by DVD CCA (and the entire DVD Forum) are unfounded and unsupportable; no proof exists to support most of their claims.
Gez, NO IT ISN'T. The "1500 byte packet" is the thing being handed to the ethernet driver -- data + UDP header + IP header.
We just keep breeding better idiots...
Maybe they had Christmas and Halloween mixed up?
- The 300-pound Parenti was heading to a neighborhood in Tocopilla, 960 miles north of Santiago...
Was that the nearest city they could point out on a map? Gez. That makes it sound like Santa had one hell of a road-trip ahead of him.And, umm, what were you thinking :-) (Granted, I wasn't thinking "stoning" either.)
Couldn't be please dispense with babytalk?
no.
Yes, it's insane. However, seeing as the netscape source code is 127M!... If one installs everything on the Redhat 6.1 x86 CD, you'd lose about 1.3GB. I've never installed the entire source code, but I'm venturing a guess that it'd be around 4x that size. The Linux kernel is an enormous snowball of code -- there's what, nine arch's in the tarball? Glibc... I'm not gonna go there. [I'll give it a go tonight if the AccelRAID 150 doesn't lock up again #$%@$]
As for "just type make"... nothing is ever that simple. Someone/thing has to install the source code first. "rpm --rebuild" isn't that much different, but it is a redhat-ism. As it was explained to me a year ago, the FreeBSD "make world" will download the missing source code (via cvs.)
But this still doesn't answer my previous question: Why would you want to rebuild your entire distribution?
All I can say is the first linux system I installed back in '91 was from a single floppy download. It ftp'ed everything it needed to install and went on it's merry way.
If this is true, why isn't it documented somewhere obvious?
Actually, that "fucking RPM crap" just wraps up the original source tarball and all the bugs^Wchanges done by Redhat (etc.)
The RPM crap is mostly a Redhat-ism. Other dists have started using it, but some don't. As I recall, slackware is all tarballs and yes, you can do a "make world"-ish rebuild everything.
This begs the question, "why would you want to?" How often do you have the need to rebuild everything on your hard drive?
Redhat (assuming you have a few spare gigs of HD for all the source)...
rpm --rebuild
REBUILD AND RECOMPILE OPTIONS
There are two other ways to invoke rpm:
rpm --recompile +
rpm --rebuild +
When invoked this way, rpm installs the named source pack-
age, and does a prep, compile and install. In addition,
--rebuild builds a new binary package. When the build has
completed, the build directory is removed (as in --clean)
and the the sources and spec file for the package are
removed.
Being someone who owns OS-9/6809 and OS-9/68k (granted old as hell versions, but...), I can say it _is_ causing confusion. They lost on a technicallity... there's a perceived difference between a "Consumer OS" and an "RTOS". I used OS-9 as my "desktop" for 10 years! It's a great little OS.
Personally, I think it stinks that Microware lost. They've had a trademark on "OS-9" for over 25 years. I personally know several of the people who wrote the original OS-9/6809.
"A 29 byte udp packet still uses 1500 bytes of bandwidth."
Please read some documents on ethernet before you say such things. This is 100% not true. "Frame"s are variable sized; "Cell"s are fixed sized.
The MINIMUM size for an ethernet frame is 64bytes. The MAXIMUM size for an ethernet frame is somewhere over 1500bytes (1514 I think.) The number "1500" is the maximum MTU (Maximum Transmit Unit -- the largest amount of data to be place in a single packet) for the OSes networking layer -- it can be set lower.
The OS generally handles the 64byte min. by padding the packet to 64bytes before handing it to the ethernet hardware. The lower limit is there to handle collision detection with maximum cable lengths. Basically, the transmitter needs to still be active when the signal reaches the end of the cable to be able to detect a collision. Of course, that only makes sense (to me at least) in the 10base-2 (coax) world where collisions are detected by the current placed on the wire.
As for what goes on inside the cable modem network, your guess is about as good as mine. I would assume the technology is somewhat like ATM, but I have no idea. Anyone know how the cable modem works?
This is an "MTU Path Discovery" exploit. When one machine wants to talk to another machine it's best to know how big a packet each can send without it being fragmented (broken into smaller packets to cross any given link.) The MTU for ethernet is 1500 -- you can set it lower if you want, but larger is good way to crash your machine. Not all router links in the world can handle a 1500 byte packet without fragmentation.
SO, at the beginning of a connection, the computers at the endpoints attempt to determine the largest packet they can send without fragmentation. This is done by setting the "DF" (do not fragment) bit in the IP header. They then "listen" for ICMP messages indicating the packet would have to have been fragmented to get there. The packet would then be retransmitted with less data in it.
This packet is usually generated by a router somewhere in between. It would appear there is a way to "trick" MacOS 9 into sending out a 1500byte packet to "do an MTU discovery". Personally, this sounds like a cut-n-dry ("oops") bug... 1500 byte ICMP packets would likely be dropped by any number of routers (see RFC1122 and RFC1812 for the rules governing ICMP messaging) AND, the report doesn't say anything about which ICMP message was being generated (there are 15 types of ICMP messages defined under Solaris 2.6 -- 13 under linux)
Disclaimer: I've never used MacOS 9 nor have I seen any of it's network code. The above explaination is "in theory" only and does not necessarily indicate how any OS actually handles MTU path discovery.