... but when does April 1 really start? To discount the effect of time zones, it's best to go by a common time zone (like how TV shows are always listed in EST/EDT in the US even though they're also seen in other time zones at other times). For a website with an international audience, the only time zone that makes sense is GMT... and it's already been a couple of hours into April 1 GMT.
(Do we really have to remind people about this every year? Sigh.)
The Yes/No dialog comes from Windows's own DLL files (which is why the language of buttons may differ from the language the dialog text is on), so all you'd need to do to intercept them is to rename the DLL and replace it with a wrapper that shows the Goatse popup and then calls the original function when the OK/Yes button is pressed.
Good luck with that. The normal system DLLs (kernel32, user32, ntdll, etc) would already be locked open since virtually all processes are statically linked with these DLLs. Replacing common shared DLLs are somewhat hard. I remember futily trying to upgrading msvcrt on an NT 4.0 station with NTFS a while back -- it's virtually impossible since even the core of Windows was holding onto it, and you can't (easily) access NTFS under DOS.
Global hooking is a lot easier and can catch situations where non-standard message boxes are used -- just look for IDYES command buttons being pressed.
Open source has fewer bugs irregardless of overall developers quality, because it's the quality of the best developer that has access to the code that matters.
Only if the best developer reviews all the code and fixes all the bugs. In a large software project, this is not practical. That is precisely why the "more eyes" theory is flawed -- it makes the assumption that everyone looks over the entire codebase, which is definitely not true. If you want to talk about the speed of specific bugfixes or the general severity of bugs, that's one thing, but the quantity should be unaffected simply because the amount of code is large and time is limited.
Any kernel with upwards of 2.5 million lines of code is going to be incredibly buggy, perhaps it's time to rethink and go back to the microkernel
Splitting any software into external pieces is exactly the same as splitting the software into internal pieces. Microkernel is not the answer -- encapsulation is the answer.
Besides, converting the kernel will not get rid of the bugs; it will just make different ones. 2.5 million lines is a lot to rewrite, and any rewrite will lose all the bugfixes already in place.
Some people find bug-fixing fun. Well, not the fuxung so much as the hunt.
Yeah, some people do -- I do most of the time. But in my experience it's the exception, not the rule. In general, I've found that people like fixing easy bugs, but the really bad heisenbugs and deep-rooted design bugs are a PITA. And these are a lot more common as the size of the codebase increases.
I thought since it is open source the bug level should be more or less constant. More bugs, more people willing to fix the bug, more fix submissions - problem solved?
This is a common misconception. In my experience, developers rarely want to fix bugs; it's often tedious to track down what is causing the bug, and the fixes can have a ripple effect where you end up creating yet more problems that you have to fix. It's much more fun to write some kewl new feature. Would you do something boring and tedious without getting paid?:)
Proponents of open source often claim that more eyes == fewer bugs, and this can be true for really obvious problems, but with respect to deep-rooted bugs I would expect it to be about the same. Proprietary vendors don't see it worth the money spent to fix every single bug, especially the rare ones -- you don't get much return on investment. Open-source generally won't fix everything either since it's tedious.
I work for a proprietary software company, and I don't look over everybody else's code except when I'm working on a particular module. Why would this be any different in open source? How many open source developers out there actively audit other people's code?
In general, bugginess is more a function of the quality of the developers (and the pace of development) rather than whether the project is open source.
If they can't get to it from the case connector they'll open the box and find a different set of wires on the circuit board to tap into. Yes, it'll take more research into the chips on the board but eventually a weak point will be found.
Well, duh. The point is to prevent a descrambling device in the middle that end users can use, such as the cable descramblers that are used today. If you could descramble at will, you can copy the HD content all you want. However, most end users won't take apart their new high definition DVD player and start hooking up wires.
It's much easier to stop a handful of people that mass-produce illegal copies than it is to stop millions of end users from making just a few copies.
I never said this was a particularly good encryption system, either. I just pointed out that it's naive to think "we'll just brute force it, and it'll be easy".
Someone will connect an oscilloscope to the wire(s) that connect(s) the devices and reverse engineer the communications signal.
There is no need to do this -- the signal itself would have to be according to some kind of standard or else a brand X DVD player couldn't work with a brand Y television. Just look up the communications protocol.
With a link (ethernet or serial) to any modern day PC they'll just brute force it.
Riiiiight. The DVD's addition rule is [1]+[3] and the TV's is [6]+[17]. What's our secret key? It could be 24 (7+17 and 9+15) or 57 (17+40 and 56+1) or 29387 (12412+16975 and 19280+10107).... Each is equally likely, so yes you could brute force it, but if the actual keys are big enough, it would take a Really Long Time to do it. This is the idea behind just about all forms of modern encryption; they can be broken by brute force, but it takes so long it's not worth it.
Could this be broken on a modern PC? Assuming you could easily verify that you got the unencrypted form and the secret keys are 17 decimal digits, then on average it would take you 5e17 guesses to brute force it. If you assume checking 1,000,000 per second, that's 5e11 seconds > 15844 years. Don't hold your breath.
This is why the attack in TFA is useful. Instead of having to try billions of possible keys, you can algebraically figure out a secret vector, so then cracking the encryption is a simple elementary school addition problem. Solving a set of linear equations to get the secret vector can be done in slightly less than thousands of years.
It won't be difficult.
Yes, it will. That's just like saying "cracking RSA is super-easy because it's just finding the prime factors of a number!!!!!!!11!!1one" So, why can't anyone with a modern PC bring RSA to its knees? After all, when you publish your public key, you're also publishing your private key, too.... if someone can figure out the factors of your modulus. You can just brute force it -- it won't be difficult.
The interesting part of this article is the fact that quasars could be used as a natural source of randomness for one time pads, yet can be accessed by both parties simultaneously.
And also by an attacker....
The historical problem with one time pads (and the reason they're rarely used in practice) is that it's a huge pain to distibute sufficient random data to all parties involved in a communication. Being able to use a natural source of randomness that's available to everyone at once would be a major increase in the usability of one time pads.
Actually, no it would not. You still have to distribute random data -- the quasar and time to start. One would expect that you'd want to pick random variations in start times or else a single leak / lucky guess completely blows away all the protection. With today's technology, distributing 1 GB of random data is just as easy as distributing a time + quasar; just use a flash drive or similar miniature electronic storage.
Also, this poses another problem: since you have to start at the same time, but you also want to be able to do this at high speed, you must synchronize your clocks for this to be useful at all, probably to less than a millisecond. This is not a trivial task.
I really think this is taking something simple and making it way too complex for no gain at all. It's certainly not more useable.
Actually, they've done previous studies on these people to investigate whether they had innate arithmetic abilities by seeing if they could add large numbers, which they could only do approximately. As long as the numbers would fit on two hands, they were exact, but over that, not so much. It seems to me that the large number tests would just be comparing sizes of physical objects rather than actual math. (I don't think they gave them arabic numerals to add, but probably tick marks or other objects. It's just a guess: I don't know their exact methodology.)
What I find most revealing about this is their results on "handedness", which to me would help weed out pattern recognition versus spacial thinking (geometry). According to TFA, only 23% got it right... but 16% would get it right by guessing alone, so it's really not much better. Like the previous study, that seems to conflict with their conclusion rather than support it.
Comments like this show that you probably don't have a lot of programming experience. The fact that they know what went wrong is because they already investigated it and fixed it. If they fixed it and still couldn't explain the problem, I'd worry that they didn't really fix it at all.
Hindsight is 20/20. Foresight is a little trickier.
Are they being ultra-careful with this, or is this just normal-careful?
I think they're being ultra-careful. From what I've heard, they would normally land in these conditions.
However, they really don't want to take a chance. Imagine if something did go wrong: the public outcry would be so big that it would virtually mean the end of manned space flight for a very long time, and that's not something NASA wants to risk.
This could mean a large body of water or that the planet is mostly water (like Earth). Water = life
If it was, I doubt that it could support water-based life as we know it. That water would be ice. Solid ice. All the way through. Since most scientists estimate the surface temperature of Pluto is colder than liquid nitrogen, and this is even further out (meaning colder), I wouldn't get your hopes up.
(BTW, the article actually does say it is made of ice and rock. And yes, it apparently does come closer than Pluto at some points in its orbit, but it'd still be pretty cold. Any life that could survive at 35 AU would almost certainly be killed at 51 AU.)
since for all mersenne numbers, which are of the form (2^n) -1, when n is prime the the mersenne number is prime.
Um, does that mean 11 is not prime? 2^11 - 1 = 2047 = 23 * 89.
So, unfortunately, you'll still need to check if M(M(25964951)) is prime. Good luck -- let us know how that turns out!;)
Re:You can help prove Riemann's hypothesis
on
Prime Obsession
·
· Score: 1
put your computer to work helping to prove the hypothesis in the Zetagrid project
Actually, it doesn't prove anything. It just gives empirical evidence that the Hypothesis is probably right. Even calculating 100 trillion zeros wouldn't prove it since you wouldn't know if #105,928,343,784 is on the line or not. It would be a good guess that it's on the line, but it would be just that: a guess.
Good example: Gauss developed a function called a "logarithmic integral" that estimates the number of primes up to a certain number (or the density of primes, depending on how you look at it). For relatively small n, the logarithmic integral is a slight overestimate... and AFAIK all calculations so far have found it to be an overestimate... but it has actually been proven that it oscillates between an under- and over-estimate infinitely often. If we just relied on brute force calculation, we'd be wrong.
Not to say the project isn't interesting, but I fail to see the utility in it.
(Actually, FWIW, I don't think this was intentional. It doesn't show up under the first 30 hits when you search all stories, which is probably what nanodude did. He did as much if not more checking than the editors did, so there's no reason to get on his case about it.)
I think it's pretty obvious that you only notice the times that really suck.
That's exactly what I thought when I saw their "research methods": tests of the experiences of 1000 people. Whether they asked people to record their experiences or to remember them, I would think that their results would be heavily biased towards exceptional situations, resulting in a much higher probability than really exists.
And for those of you who are complaining about no equals sign in the equations, RTFA. "the formula allows people to calculate the chances" of things going wrong... It's a probability, which means there's an implied "P=" at the beginning, and the resulting quantity is between 0 and 1. Each of the factors are "given a score between one and nine"... I don't see any problem with how you can calculate it or what the result would be, mathematically speaking.
I also think this is crap, but it's because of the subjectiveness of recording human experience and of assigning the score values.
However, you can substitute "add ax, 1" for "inc ax", and "add al, 1" for "inc al", and "add eax, 1" for "inc eax".
You can't even do that. The ADD instruction is generally going to be longer than the INC instruction because of the immediate value. For example, "inc ax" takes up one byte while "add ax, 1" takes up three. (That's in 16-bit mode. In 32-bit mode, both of them have an address size prefix, making 2 bytes and 4 bytes respectively, but that still doesn't change the fact that they don't match.)
The only exception is al. "add al, 1" takes two bytes and "inc al" also takes two bytes. This is because "add al" has a special encoding.... normally "add (8-bit register), (immediate)" takes three, but in al's case only takes two.
So, in effect, these instructions are not interchangeable since the original work could contain the shorter instruction - you can't put in the longer without further modifying the program.
I think Huffman was just being humble, hence he did not use his name for the coding.
I agree. I took a class from G. Blakely, author of the "Blakely secret-sharing scheme", which is what he called it in class. (Yes, I know, Shamir's idea is more well known, and Blakely definitely gave it props in his class.) That's not to say that Blakely wasn't humble, but rather to say that calling something after yourself isn't that weird, especially if that's what it's commonly called.
Bender: Hey robot, what's your serial number? Flexo: 3370318. Bender: No way! Mine's 2716057.
[They both laugh. Then Fry laughs, but stops and looks confused.] Fry: I don't get it. Bender: We're both expressable as the sum of two cubes. Flexo: Woooh!
In the DVD commentary, David Cohen goes on to say that it's tricky to find the cubes. Well, he's right. Here's the trick, in case you were interested:
When 0101100101 appears on the wall in blood, everyone asks Bender what it means and he say's it's just gibberish, then he looks at it in the mirror and screams.
But do you know why? 1010011010 is 666 in binary.
I also remember something from the DVD commentary about the number on the door of Bender's apartment. IIRC, it was 00100100, which looks nice just on the face of it, but David Cohen said specifically that it meant something in ASCII. Sure enough, when you convert it, it's '$'
My favorite, for no apparent reason, has got to be when Bender had a dream in binary.... "I think I saw a 2!" Fry: "Don't worry - there's no such thing as 2." Classic.
You won't know the number you need factored until you intercept or steal the encrypted data.
You don't have to steal anything. The number to factor (the modulus) is given away as part of the public key.
organise a database of the results but the storage - even if you just store some sort of clue to the primes used - would be staggering, even for just 1024-bit RSA.
For 1024-bit numbers, the factors will be on the order of 512-bits. The density of primes is rougly 1/ln(n), and ln(2^512) is about 355, so you should expect around every 355 numbers to be prime. That's only 3e151 numbers, not to mention that you'd have to figure every product of the two, which is 0.5*(3e151)^2, or 7e302 numbers.
Staggering doesn't begin to describe how many of these things you'd have to store.
I don't recall reading anything in the article that stated the FBI was looking for pirated music and movies.
I thought the same thing at first, until I reread it and came across this:
It was among other places in Arizona and "quite a few other states" where sealed search warrants were served, the FBI said. The raids came on the same day that Justice Department officials in Washington announced the creation of a new Intellectual Property Task Force to step up copyright enforcement.
They couldn't give details about the case (like who they were investigating, what type of infringement they were looking for, how they found out it was at the school, etc.) It does seem, though, that they indicated a very generic high-level reason. It's like they say "we're doing a murder investigation" but they can't say who the victim or suspect are, how they died, etc.
Slashdot Mirror
... but when does April 1 really start? To discount the effect of time zones, it's best to go by a common time zone (like how TV shows are always listed in EST/EDT in the US even though they're also seen in other time zones at other times). For a website with an international audience, the only time zone that makes sense is GMT... and it's already been a couple of hours into April 1 GMT.
(Do we really have to remind people about this every year? Sigh.)
Right, just use a CBT hook.
Good luck with that. The normal system DLLs (kernel32, user32, ntdll, etc) would already be locked open since virtually all processes are statically linked with these DLLs. Replacing common shared DLLs are somewhat hard. I remember futily trying to upgrading msvcrt on an NT 4.0 station with NTFS a while back -- it's virtually impossible since even the core of Windows was holding onto it, and you can't (easily) access NTFS under DOS.
Global hooking is a lot easier and can catch situations where non-standard message boxes are used -- just look for IDYES command buttons being pressed.
Only if the best developer reviews all the code and fixes all the bugs. In a large software project, this is not practical. That is precisely why the "more eyes" theory is flawed -- it makes the assumption that everyone looks over the entire codebase, which is definitely not true. If you want to talk about the speed of specific bugfixes or the general severity of bugs, that's one thing, but the quantity should be unaffected simply because the amount of code is large and time is limited.
Splitting any software into external pieces is exactly the same as splitting the software into internal pieces. Microkernel is not the answer -- encapsulation is the answer.
Besides, converting the kernel will not get rid of the bugs; it will just make different ones. 2.5 million lines is a lot to rewrite, and any rewrite will lose all the bugfixes already in place.
Yeah, some people do -- I do most of the time. But in my experience it's the exception, not the rule. In general, I've found that people like fixing easy bugs, but the really bad heisenbugs and deep-rooted design bugs are a PITA. And these are a lot more common as the size of the codebase increases.
This is a common misconception. In my experience, developers rarely want to fix bugs; it's often tedious to track down what is causing the bug, and the fixes can have a ripple effect where you end up creating yet more problems that you have to fix. It's much more fun to write some kewl new feature. Would you do something boring and tedious without getting paid? :)
Proponents of open source often claim that more eyes == fewer bugs, and this can be true for really obvious problems, but with respect to deep-rooted bugs I would expect it to be about the same. Proprietary vendors don't see it worth the money spent to fix every single bug, especially the rare ones -- you don't get much return on investment. Open-source generally won't fix everything either since it's tedious.
I work for a proprietary software company, and I don't look over everybody else's code except when I'm working on a particular module. Why would this be any different in open source? How many open source developers out there actively audit other people's code?
In general, bugginess is more a function of the quality of the developers (and the pace of development) rather than whether the project is open source.
Well, duh. The point is to prevent a descrambling device in the middle that end users can use, such as the cable descramblers that are used today. If you could descramble at will, you can copy the HD content all you want. However, most end users won't take apart their new high definition DVD player and start hooking up wires.
It's much easier to stop a handful of people that mass-produce illegal copies than it is to stop millions of end users from making just a few copies.
I never said this was a particularly good encryption system, either. I just pointed out that it's naive to think "we'll just brute force it, and it'll be easy".
There is no need to do this -- the signal itself would have to be according to some kind of standard or else a brand X DVD player couldn't work with a brand Y television. Just look up the communications protocol.
Riiiiight. The DVD's addition rule is [1]+[3] and the TV's is [6]+[17]. What's our secret key? It could be 24 (7+17 and 9+15) or 57 (17+40 and 56+1) or 29387 (12412+16975 and 19280+10107).... Each is equally likely, so yes you could brute force it, but if the actual keys are big enough, it would take a Really Long Time to do it. This is the idea behind just about all forms of modern encryption; they can be broken by brute force, but it takes so long it's not worth it.
Could this be broken on a modern PC? Assuming you could easily verify that you got the unencrypted form and the secret keys are 17 decimal digits, then on average it would take you 5e17 guesses to brute force it. If you assume checking 1,000,000 per second, that's 5e11 seconds > 15844 years. Don't hold your breath.
This is why the attack in TFA is useful. Instead of having to try billions of possible keys, you can algebraically figure out a secret vector, so then cracking the encryption is a simple elementary school addition problem. Solving a set of linear equations to get the secret vector can be done in slightly less than thousands of years.
Yes, it will. That's just like saying "cracking RSA is super-easy because it's just finding the prime factors of a number!!!!!!!11!!1one" So, why can't anyone with a modern PC bring RSA to its knees? After all, when you publish your public key, you're also publishing your private key, too.... if someone can figure out the factors of your modulus. You can just brute force it -- it won't be difficult.
And also by an attacker....
Actually, no it would not. You still have to distribute random data -- the quasar and time to start. One would expect that you'd want to pick random variations in start times or else a single leak / lucky guess completely blows away all the protection. With today's technology, distributing 1 GB of random data is just as easy as distributing a time + quasar; just use a flash drive or similar miniature electronic storage.
Also, this poses another problem: since you have to start at the same time, but you also want to be able to do this at high speed, you must synchronize your clocks for this to be useful at all, probably to less than a millisecond. This is not a trivial task.
I really think this is taking something simple and making it way too complex for no gain at all. It's certainly not more useable.
Probably because you haven't installed the compiler. Google for "Java native code compiler" or try Excelsior JET.
Agreed.
Actually, they've done previous studies on these people to investigate whether they had innate arithmetic abilities by seeing if they could add large numbers, which they could only do approximately. As long as the numbers would fit on two hands, they were exact, but over that, not so much. It seems to me that the large number tests would just be comparing sizes of physical objects rather than actual math. (I don't think they gave them arabic numerals to add, but probably tick marks or other objects. It's just a guess: I don't know their exact methodology.)
What I find most revealing about this is their results on "handedness", which to me would help weed out pattern recognition versus spacial thinking (geometry). According to TFA, only 23% got it right... but 16% would get it right by guessing alone, so it's really not much better. Like the previous study, that seems to conflict with their conclusion rather than support it.
Comments like this show that you probably don't have a lot of programming experience. The fact that they know what went wrong is because they already investigated it and fixed it. If they fixed it and still couldn't explain the problem, I'd worry that they didn't really fix it at all.
Hindsight is 20/20. Foresight is a little trickier.
Are they being ultra-careful with this, or is this just normal-careful?
I think they're being ultra-careful. From what I've heard, they would normally land in these conditions.
However, they really don't want to take a chance. Imagine if something did go wrong: the public outcry would be so big that it would virtually mean the end of manned space flight for a very long time, and that's not something NASA wants to risk.
This could mean a large body of water or that the planet is mostly water (like Earth). Water = life
If it was, I doubt that it could support water-based life as we know it. That water would be ice. Solid ice. All the way through. Since most scientists estimate the surface temperature of Pluto is colder than liquid nitrogen, and this is even further out (meaning colder), I wouldn't get your hopes up.
(BTW, the article actually does say it is made of ice and rock. And yes, it apparently does come closer than Pluto at some points in its orbit, but it'd still be pretty cold. Any life that could survive at 35 AU would almost certainly be killed at 51 AU.)
since for all mersenne numbers, which are of the form (2^n) -1, when n is prime the the mersenne number is prime.
Um, does that mean 11 is not prime? 2^11 - 1 = 2047 = 23 * 89.
So, unfortunately, you'll still need to check if M(M(25964951)) is prime. Good luck -- let us know how that turns out! ;)
Actually, it doesn't prove anything. It just gives empirical evidence that the Hypothesis is probably right. Even calculating 100 trillion zeros wouldn't prove it since you wouldn't know if #105,928,343,784 is on the line or not. It would be a good guess that it's on the line, but it would be just that: a guess.
Good example: Gauss developed a function called a "logarithmic integral" that estimates the number of primes up to a certain number (or the density of primes, depending on how you look at it). For relatively small n, the logarithmic integral is a slight overestimate... and AFAIK all calculations so far have found it to be an overestimate... but it has actually been proven that it oscillates between an under- and over-estimate infinitely often. If we just relied on brute force calculation, we'd be wrong.
Not to say the project isn't interesting, but I fail to see the utility in it.
after searching /. for a similar article I realized that no one had posted about this before
That's funny... a quick search in Developers for "Visual Studio" seems to disagree with you.
(Actually, FWIW, I don't think this was intentional. It doesn't show up under the first 30 hits when you search all stories, which is probably what nanodude did. He did as much if not more checking than the editors did, so there's no reason to get on his case about it.)
Still, a dup's a dup.
8 billion pages and not a single link to my blog.
Perhaps you should just tell them where it is.
I think it's pretty obvious that you only notice the times that really suck.
That's exactly what I thought when I saw their "research methods": tests of the experiences of 1000 people. Whether they asked people to record their experiences or to remember them, I would think that their results would be heavily biased towards exceptional situations, resulting in a much higher probability than really exists.
And for those of you who are complaining about no equals sign in the equations, RTFA. "the formula allows people to calculate the chances" of things going wrong... It's a probability, which means there's an implied "P=" at the beginning, and the resulting quantity is between 0 and 1. Each of the factors are "given a score between one and nine"... I don't see any problem with how you can calculate it or what the result would be, mathematically speaking.
I also think this is crap, but it's because of the subjectiveness of recording human experience and of assigning the score values.
However, you can substitute "add ax, 1" for "inc ax", and "add al, 1" for "inc al", and "add eax, 1" for "inc eax".
You can't even do that. The ADD instruction is generally going to be longer than the INC instruction because of the immediate value. For example, "inc ax" takes up one byte while "add ax, 1" takes up three. (That's in 16-bit mode. In 32-bit mode, both of them have an address size prefix, making 2 bytes and 4 bytes respectively, but that still doesn't change the fact that they don't match.)
The only exception is al. "add al, 1" takes two bytes and "inc al" also takes two bytes. This is because "add al" has a special encoding.... normally "add (8-bit register), (immediate)" takes three, but in al's case only takes two.
So, in effect, these instructions are not interchangeable since the original work could contain the shorter instruction - you can't put in the longer without further modifying the program.
I think Huffman was just being humble, hence he did not use his name for the coding.
I agree. I took a class from G. Blakely, author of the "Blakely secret-sharing scheme", which is what he called it in class. (Yes, I know, Shamir's idea is more well known, and Blakely definitely gave it props in his class.) That's not to say that Blakely wasn't humble, but rather to say that calling something after yourself isn't that weird, especially if that's what it's commonly called.
From the activity sheet:
In the DVD commentary, David Cohen goes on to say that it's tricky to find the cubes. Well, he's right. Here's the trick, in case you were interested:
3370318 = 119^3 + 119^3
2716057 = 952^3 + (-951)^3
No one ever said the cubed numbers had to be positive.... and yes, I'm a dork for working this out!
When 0101100101 appears on the wall in blood, everyone asks Bender what it means and he say's it's just gibberish, then he looks at it in the mirror and screams.
But do you know why? 1010011010 is 666 in binary.
I also remember something from the DVD commentary about the number on the door of Bender's apartment. IIRC, it was 00100100, which looks nice just on the face of it, but David Cohen said specifically that it meant something in ASCII. Sure enough, when you convert it, it's '$'
My favorite, for no apparent reason, has got to be when Bender had a dream in binary.... "I think I saw a 2!" Fry: "Don't worry - there's no such thing as 2." Classic.
You won't know the number you need factored until you intercept or steal the encrypted data.
You don't have to steal anything. The number to factor (the modulus) is given away as part of the public key.
organise a database of the results but the storage - even if you just store some sort of clue to the primes used - would be staggering, even for just 1024-bit RSA.
For 1024-bit numbers, the factors will be on the order of 512-bits. The density of primes is rougly 1/ln(n), and ln(2^512) is about 355, so you should expect around every 355 numbers to be prime. That's only 3e151 numbers, not to mention that you'd have to figure every product of the two, which is 0.5*(3e151)^2, or 7e302 numbers.
Staggering doesn't begin to describe how many of these things you'd have to store.
I don't recall reading anything in the article that stated the FBI was looking for pirated music and movies.
I thought the same thing at first, until I reread it and came across this:
They couldn't give details about the case (like who they were investigating, what type of infringement they were looking for, how they found out it was at the school, etc.) It does seem, though, that they indicated a very generic high-level reason. It's like they say "we're doing a murder investigation" but they can't say who the victim or suspect are, how they died, etc.
At least, that's the best I could figure out.