You fail to understand the essence of good system (and web) design. Things should fail gracefully. You can use all W3C approved features, but you need to design the web page so that it is stil navigable if the fancy features fail. Look at the cingular website for an example of this done very poorly. If you use anything that doesn't identify itself as Netscape, the javascript routines become very ie-specific, so you can't get any deeper than the front page is you're using Mozilla.
If your webpage is unusable in Lynx, that's a bug in your webpage. It doesn't have to be pretty in Lynx, but SSL-enabled Lynx users should still be able to select products and buy them. Go ahead and do pretty things with the newest approved W3C features, but they need to not be critical. Sure, go ahead and make it ugly on anything but Netscape and IE. People using alternative browsers really don't care, nd to be honest, if it looks good in Netscape and is usable in Lynx, almost any alternative browser user will be very happy. And for the love of Jebus, is you have to make multiple versions of a webpage, then make the Netscape one the default if you can't figure out what browser they're using. Netscape/Mozilla rendering is pretty close to the target alternative browsers are shooting for (as in Mozilla is much much closer to a W3C compliant renderer).
These are basic principles of software engineering. You need graceful failure. Sure strict HTML isn't Turing complete, but the principles still apply. Take a system design class sometime. I'm not saying good web design is easy. I'm saying that too many special cases is a general warning in system design, and it carries over into web design. Think of browser-specifics as hacks. Sometimes you need a hackto meet a deadline, but hacks are bad, Ugly webpages are better than unnavigable webpages.
Microsoft has been convicted of illegally busing its monopoly in violation of the Sherman Anti-trust act. They are not free to do whatever they want. They've shown an inability to play nicely with other children and now have to go sit in the corner.
making good HTML isn't part of the settlement, but as a part of a continuing pattern, this could land MS in legal trouble. (It won't 'cause it's too minor to prosecute, just like jaywalking is seldom prosecuted.)
First, the interfaces and abstractions in *NIX are much cleaner. MS breaks abstraction layers all the time for performance reasons. *NIX tends to be muchmore modular, particualrly OSS, since there is little interdependence between projects. Not so for MS applications.
Secondly, OSS project leads do it because they love it. They tae pride in thier work. All of thier work is unpaid overtime so they don't mind so much putting in unpaid overtime to get back respect for thier pride and joy, and there's no management breathing down thier necks to get the next feature release out the door. How many MS coders or project leads have the authority to stall a project for months just to clean up the code? How many MS coders or project leads would work like slaves for thier code if they got paid less than minimum wage? It's all about the love. It's like a car enthusiast who learns to do his own maintenence vs. the car mechanic getting pressure to hurry it up so that the next car can get fixed.
I know of several people that have had thier oil pan drain plugs stripped by an air wrench and not had the mechanic bother to tell them, only to find a hugepuddle of oil the next morning. That guy down the street that waxes his 'vette every Saturday probably personally changes his oil, if not personally overhauls his own drivetrain. A job is just a job, but a hobby is something you don't rush or do half-assed. It sounds cheesy, but love is what makes hobby software (usually OSS) special. If you get paid to do your hobby, so much the better, but it's still your hobby, not just some job.
The main problem with x86 is multiple-width instructions that prevent eficient parallel instruction decoding. The main point the RISC movement made was that most architectures used to have tons of instructions that were rarely used. An unused instruction still takes up just as many transistors and development time that could be spent elsewhere. When was that last time you saw a modern C compiler spit out x86 BCD instructions (that weren't inline assembly). They might as well have made instructions to do base 13 as well as BCD and binary operations. I centainly hope they've simply made some BCD to/from binary conversion micro-ops and moved all o the BCD handling into microcode.
Consoles are 128-bit and video cards are 2048-bit in the same sense that the G4 and any x86 CPU with MMX, 3DNow, or SSE/SSE2 are 128-bit. You're talking about vector operations. If you count the PS2 as 128-bit, you need to count any x86 with an FPU as an 80-bit CPU (128-bits in the case of chips supporting the aforementioned vector extensions.)
These devices do not directly manipulate 128-bit pointers or 128-bit integers. You can get some cryptographic coprocessors that will do 1024-bit integer operations (and by now, problably 2048-, if not 4096-bit). Heck, a 486 will do 80-bit floating point operations, but we still consider ia32 to be 32-bit systems. For general computing, you're looking at the size of pointers when you talk about the "bit-ness" of a CPU. Vector ops aren't necessarily faster in a superscalar CPU. They happen to be for every CPU I'm aware of, but it's possible to invest those same transistors into more integer/float units and get the same performance (assuming the increased flexability and general performace increase offsets the slight decode/issue overhead you gain by representing vector operations serially but perforing them in parallel). My understanding is that AMD chips simply have blazing fast FPUs and the SSE2 instructions were added in microcode, not transistors.
Some of the HP48G calculators had CPUs with 64-bit accumulators. However, all of the math was done in BCD, and memory access was done a nibble at a time. Don't get me wrong, more bits are great, but my aging PII will take the Pepsi Challenge against an HP48G any day of the week. (My understanding is that most of the HP48G code was interpreted RTL rather than directly executed, allowin them to pretty easily switch CPUs out from under everything. Pretty cool.)
BTW, the GameCube's "Gecko" CPU is 32-bits (64-bit FPU), I believe. I'm not aware of any games that take advantage of 64-bit integers, nor any gaming consoles that need more than 4 GB of virtual memory.
In short, yes, we are talking about the "housekeeping CPU" in a sense. More directly, we're probably talking about the MMU, which isn't necessarily on the same chip as any of the compuational engines.
More importantly, it's very easy to emulate 64-bit integer and 2048-bit vector operations on a 32-bit machine. However, it is much much more difficult to emulate very large address spaces on machines that use 32-bit pointers. One of the reasons the IBM POWER series has had 64-bit pointers from the get-go (While the Power PCs still are 32-bit) is that AIX runs all of the processes in a single adress space (memory protection is done by other means than seperate address spaces. This means you never have to do a TLB flush.) There are some tricks now for ia32 that basically give several 32-bit address spaces to a single process, but it's a real hack.
In summary,it's all about the pointers. Larger FP and integer operations than natively supported are easily done using multiple registers and slighly more time. Pointer operations larger than supported natively by the CPU arevery expensive to do..
Freenet retrieval is too unreliable unless the documents are very popular. Hope that your encrypted data is not a hugely popular download.
P2P can be done securely, depending on your threat model. DOS attacks against P2P systems is still a largely unsolved problem. However you could easily make a system that is for all practical purposes immune to data disclosure. (GPG encrypt your data to yourself befre distributing it, for instance.) I have a nice little perl script that makes a nightly tarball of my CVS repository and GPG-encrypts it, then puts the encrypted tarballup on the web under a filename that contains 64-bits of the md5sum of the unencrrypted tarball. (taken pre-compression). On the backup storage machine, there's a perl script to chck if the md5sum fragment has changed, and if so, use wget to backup the tar ball. (This most defintely isn't P2P, but it deonstrates a simple example of a backup system that lets thee entire world see the backup, yet is for all practical purposes immune to data disclosure.)
If you had a distributed cooperative file system, you could use my perl scripts do do your backups, and the only notable attack (aside from compromise of your machine) would be a DOS/deletion attack against the cooperative filesystem. Of course, you need to chack signatures on the tarballs when you decrypt them.
I was actually talking with one of the Freene developers about his efforts provide distributed encrypted anonymous storage. Unfortunately, the DOS/deletion problem is still unslved, so he was forced to go with storage only on his machines, which means it's not P2P. Most P2P stems are also so transient that you'd need a very high level of replication.
Of course, there's a simple modification to my perl script system that you could make... have it scan random IP addresses for open SMB shares... that would be "non-cooperative distributed filesystems":-P
You're right, it does use 40-bit or 120-bit (MS likes to count the 8 parity bits in addition) DESX.
I hadn't heard of any salt being used. Salts are completely useless if you're using a seperate strongly (pseudo-)random key for each file. If you're not very very careful, the salting may also very slightly reduce your key space.
If you're using an encrypted fielsystem, make sure your password is stored only using the NT hash. By default, both the LM hash and the NT hash of your password are stored in the registry. In the absolute best case, the work foactor is somewhere aroudn 2 ** 56 to break a 14-character strong password. If you password doesn't require you to hold down the alt key while using the nueric keypad, you're most likely looking at a work factor of about 2 ** 37 to crack your password. (Your password is borken into 7-character halves and converted into upper case, then something like an unsalted UNIX crypt algorithm is applied seperately to each half.) Once they have your password, they can decrypt your SK and get all of your files. Game over man, game over.
Microsoft should be applauded for making a default install crypto-filesysm capable. However, per-file encryption falls to some attacks and information leakage that volume-level encryption doesn't suffer from. Swap space and temp files are still a big problem without third-party add-ons.
It's also important to note that RSA Labs designed DESX explicitly as a stop-gap measure until the Advanced Encryption Standard (AES) was decided upon.
MS could also have done the world a great service by including 40-yaer old password salting technology instead of using unsalted password hashes.
IBM used to be the big evil giant, but I have to say I'm really starting to love IBM. I prefer thier JVMs to the official Sun versions. I really hope Apple ships something based on a POWER4 chip soon. IBM does some REALLY cool research and puts lots of money into Linux development.
BTW, while you're at regitering at IBM, pick up Jikes, the 1.4 JVM, and robot wars. All good stuff. They've got some good Linux white papers too.
(Now to get them to use 100% ASCII in thier HTML instead of those stupid MS "smart quotes".)
That MS makes the best software and McD's makes by far the best food on the entire plannet. Britney is the best musician alive, and some huge state school offers an education that far outclasses any Ivy League school. China and India are the best countries in which to live and bud light is the best beer. Ford and GM make the best cars. Excuse me while I finish off my microbrews, escargot, veal, and caviar and find a nice cliff over which to drive my German engineered uberwundercar. If this is the best this planet has to offer, there's no sense in continuing.
It turns out that you now have to register for a Passport account in order to recieve their security alerts. They simply changed this and didn't notify anyone who stopped receiving alerts. Oh, I'm sure they put a message up somewhere, but...
I refuse to get a Passport account, so I still don't get them, but I guess I can only blame my stubbornness for that.
Silly user, the anouncemnt has been on display for quite some time:
http://h48fd614e.obscurity.microsoft.com/basement/ subbasement/ususedRestRoom/LockedFlilingCabnet/ BewareOfLeopard/announcements.asp?user=BillyG&pass =VBSisVirusBreading System
... and I'm sure Firestone published their exact formulations for the rubber, as well as thermal and wear test data, as well as tensile and shear strengths of the ply material as well as the rubber-ply matrix.
many people bought and drive Ford Explorers with Firestone tires, many of whom were probably automobile experts, safety experts, physicists; but the "vulnerability" of a tire blow out causing a fatal crash was never revealed by the consumer.
Most of these experts had access to only the "compiled tire", so they'd have to wear out a lot of tires doing testing to find the problem.
The main problem with your analogy, however, is that I've never heard of a single person that formulates thier own rubber, weaves thier own plies, and manufacturers their own car tires as a hobby. However, there are many many people that make thier own computer software from scratch as a hobby and there's very little money to be made as a freelance tire analysis consultant. If you find a few esoteric bugs in software, you stand a much better chance of getting paid good money as a computer security consultant. Oh, and computers are much more common than tire manufacturing equipment in people's homes. The electricity cost of pulling up a text edditor, a compiler, and a debugger is much less than the cost of polyester, vinyl, and steel. Software is simply the ultimate in DIY, while tires are really hard to create and test yourself. (How many people do you know that have made a little extra money on the side selling car tires they made? How many people do you know that made a little extra money selling shareware?)
Did they sell exclusive rights to Xenix to SCO, or could they still migrate everything over to the Xenix kernel without having to pay SCO?
This will NOT happen.
It's a shame to see MS take things it definately knows about and reinvent them poorly. They knew about UNIX crypt passwords, but went ahead and made the LM hash for passwords but neglected the salt value used in UNIX crypt to prevent parallel cracking of the entire password file. They later saw some of thier problems and came up with the NT hash based on UNIX md5 passwords (but using the md4 hash), again neglecting the UNIX salt. I'm a security systems guy, so maybe it just happens that MS only reinvented poorly the stuff I'm knowledgable about. Using off-the-shelf MIT-liscenced (similar to X11 liscence) Kerberos instead of making up their own networking authentication protocols and having to revise them when they realize they designed them poorly.
It was a good idea for them to try and make NT a microkernel OS, but it didn't end up working out. It's a shame they didn't reinvent the filesystem as a unified virtual filesystem with C:, D:, etc. being symbolic links for legacy purposes. Oh well.
You may not need to chain several greoups of captured bytes together. You can use them as part of a dictionary for a hybrid password cracker.
Better yet, if you've got a pretty good idea that you have a password fragment (for instance, it's preceded by a known username and a colon), you've greatly reduced the password cracking effort. If you have a strong password, leaking 3 characters makes it about 300,000 times easier to crack.
MS statements aren't very reliable. Remember the fmous "that vulnerability is purely theoretical" claims? Someone else here claimed they got a vulnerable driver from Windows Update. Maybe MS is nice and distributes 3rd party drivers through thier update service, but I doubt they've thuroughly tested all of the drivers they ship on thier CD.
Unless you've personally tested your driver, I'd play it safe and go with the statement of the publishers: Linux, NetBSD, and Windows are vulnerable.
You also seem to wish that Linux would relase a statement. Linux cannot release a statement. Linus can. Red Hat can. Mandrake can. Linux cannot. Windows cannot. Cobol cannot. VB Script cannot.
Looks like the shoe is on at least three feet now, but some of the feet appear to be in denial. Oh, and "haha" doesn't help your post look informed or intelligent.
The Raelians have announced their first colonizing ship full of expectant clone mothers is due to arrive in the nearest system in question sometime next month.
I don't see how that would affect anything. Since you check against a.length (rather than a constant), once i hit a.length, you would end the loop. While you might hit a bug with the loop terminating early, it would never terminate late (and thus overflow).
How much multi-threaded programming (with preemptive scheduling) have you done?
Loop itterations are not atomic in Java (or any language I'm aware of). If java arrays could change size (which they can't), then you could have another thread change the size of the array between the loop condition check and the assignment.
In Java, you're lucky if i++ gets jitted into something atomic.
private static int threadCount = 0;
public static int numberMe(){ return ++threadCount;}
If every thread calls numberMe() once, they are not guaranteed to get unique results nor is threadCount guranteed to end up equalling the number of threadsthat have called it. (If you make numberMe a synchronized method, it's a different story.)
Ehh.. you're describing a replay attack, not a MITM attack. It's pretty trivial to make the system invlunerable to a replay attack.
Imagine a system in which a signed 1128-bit number, representing the number of milliseconds since Jan. 1, 1970 is encrypted using Twofish or Mars with a 256-bit key. The laptop broadcasts this as a querry. The token decrypts it and makes sure it's not too far in the future or too far in the past, flips the MSB, re-encrypts, and sends it back as the repsonse. You could have the token keep track of latencies. If some guy snags the laptop and uses a sgnal booster while driving away in a car, latencies are going to start going up rapidly, and the watch should stop repsonding for a little while.
Give the watch a nice big panic button to make it forget the key.
Go to mug the guy and he hits the panic button and the watch is useless. (Put a pulse sensor and a sensor on the watch clasp if you're really paranoid.)
It'll take literally decillions of years of following the guy in order to be able to replay querry responses.
The simplest attack I can think of that would work in this case is to have a signal booster to increase the range that the token can be from the laptop. The range is still limited by the amount of latency the watch is willing to accept, so you still can't take the laptop too far from the token.
Unless your line of work involves carying a suicide pill, a system like this should work fine.
The main thing is that you want the data encrypted all the time it's on disk and use something like encrypted loopback device or a cryptographic fs driver, otherwise some guy puts an ice pickthrough your battery and runs off with the dead laptop and reads the HD with a different machine.
Each kernel module declairs what liscence it falls under. More symbols are exported for Free modules.
Nobody is preventing NVidia from writing binary-only drivers, they just need to hook into the kernel at lower levels. Some kernel developers want the NVidia people to mooch less.
They're tightening restrictions, not banning binary-only modules. Relax. They're just saying if NVidia wants to use binary-only modules, that's thier perogative, but it's a huge pain for the developers that become de facto support for those NVidia drivers. Basically "You want to be a pain in my ass, go ahead, but you're now getting less help from me to do it."
The *BSD kernels are simpler and may not have equivalents to the special higher-level functions that are being hidden from non-Free modules. I don't know. In any case, it's unlikely NVidia is going to jump ship for one of the *BSDs. I'm not even surewhat companies hope to achieve by providing binary-only drivers. Thier competitors certainly have decompilers. If they really need to protect patented algorithms, that can be done in firmware/hardware and/or usermode drivers. Usermode drivers also prevent binary-only kernel instabilities and reduce kernel dependancies.
Ehh... you don't need the actual CD to claim that you're listening to a song on it. I also doubt that it' a challenge-response protocol involving random stretches of the current song as proof that you're really listening to the song you claim. My guess is that it's a completely trusted client. Thanks for playing, though.
I dunno... I do lots of things b/c I can't. I couldn't write anything in Ocaml and I couldn't write any http basic auth apps, so I went and got rfc 2617 and went to ocaml.org.
I take great joy in doing things I can't do. (Okay, if you want to pick nits, it's stuff I couldn't do and learned in the process of doing, but it sounds better to phrase it the other way.)
I've been thinking about writing an app to quiz me on Koine Greek (very similar to Attic Greek spoken in the Helenistic erra). I'm leaning towards writing it as a Zope Python script, but PHP is also a strong option.
Anyone up for packet-sniffing the protocol and sending me the results? I'd be more than happy to write a Python and/or Ocaml client to spout random statistics back. Maybe we could set up a website with teams and stuff, keeping track of the total number of fake listening hours reported. (Of course, there'd be lots of cheating on those stats, but what do you expect when you're trying to keep track of self-reported cheating stats?)
You are correct. The CSS cipher is vulnerable to an attack similar to the one against the GSM phone "A4" cipher. You guess the initial state of all of the shift registers except the largest one, then from the cipher output you deduce the initial contents of the largest shift regster. IIRC, this means that the CSS cipher is as hard to crack as a 16-bit key cipher without flaws. (In the case of A4, you need to guess 40-bits of the key nd check the others, and the checking requires some slightly more complicated linearalgebra due to the non-standard register clocking, so it ends up being equivalent to about 44-bit key strength, assuming you use some advanced sparse matrix inversion techniques devloped in Russia.)
With DVDs, the disc master key is encrypted with itself and stored on the disc, which makes the guess and check step in key recovery much easier. Once you have the disc master key, you can start cracking the 400-some player keys, with some of the computation parallelizable across all of the player keys you're trying to crack.
BeOS definately gets points for design. Too bad Apple didn't buy them out. Thier microkernel was much less ugly than Mach, and the OS is implemented as a multiserver instead of monoserver on top of the microkernel. (I think BeOS also avoided performance hackslike making the severs run in the kernel's address space in ring 0.)
On the other hand, thier implementation had some serious problems. I never figured out how I was using semaphores improperly (I use them fine under Linux), but I got kernel panics every single time I ran this small app I wrote and I traced the problem down to semaphores. I'd also get random kernel panics. Not cool.
The worst was waking up one morning. "Why's the floppy drive spinning? Has it been spinning all night?" It had spunthe thing all night, leaving a notch in the surface of thefloppy and ruining the floppy drive head.
I also had a few ethernet driver crashes, but luckily it's a microkernel OS, so I just had to restart the driver process.
Would it have killed them to modify mv and cp to move metadata as well as data? COuld they have put the bookmark urls in the data fork instead of the metadata fork? I lost all of my bookmarks 'cause I used cp to move them to a second BeOS partition before reinstalling. (I was affraid it had kernel paniced too many times and might have started getting kernel image corruption.) What kind of stupid software engineer puts vital data in the metadata fork? (Incidently, if you use cp to copy your BeOS system to a new partition, all of your OS servers become unhidden and show up in the task bar.)
It's a nice little OS that seemed to get really good performance and encourage good programming habbits without ugly hacks. A little more development and multiuser capability and I may have run it more than 10% of the time.
Slashdot Mirror
You fail to understand the essence of good system (and web) design. Things should fail gracefully. You can use all W3C approved features, but you need to design the web page so that it is stil navigable if the fancy features fail. Look at the cingular website for an example of this done very poorly. If you use anything that doesn't identify itself as Netscape, the javascript routines become very ie-specific, so you can't get any deeper than the front page is you're using Mozilla.
If your webpage is unusable in Lynx, that's a bug in your webpage. It doesn't have to be pretty in Lynx, but SSL-enabled Lynx users should still be able to select products and buy them. Go ahead and do pretty things with the newest approved W3C features, but they need to not be critical. Sure, go ahead and make it ugly on anything but Netscape and IE. People using alternative browsers really don't care, nd to be honest, if it looks good in Netscape and is usable in Lynx, almost any alternative browser user will be very happy. And for the love of Jebus, is you have to make multiple versions of a webpage, then make the Netscape one the default if you can't figure out what browser they're using. Netscape/Mozilla rendering is pretty close to the target alternative browsers are shooting for (as in Mozilla is much much closer to a W3C compliant renderer).
These are basic principles of software engineering. You need graceful failure. Sure strict HTML isn't Turing complete, but the principles still apply. Take a system design class sometime. I'm not saying good web design is easy. I'm saying that too many special cases is a general warning in system design, and it carries over into web design. Think of browser-specifics as hacks. Sometimes you need a hackto meet a deadline, but hacks are bad, Ugly webpages are better than unnavigable webpages.
making good HTML isn't part of the settlement, but as a part of a continuing pattern, this could land MS in legal trouble. (It won't 'cause it's too minor to prosecute, just like jaywalking is seldom prosecuted.)
Secondly, OSS project leads do it because they love it. They tae pride in thier work. All of thier work is unpaid overtime so they don't mind so much putting in unpaid overtime to get back respect for thier pride and joy, and there's no management breathing down thier necks to get the next feature release out the door. How many MS coders or project leads have the authority to stall a project for months just to clean up the code? How many MS coders or project leads would work like slaves for thier code if they got paid less than minimum wage? It's all about the love. It's like a car enthusiast who learns to do his own maintenence vs. the car mechanic getting pressure to hurry it up so that the next car can get fixed.
I know of several people that have had thier oil pan drain plugs stripped by an air wrench and not had the mechanic bother to tell them, only to find a hugepuddle of oil the next morning. That guy down the street that waxes his 'vette every Saturday probably personally changes his oil, if not personally overhauls his own drivetrain. A job is just a job, but a hobby is something you don't rush or do half-assed. It sounds cheesy, but love is what makes hobby software (usually OSS) special. If you get paid to do your hobby, so much the better, but it's still your hobby, not just some job.
The main problem with x86 is multiple-width instructions that prevent eficient parallel instruction decoding. The main point the RISC movement made was that most architectures used to have tons of instructions that were rarely used. An unused instruction still takes up just as many transistors and development time that could be spent elsewhere. When was that last time you saw a modern C compiler spit out x86 BCD instructions (that weren't inline assembly). They might as well have made instructions to do base 13 as well as BCD and binary operations. I centainly hope they've simply made some BCD to/from binary conversion micro-ops and moved all o the BCD handling into microcode.
These devices do not directly manipulate 128-bit pointers or 128-bit integers. You can get some cryptographic coprocessors that will do 1024-bit integer operations (and by now, problably 2048-, if not 4096-bit). Heck, a 486 will do 80-bit floating point operations, but we still consider ia32 to be 32-bit systems. For general computing, you're looking at the size of pointers when you talk about the "bit-ness" of a CPU. Vector ops aren't necessarily faster in a superscalar CPU. They happen to be for every CPU I'm aware of, but it's possible to invest those same transistors into more integer/float units and get the same performance (assuming the increased flexability and general performace increase offsets the slight decode/issue overhead you gain by representing vector operations serially but perforing them in parallel). My understanding is that AMD chips simply have blazing fast FPUs and the SSE2 instructions were added in microcode, not transistors.
Some of the HP48G calculators had CPUs with 64-bit accumulators. However, all of the math was done in BCD, and memory access was done a nibble at a time. Don't get me wrong, more bits are great, but my aging PII will take the Pepsi Challenge against an HP48G any day of the week. (My understanding is that most of the HP48G code was interpreted RTL rather than directly executed, allowin them to pretty easily switch CPUs out from under everything. Pretty cool.)
BTW, the GameCube's "Gecko" CPU is 32-bits (64-bit FPU), I believe. I'm not aware of any games that take advantage of 64-bit integers, nor any gaming consoles that need more than 4 GB of virtual memory.
In short, yes, we are talking about the "housekeeping CPU" in a sense. More directly, we're probably talking about the MMU, which isn't necessarily on the same chip as any of the compuational engines.
More importantly, it's very easy to emulate 64-bit integer and 2048-bit vector operations on a 32-bit machine. However, it is much much more difficult to emulate very large address spaces on machines that use 32-bit pointers. One of the reasons the IBM POWER series has had 64-bit pointers from the get-go (While the Power PCs still are 32-bit) is that AIX runs all of the processes in a single adress space (memory protection is done by other means than seperate address spaces. This means you never have to do a TLB flush.) There are some tricks now for ia32 that basically give several 32-bit address spaces to a single process, but it's a real hack.
In summary,it's all about the pointers. Larger FP and integer operations than natively supported are easily done using multiple registers and slighly more time. Pointer operations larger than supported natively by the CPU arevery expensive to do..
We can however, blame MS for releasing a patch in October that reintroducs the vunerability that was patched in July.
P2P can be done securely, depending on your threat model. DOS attacks against P2P systems is still a largely unsolved problem. However you could easily make a system that is for all practical purposes immune to data disclosure. (GPG encrypt your data to yourself befre distributing it, for instance.) I have a nice little perl script that makes a nightly tarball of my CVS repository and GPG-encrypts it, then puts the encrypted tarballup on the web under a filename that contains 64-bits of the md5sum of the unencrrypted tarball. (taken pre-compression). On the backup storage machine, there's a perl script to chck if the md5sum fragment has changed, and if so, use wget to backup the tar ball. (This most defintely isn't P2P, but it deonstrates a simple example of a backup system that lets thee entire world see the backup, yet is for all practical purposes immune to data disclosure.)
If you had a distributed cooperative file system, you could use my perl scripts do do your backups, and the only notable attack (aside from compromise of your machine) would be a DOS/deletion attack against the cooperative filesystem. Of course, you need to chack signatures on the tarballs when you decrypt them.
I was actually talking with one of the Freene developers about his efforts provide distributed encrypted anonymous storage. Unfortunately, the DOS/deletion problem is still unslved, so he was forced to go with storage only on his machines, which means it's not P2P. Most P2P stems are also so transient that you'd need a very high level of replication.
Of course, there's a simple modification to my perl script system that you could make... have it scan random IP addresses for open SMB shares... that would be "non-cooperative distributed filesystems" :-P
I hadn't heard of any salt being used. Salts are completely useless if you're using a seperate strongly (pseudo-)random key for each file. If you're not very very careful, the salting may also very slightly reduce your key space.
If you're using an encrypted fielsystem, make sure your password is stored only using the NT hash. By default, both the LM hash and the NT hash of your password are stored in the registry. In the absolute best case, the work foactor is somewhere aroudn 2 ** 56 to break a 14-character strong password. If you password doesn't require you to hold down the alt key while using the nueric keypad, you're most likely looking at a work factor of about 2 ** 37 to crack your password. (Your password is borken into 7-character halves and converted into upper case, then something like an unsalted UNIX crypt algorithm is applied seperately to each half.) Once they have your password, they can decrypt your SK and get all of your files. Game over man, game over.
Microsoft should be applauded for making a default install crypto-filesysm capable. However, per-file encryption falls to some attacks and information leakage that volume-level encryption doesn't suffer from. Swap space and temp files are still a big problem without third-party add-ons.
It's also important to note that RSA Labs designed DESX explicitly as a stop-gap measure until the Advanced Encryption Standard (AES) was decided upon.
MS could also have done the world a great service by including 40-yaer old password salting technology instead of using unsalted password hashes.
BTW, while you're at regitering at IBM, pick up Jikes, the 1.4 JVM, and robot wars. All good stuff. They've got some good Linux white papers too.
(Now to get them to use 100% ASCII in thier HTML instead of those stupid MS "smart quotes".)
That MS makes the best software and McD's makes by far the best food on the entire plannet. Britney is the best musician alive, and some huge state school offers an education that far outclasses any Ivy League school. China and India are the best countries in which to live and bud light is the best beer. Ford and GM make the best cars. Excuse me while I finish off my microbrews, escargot, veal, and caviar and find a nice cliff over which to drive my German engineered uberwundercar. If this is the best this planet has to offer, there's no sense in continuing.
Silly user, the anouncemnt has been on display for quite some time:/ subbasement/ususedRestRoom/LockedFlilingCabnet/ BewareOfLeopard/announcements.asp?user=BillyG&pass =VBSisVirusBreading System
http://h48fd614e.obscurity.microsoft.com/basement
The main problem with your analogy, however, is that I've never heard of a single person that formulates thier own rubber, weaves thier own plies, and manufacturers their own car tires as a hobby. However, there are many many people that make thier own computer software from scratch as a hobby and there's very little money to be made as a freelance tire analysis consultant. If you find a few esoteric bugs in software, you stand a much better chance of getting paid good money as a computer security consultant. Oh, and computers are much more common than tire manufacturing equipment in people's homes. The electricity cost of pulling up a text edditor, a compiler, and a debugger is much less than the cost of polyester, vinyl, and steel. Software is simply the ultimate in DIY, while tires are really hard to create and test yourself. (How many people do you know that have made a little extra money on the side selling car tires they made? How many people do you know that made a little extra money selling shareware?)
This will NOT happen.
It's a shame to see MS take things it definately knows about and reinvent them poorly. They knew about UNIX crypt passwords, but went ahead and made the LM hash for passwords but neglected the salt value used in UNIX crypt to prevent parallel cracking of the entire password file. They later saw some of thier problems and came up with the NT hash based on UNIX md5 passwords (but using the md4 hash), again neglecting the UNIX salt. I'm a security systems guy, so maybe it just happens that MS only reinvented poorly the stuff I'm knowledgable about. Using off-the-shelf MIT-liscenced (similar to X11 liscence) Kerberos instead of making up their own networking authentication protocols and having to revise them when they realize they designed them poorly.
It was a good idea for them to try and make NT a microkernel OS, but it didn't end up working out. It's a shame they didn't reinvent the filesystem as a unified virtual filesystem with C:, D:, etc. being symbolic links for legacy purposes. Oh well.
Better yet, if you've got a pretty good idea that you have a password fragment (for instance, it's preceded by a known username and a colon), you've greatly reduced the password cracking effort. If you have a strong password, leaking 3 characters makes it about 300,000 times easier to crack.
Unless you've personally tested your driver, I'd play it safe and go with the statement of the publishers: Linux, NetBSD, and Windows are vulnerable.
You also seem to wish that Linux would relase a statement. Linux cannot release a statement. Linus can. Red Hat can. Mandrake can. Linux cannot. Windows cannot. Cobol cannot. VB Script cannot.
Looks like the shoe is on at least three feet now, but some of the feet appear to be in denial. Oh, and "haha" doesn't help your post look informed or intelligent.
The Raelians have announced their first colonizing ship full of expectant clone mothers is due to arrive in the nearest system in question sometime next month.
How much multi-threaded programming (with preemptive scheduling) have you done?
Loop itterations are not atomic in Java (or any language I'm aware of). If java arrays could change size (which they can't), then you could have another thread change the size of the array between the loop condition check and the assignment.
In Java, you're lucky if i++ gets jitted into something atomic.
private static int threadCount = 0;
public static int numberMe(){ return ++threadCount;}
If every thread calls numberMe() once, they are not guaranteed to get unique results nor is threadCount guranteed to end up equalling the number of threadsthat have called it. (If you make numberMe a synchronized method, it's a different story.)
Imagine a system in which a signed 1128-bit number, representing the number of milliseconds since Jan. 1, 1970 is encrypted using Twofish or Mars with a 256-bit key. The laptop broadcasts this as a querry. The token decrypts it and makes sure it's not too far in the future or too far in the past, flips the MSB, re-encrypts, and sends it back as the repsonse. You could have the token keep track of latencies. If some guy snags the laptop and uses a sgnal booster while driving away in a car, latencies are going to start going up rapidly, and the watch should stop repsonding for a little while.
Give the watch a nice big panic button to make it forget the key.
Go to mug the guy and he hits the panic button and the watch is useless. (Put a pulse sensor and a sensor on the watch clasp if you're really paranoid.)
It'll take literally decillions of years of following the guy in order to be able to replay querry responses.
The simplest attack I can think of that would work in this case is to have a signal booster to increase the range that the token can be from the laptop. The range is still limited by the amount of latency the watch is willing to accept, so you still can't take the laptop too far from the token.
Unless your line of work involves carying a suicide pill, a system like this should work fine.
The main thing is that you want the data encrypted all the time it's on disk and use something like encrypted loopback device or a cryptographic fs driver, otherwise some guy puts an ice pickthrough your battery and runs off with the dead laptop and reads the HD with a different machine.
Nobody is preventing NVidia from writing binary-only drivers, they just need to hook into the kernel at lower levels. Some kernel developers want the NVidia people to mooch less.
They're tightening restrictions, not banning binary-only modules. Relax. They're just saying if NVidia wants to use binary-only modules, that's thier perogative, but it's a huge pain for the developers that become de facto support for those NVidia drivers. Basically "You want to be a pain in my ass, go ahead, but you're now getting less help from me to do it."
The *BSD kernels are simpler and may not have equivalents to the special higher-level functions that are being hidden from non-Free modules. I don't know. In any case, it's unlikely NVidia is going to jump ship for one of the *BSDs. I'm not even surewhat companies hope to achieve by providing binary-only drivers. Thier competitors certainly have decompilers. If they really need to protect patented algorithms, that can be done in firmware/hardware and/or usermode drivers. Usermode drivers also prevent binary-only kernel instabilities and reduce kernel dependancies.
Ehh... you don't need the actual CD to claim that you're listening to a song on it. I also doubt that it' a challenge-response protocol involving random stretches of the current song as proof that you're really listening to the song you claim. My guess is that it's a completely trusted client. Thanks for playing, though.
Ah yes, the subtle Hans Andersen flaw, first described in 1837. Good show, quite clever. Mod parent up.
I take great joy in doing things I can't do. (Okay, if you want to pick nits, it's stuff I couldn't do and learned in the process of doing, but it sounds better to phrase it the other way.)
I've been thinking about writing an app to quiz me on Koine Greek (very similar to Attic Greek spoken in the Helenistic erra). I'm leaning towards writing it as a Zope Python script, but PHP is also a strong option.
Do things b/c you can't, not b/c you can.
Anyone up for packet-sniffing the protocol and sending me the results? I'd be more than happy to write a Python and/or Ocaml client to spout random statistics back. Maybe we could set up a website with teams and stuff, keeping track of the total number of fake listening hours reported. (Of course, there'd be lots of cheating on those stats, but what do you expect when you're trying to keep track of self-reported cheating stats?)
With DVDs, the disc master key is encrypted with itself and stored on the disc, which makes the guess and check step in key recovery much easier. Once you have the disc master key, you can start cracking the 400-some player keys, with some of the computation parallelizable across all of the player keys you're trying to crack.
On the other hand, thier implementation had some serious problems. I never figured out how I was using semaphores improperly (I use them fine under Linux), but I got kernel panics every single time I ran this small app I wrote and I traced the problem down to semaphores. I'd also get random kernel panics. Not cool.
The worst was waking up one morning. "Why's the floppy drive spinning? Has it been spinning all night?" It had spunthe thing all night, leaving a notch in the surface of thefloppy and ruining the floppy drive head.
I also had a few ethernet driver crashes, but luckily it's a microkernel OS, so I just had to restart the driver process.
Would it have killed them to modify mv and cp to move metadata as well as data? COuld they have put the bookmark urls in the data fork instead of the metadata fork? I lost all of my bookmarks 'cause I used cp to move them to a second BeOS partition before reinstalling. (I was affraid it had kernel paniced too many times and might have started getting kernel image corruption.) What kind of stupid software engineer puts vital data in the metadata fork? (Incidently, if you use cp to copy your BeOS system to a new partition, all of your OS servers become unhidden and show up in the task bar.)
It's a nice little OS that seemed to get really good performance and encourage good programming habbits without ugly hacks. A little more development and multiuser capability and I may have run it more than 10% of the time.