In windows task manager, total memory allocated = Mem usage + VM Size
I don't think that's quite true. I've not found any definitive reference on how these figures are calculated, but the best I can see is that VM Size excludes pages that are shared, whereas they're included in mem usage.
Actually, no. Looking at the document, you'd have to actually play one of the listed files through an audio player before it'd be an infringment. And it doesn't have to be wireless; it has to be over a "telecommunication network" (e.g. the Internet).
1. Method of receiving information from one of a plurality of information systems via a high data rate telecommunication network in response to a request from one of plural subscriber stations, said method comprising the steps of:
initiating a two-way transmission from subscriber computer means of said one of said plural subscriber stations to one of said information systems via said telecommunication network,
outputting on output means of said one of said plural subscriber stations data related to plural information stored at one of said information systems,
selecting at said one of said plural subscriber stations at least one of said information by means of input means of said one of said plural subscriber stations and transmitting a signal identifying said at least one selected information from said subscriber computer means to a selected information system via said telecommunication network,
receiving at said one of said plural subscriber stations from said selected information system digital signals via said telecommunication network, expanding by expansion means said transmitted signals, converting said expanded digital signals into analog signals and delivering said analog signals to transducer means.
A 2-way connection is initiated by a subscriber's computer, e.g. an ISDN phone. A list of available messages is sent from the base station to the phone, which outputs them (by sending the data, transmitted as digitally encoded signals, through the DAC and to the loudspeaker). The user presses a button on the phone's keypad, which is transmitted as a DTMF tone back to the base station, whereupon it is used to select a stored message. This message is transmitted as digitally encoded audio to the phone, which decodes it and produces sounds. Sounds like voicemail to me.
I'm pretty sure this was common practice before the patent's filing date of Dec 22 1995.
2. Method in accordance with claim 1, further including the step of storing in memory means of said one of said plural subscriber stations said digital signals received at said one of said plural subscriber stations.
A voice mail system that stores messages in memory (e.g. a flash disk).
3. Method of transmitting information from a central server to plural subscriber stations via a high data rate telecommunication network in response to requests from said subscriber stations, said method comprising the steps of:
recording information at said central server on a plurality of information storage means, each of said information storage means being identified by an address,
receiving at the central server a signal representing an initiation of a two-way transmission from one of said plural subscriber stations via said telecommunication network,
receiving at the central server a signal identifying at least one selected one of said information storage means at said central server from said one of said plural subscriber stations via said telecommunication network,
reading at the central server from memory means of said central server said address identifying each of said at least one information storage means,
transmitting said address from said central computer means to a controller,
controlling each at least one selected information storage means drive to retrieve signals from each at least one selected information storage means,
transmitting said retrieved signals as compressed digital signals to said one of said plural subscriber stations via said telecommunication network.
A little more complicated. It seems to describe a system with multiple disks (or other storage media) attached to the server, with some kind of controller that enables access to them. A CD jukebox would conform to this, as might some kind of large disk array. Still, I suspect that this kind of arrangement has been used for voicemail before 95. Possibly even with the storage media being magnetic tapes loaded into a j
If all the developers developing functionality in this KDE-only style would put the (wasted) effort into programming this on the OS-level (as in: writing filesystem drivers instead of KIOslaves) every app could use this, not just the ones linking with kdelibs.
Yes, but only the ones running on one particular operating system. I know that KDE can run on at least Linux, Windows/cygwin, NetBSD, and OpenBSD. I believe there's also a MacOSX port. To write OS level drivers for all these systems would have been substantially more work than writing the kioslaves plugin system, not least because writing a kernel-based FS driver is a *lot* harder than writing a library to emulate it in userspace.
The question now is: how the release of such search engines is going to impact the BitTorrent network?
The answer: not at all. There isn't a BitTorrent network, just an application that has caused many thousands of disjoint, single purpose networks to come into existance.
And that disjointness will help protect them, I feel.
Re:Multicore is great, but not for the obvious rea
on
AMD Quad Cores, Oh My
·
· Score: 1
does anyone actually make a "server" that doesn't have SMP?
Agreed. Until I can get a PDA that measures 8cmx10cm, is just 1cm thick, doesn't need batteries charging/replacing for an entire year, and doesn't have a convoluted user interface, I think I'll stick with my pocket diary.
Simple -- send everyone an e-mail asking "is this time OK?", if they send one back saying it isn't, try again with a time that they suggest. Repeat until you have a time agreed, send confirmation e-mails and write it in your diary.
If you're working with external contractors, who are likely to be using a calendaring system that won't automatically interoperate with your own, it's the only way you can make it work anyway.
If only they got "everything is a file [bell-labs.com]" not "every protocol needs a new KIOslave"
"Everything is a file" is a great abstraction, but it can only be implemented by the operating system. kioslaves are simply an abstraction layer that adds the ability to treat non-file objects as if they were a file without OS support for the notion -- it's the only way they can do it without junking support for just about every operating system in existance.
how am I going to open a remote image with gimp ?
Why don't you ask the GIMP developers to support it? Or ask the developers of the kernel of the operating system you use to support it? Rather than using it as an excuse for complaining about KDE, when it is not the KDE team's fault and there is absolutely nothing they can do about it?
BTW, if you're on Linux you might want to look into the FUSE/kioslave bridge project, which apparently allows you to mount kioslave plugins as if they were a real filesystem...
MD5 seemed like a good way to check for duplicate jpg images, sometimes an image with the same data had a different name. But equivelent MD5 hashes of different images made a mess of that scheme.
If you have two different JPEG files that have the same MD5 hash but show a different image, I suspect security researchers would like to see them. Especially if they're the kind of JPEG images most slashdotters seem to have more of than the other kinds...
Wang has lowered that number to 2^64, which is uncomfortably small by today's standards and reckless by tomorrow's
Do you know how long it would take to brute force 2^64 trials? Or how much memory you would need to store the results?
Do the maths. It comes in at thousands of years (even if you're very generous with the estimate of how many hashes per second you can calculate), and millions of terabytes (even using the most storage-efficient solution, which is clearly not going to be very fast at all).
The crypto geeks are speulating that these weaknesses are inherent in any hash algorithm that can be calculated incrementally
I haven't been staying up to date with this, but I'm pretty sure that these particular attacks are based on differential cryptanalysis. My understanding is that this technique is only applicable to algorithms that have particular flaws (e.g. particular inputs can be found that only cause a small number of bits to change in intermediate stages, and these changes can be arrange to cancel each other out). Some new designs of hash algorithm claim to be able to prevent this kind of analysis from working (e.g. Tiger). Unless I've missed somebody pointing out why this isn't the case, then anyone speculating like that is jumping the gun somewhat.
Secure schemes involving one party signing material provided by another party should always involve a signing nonce. This is a random bitstring appended to the material to be signed. In the example from the article, if Caesar had added a nonce before signing the "good" document, then Alice would not have been able to produce a "bad" document with a matching hash.
That doesn't work for this attack, because it produces a single document that contains both texts, and differences in just one hashing block of the file trigger a change in what is shown. Any changes made in one copy can simply be copied over to the other and it will continue to work fine.
MD5 it's obsolete now and SHA-1 have been phased out
Perhaps in the field you use hashing in, however for many applications these two are the de-facto standards.
the fact is that by now every serious cryto soft must be using high order sha, like SHA-256 or SHA-512 or stronger has functions like Tiger or Whirpool.
This attack is not related to the size of the hash, but rather to an error in the algorithm that allows you to compute two blocks with identical hashes easily. This will be harder with SHA-256 and so, but probably not as much harder as you think. I don't know the design of SHA-256, but unless it altered significantly from SHA-1 I'd expect to see an attack against it along these lines in the next 2-3 years. A new design *is* required to fix this problem.
Tiger might be that design; it was certainly designed to be resistant to the family of attacks currently being used on MD5 and SHA1. I don't know whirlpool, though.
A new competition would be good, as it would help people choose between SHA-256 et al, Tiger and any other competition available.
One must ALWAYS add some random junk to the document (clear text or hidden). This should be implemented in sofetware that helps in signing, but if the option isn't given, you can add a clear text "random" string.
Doesn't help. MD5 (and most others) are block based hashes -- if they find a single pair of blocks that hash to the same value one of those two can be inserted into a document at any block boundary and the hash comes out the same, regardless of what is in the remainder of the document. You can add as much random text as you like, as long as you don't disturb their collision block they can just duplicate your changes to the alternative document and it still hashes the same as the one you signed.
I really wish Linux distros would stop trating md5 sums as if they were secure.
They are, as long as you can trust that they generated the MD5s with files that they produced the content for. This attack does not work unless you control both versions of the file you're trying to switch.
Unfortunately not. Their technique requires both generated certificates to have the same name details, but different keys.
The only practical use I can think of in generating certificates with a hash collision is if it enables me to persuade an authority to sign one certificate which I can then switch some details on and pretend to be somebody else who the certificate issuer wouldn't normally have signed for. This technique doesn't allow you to do this. In fact, it doesn't do anything that most certificate issuers wouldn't normally allow you to do (have two identical certificates except for the key) anyway, as long as you paid them enough.
From your description it sounds like X and Y can be very small though, in which case it shouldn't take too long to find X and Y "brute-force" for any hash algorithm?
MD5 (and most similar hashes) work on blocks of data at once; if you can produce a single block of data that hashes the same, it doesn't matter what's in the file before or after it, it'll always have the same effect on the resulting hash. I think the blocks are 64 bytes for MD5, so that's the size of your X and Y.
Still, to brute force it, you'd need to perform on average 2^64 hashes (because there are 2^128 possible outcomes for the 2^512 possible inputs), each one using approximately 3-500 arithmetic unit cycles* and producing a *very* large lookup table to determine if you'd found a hit**.
So, no, brute forcing it isn't feasible, even for very small blocks.
* or roughly 200 processor cycles on a modern intel processor, so you're probably looking at about 2^40 processor seconds or so, or about 2^15 processor years, or much longer than I'd be willing to wait)
** to do the lookups you'd need at least 2^64 * 72 bytes of RAM to store each hashed result and the input that generated it, or about 300 million terabytes. It would be best to store the information in a hash table large enough to store every possible result, at which point you'd need 2^128 * 64 bytes of RAM, which is a *ludicrous* volume! In reality, somewhere between the two would suffice nicely, perhaps just 600 or 900 million terabytes.
I'd be interested to see how this attack is actually useful in the real world. Even given that they're using a code-base format like postscript, under what strange scenario is an organization going to rely on important documents being digitally signed by people other than the original creator? Any kind of contract or important document is going to be hand signed with at least one witness.
The only situations I'm aware of where it is common for documents to be signed by somebody other than the creator are:
* X.509 certificates -- in this case the documents are very small, contain little redundancy and it is unlikely that such an attack could be made to work. * Date stamping services that prove a document existed at a particular time -- but this attack isn't applicable here because you have to produce both documents at the same time. * Peer-to-peer networks that use reviews on web sites to help users differentiate good files from bad ones. This last category *might* be vulnerable.
I honestly don't think this kind of attack is really useful, despite what anyone might say. It cannot be applied to contracts, because in order for the contract to be useful it would have to be possible to produce the original digital file that was signed in court. Anyone reasonably competent examining this file could easily see that the text of both documents is in there -- this alone would be enough to throw doubt on the contract, and whoever had produced the contract would almost certainly lose the case.
The only other use I've seen usggested is for generating two certificates (or any equivalent) with different public keys. But what would be the use in that since it would have to be the same person generating both certificates? Congratulations Mr. Hacker, you can generate two certificates with different keys that both appear to come from Mr. Hacker.
If the attack could be made to work (which it can't in its current form) then you could use it to persuade the issuer to sign a certificate they wouldn't usually sign -- e.g., you own example1.com, while somebody else you want to attack owns example2.com; if you can produce a certificate request that looks like it is for example1.com but has the same hash code as a valid certificate request for example2.com, then you could submit the one for example1.com, take the signature returned to you and apply it to example2.com.
But the attack doesn't work like that -- it relies on being able to use effectively random changes to a small and otherwise meaningless chunk of the file in order to switch the meaning of the document between two extremes. This requires the format of the document to have some very advanced capabilities (in the case of the attack presented, they're using the general programming capabilities of postscript to choose between two different documents), which certificate signing requests don't.
I mention that P2P networks might be vulnerable; here's how an attack on one of those would work:
You have a piece of software that would be popular on a P2P network (say the latest version of a popular free software project). You want to include a trojan horse program in it.
The P2P network has a review site where trusted people evaluate software available on it and check whether there are any trojans, etc, in the package. They do this by closely monitoring the behaviour of the programs in a set of tests that you know little about. They're good at spotting trojans; you're pretty sure that if you released your software with the trojan in it, they'd spot it and would recommend users didn't download the file, destroying the effectiveness of your plan. If however they were to evaluate your file and not spot the trojan, thousands of people would be infected...
You produce a program that, during startup, checks one data block against another (in an identical fashion to the postscript document described above) and starts your trojan thread only if they differ/match/whatever. You release the non-
...I saw it when it first came out in 1977, several times actually, and I distinctly remember seeing the "Episode IV" at the beginning of the space scroll and thinking "what the....episode LV???" (Hey, I was Eight at the time...gimme a break).
I didn't see it until much later (some time around 81, I think), but I've heard this from several sources, who all claim to have seen it with their own eyes -- the original release did *not* have "Episode IV" or "A New Hope" in it.
I don't think he meant Vader to be Father as I think George was writing 4-6 as he was going along... it wasn't all pre-planned from the beginning.
My understanding is that he came up with outlines for the plots of all the films that have been made between the release of "Star Wars" (later retitled "Star Wars: Episode IV, A New Hope") and the release of "Empire Strikes Back". How closely he's stuck to that outline is impossible to know.
Slashdot Mirror
In windows task manager, total memory allocated = Mem usage + VM Size
I don't think that's quite true. I've not found any definitive reference on how these figures are calculated, but the best I can see is that VM Size excludes pages that are shared, whereas they're included in mem usage.
The patent appears to be so vague that it could apply to the teletype. Or perhaps even the telegraph.
Did you actually read it? Or just respond based on the title of it?
If you read it, you'll see that neither the teletype nor the telegraph are even approximately covered by it.
Actually, no. Looking at the document, you'd have to actually play one of the listed files through an audio player before it'd be an infringment. And it doesn't have to be wireless; it has to be over a "telecommunication network" (e.g. the Internet).
When was the Internet created? Back in 1977? How about FTP? When was Sun's .au audio format created?
Or how about this: Find any audio file that was on a BBS before 1991, and locate the BBS's owner. Remember dialup?
This would invalidate claim 1, sure. But it probably wouldn't get you very far with the other 20 or so claims in the patent...
I claim:
1. Method of receiving information from one of a plurality of information systems via a high data rate telecommunication network in response to a request from one of plural subscriber stations, said method comprising the steps of:
initiating a two-way transmission from subscriber computer means of said one of said plural subscriber stations to one of said information systems via said telecommunication network,
outputting on output means of said one of said plural subscriber stations data related to plural information stored at one of said information systems,
selecting at said one of said plural subscriber stations at least one of said information by means of input means of said one of said plural subscriber stations and transmitting a signal identifying said at least one selected information from said subscriber computer means to a selected information system via said telecommunication network,
receiving at said one of said plural subscriber stations from said selected information system digital signals via said telecommunication network, expanding by expansion means said transmitted signals, converting said expanded digital signals into analog signals and delivering said analog signals to transducer means.
A 2-way connection is initiated by a subscriber's computer, e.g. an ISDN phone. A list of available messages is sent from the base station to the phone, which outputs them (by sending the data, transmitted as digitally encoded signals, through the DAC and to the loudspeaker). The user presses a button on the phone's keypad, which is transmitted as a DTMF tone back to the base station, whereupon it is used to select a stored message. This message is transmitted as digitally encoded audio to the phone, which decodes it and produces sounds. Sounds like voicemail to me.
I'm pretty sure this was common practice before the patent's filing date of Dec 22 1995.
2. Method in accordance with claim 1, further including the step of storing in memory means of said one of said plural subscriber stations said digital signals received at said one of said plural subscriber stations.
A voice mail system that stores messages in memory (e.g. a flash disk).
3. Method of transmitting information from a central server to plural subscriber stations via a high data rate telecommunication network in response to requests from said subscriber stations, said method comprising the steps of:
recording information at said central server on a plurality of information storage means, each of said information storage means being identified by an address,
receiving at the central server a signal representing an initiation of a two-way transmission from one of said plural subscriber stations via said telecommunication network,
receiving at the central server a signal identifying at least one selected one of said information storage means at said central server from said one of said plural subscriber stations via said telecommunication network,
reading at the central server from memory means of said central server said address identifying each of said at least one information storage means,
transmitting said address from said central computer means to a controller,
controlling each at least one selected information storage means drive to retrieve signals from each at least one selected information storage means,
transmitting said retrieved signals as compressed digital signals to said one of said plural subscriber stations via said telecommunication network.
A little more complicated. It seems to describe a system with multiple disks (or other storage media) attached to the server, with some kind of controller that enables access to them. A CD jukebox would conform to this, as might some kind of large disk array. Still, I suspect that this kind of arrangement has been used for voicemail before 95. Possibly even with the storage media being magnetic tapes loaded into a j
If all the developers developing functionality in this KDE-only style would put the (wasted) effort into programming this on the OS-level (as in: writing filesystem drivers instead of KIOslaves) every app could use this, not just the ones linking with kdelibs.
Yes, but only the ones running on one particular operating system. I know that KDE can run on at least Linux, Windows/cygwin, NetBSD, and OpenBSD. I believe there's also a MacOSX port. To write OS level drivers for all these systems would have been substantially more work than writing the kioslaves plugin system, not least because writing a kernel-based FS driver is a *lot* harder than writing a library to emulate it in userspace.
The question now is: how the release of such search engines is going to impact the BitTorrent network?
The answer: not at all. There isn't a BitTorrent network, just an application that has caused many thousands of disjoint, single purpose networks to come into existance.
And that disjointness will help protect them, I feel.
does anyone actually make a "server" that doesn't have SMP?
Yes
Agreed. Until I can get a PDA that measures 8cmx10cm, is just 1cm thick, doesn't need batteries charging/replacing for an entire year, and doesn't have a convoluted user interface, I think I'll stick with my pocket diary.
Simple -- send everyone an e-mail asking "is this time OK?", if they send one back saying it isn't, try again with a time that they suggest. Repeat until you have a time agreed, send confirmation e-mails and write it in your diary.
If you're working with external contractors, who are likely to be using a calendaring system that won't automatically interoperate with your own, it's the only way you can make it work anyway.
Don't you find figuring out all those complex leap year rules tricky?
Although I guess after the aztec calendar, everything will seem simple.
all that KDE protocol crap is, well, wrong.
If only they got "everything is a file [bell-labs.com]" not "every protocol needs a new KIOslave"
"Everything is a file" is a great abstraction, but it can only be implemented by the operating system. kioslaves are simply an abstraction layer that adds the ability to treat non-file objects as if they were a file without OS support for the notion -- it's the only way they can do it without junking support for just about every operating system in existance.
how am I going to open a remote image with gimp ?
Why don't you ask the GIMP developers to support it? Or ask the developers of the kernel of the operating system you use to support it? Rather than using it as an excuse for complaining about KDE, when it is not the KDE team's fault and there is absolutely nothing they can do about it?
BTW, if you're on Linux you might want to look into the FUSE/kioslave bridge project, which apparently allows you to mount kioslave plugins as if they were a real filesystem...
I think the version I used was either v5 or v6, and it certainly had layers that could be used to keep editable vector objects in long term.
:)
The last version of PhotoPaint I used was 3, which didn't.
MD5 seemed like a good way to check for duplicate jpg images, sometimes an image with the same data had a different name.
But equivelent MD5 hashes of different images made a mess of that scheme.
If you have two different JPEG files that have the same MD5 hash but show a different image, I suspect security researchers would like to see them. Especially if they're the kind of JPEG images most slashdotters seem to have more of than the other kinds...
Prepending a string might work, though. Just a thought.
Wang has lowered that number to 2^64, which is uncomfortably small by today's standards and reckless by tomorrow's
Do you know how long it would take to brute force 2^64 trials? Or how much memory you would need to store the results?
Do the maths. It comes in at thousands of years (even if you're very generous with the estimate of how many hashes per second you can calculate), and millions of terabytes (even using the most storage-efficient solution, which is clearly not going to be very fast at all).
The crypto geeks are speulating that these weaknesses are inherent in any hash algorithm that can be calculated incrementally
I haven't been staying up to date with this, but I'm pretty sure that these particular attacks are based on differential cryptanalysis. My understanding is that this technique is only applicable to algorithms that have particular flaws (e.g. particular inputs can be found that only cause a small number of bits to change in intermediate stages, and these changes can be arrange to cancel each other out). Some new designs of hash algorithm claim to be able to prevent this kind of analysis from working (e.g. Tiger). Unless I've missed somebody pointing out why this isn't the case, then anyone speculating like that is jumping the gun somewhat.
Secure schemes involving one party signing material provided by another party should always involve a signing nonce. This is a random bitstring appended to the material to be signed. In the example from the article, if Caesar had added a nonce before signing the "good" document, then Alice would not have been able to produce a "bad" document with a matching hash.
That doesn't work for this attack, because it produces a single document that contains both texts, and differences in just one hashing block of the file trigger a change in what is shown. Any changes made in one copy can simply be copied over to the other and it will continue to work fine.
MD5 it's obsolete now and SHA-1 have been phased out
Perhaps in the field you use hashing in, however for many applications these two are the de-facto standards.
the fact is that by now every serious cryto soft must be using high order sha, like SHA-256 or SHA-512 or stronger has functions like Tiger or Whirpool.
This attack is not related to the size of the hash, but rather to an error in the algorithm that allows you to compute two blocks with identical hashes easily. This will be harder with SHA-256 and so, but probably not as much harder as you think. I don't know the design of SHA-256, but unless it altered significantly from SHA-1 I'd expect to see an attack against it along these lines in the next 2-3 years. A new design *is* required to fix this problem.
Tiger might be that design; it was certainly designed to be resistant to the family of attacks currently being used on MD5 and SHA1. I don't know whirlpool, though.
A new competition would be good, as it would help people choose between SHA-256 et al, Tiger and any other competition available.
One must ALWAYS add some random junk to the document (clear text or hidden). This should be implemented in sofetware that helps in signing, but if the option isn't given, you can add a clear text "random" string.
Doesn't help. MD5 (and most others) are block based hashes -- if they find a single pair of blocks that hash to the same value one of those two can be inserted into a document at any block boundary and the hash comes out the same, regardless of what is in the remainder of the document. You can add as much random text as you like, as long as you don't disturb their collision block they can just duplicate your changes to the alternative document and it still hashes the same as the one you signed.
I really wish Linux distros would stop trating md5 sums as if they were secure.
They are, as long as you can trust that they generated the MD5s with files that they produced the content for. This attack does not work unless you control both versions of the file you're trying to switch.
Unfortunately not. Their technique requires both generated certificates to have the same name details, but different keys.
The only practical use I can think of in generating certificates with a hash collision is if it enables me to persuade an authority to sign one certificate which I can then switch some details on and pretend to be somebody else who the certificate issuer wouldn't normally have signed for. This technique doesn't allow you to do this. In fact, it doesn't do anything that most certificate issuers wouldn't normally allow you to do (have two identical certificates except for the key) anyway, as long as you paid them enough.
From your description it sounds like X and Y can be very small though, in which case it shouldn't take too long to find X and Y "brute-force" for any hash algorithm?
MD5 (and most similar hashes) work on blocks of data at once; if you can produce a single block of data that hashes the same, it doesn't matter what's in the file before or after it, it'll always have the same effect on the resulting hash. I think the blocks are 64 bytes for MD5, so that's the size of your X and Y.
Still, to brute force it, you'd need to perform on average 2^64 hashes (because there are 2^128 possible outcomes for the 2^512 possible inputs), each one using approximately 3-500 arithmetic unit cycles* and producing a *very* large lookup table to determine if you'd found a hit**.
So, no, brute forcing it isn't feasible, even for very small blocks.
* or roughly 200 processor cycles on a modern intel processor, so you're probably looking at about 2^40 processor seconds or so, or about 2^15 processor years, or much longer than I'd be willing to wait)
** to do the lookups you'd need at least 2^64 * 72 bytes of RAM to store each hashed result and the input that generated it, or about 300 million terabytes. It would be best to store the information in a hash table large enough to store every possible result, at which point you'd need 2^128 * 64 bytes of RAM, which is a *ludicrous* volume! In reality, somewhere between the two would suffice nicely, perhaps just 600 or 900 million terabytes.
I'd be interested to see how this attack is actually useful in the real world. Even given that they're using a code-base format like postscript, under what strange scenario is an organization going to rely on important documents being digitally signed by people other than the original creator? Any kind of contract or important document is going to be hand signed with at least one witness.
The only situations I'm aware of where it is common for documents to be signed by somebody other than the creator are:
* X.509 certificates -- in this case the documents are very small, contain little redundancy and it is unlikely that such an attack could be made to work.
* Date stamping services that prove a document existed at a particular time -- but this attack isn't applicable here because you have to produce both documents at the same time.
* Peer-to-peer networks that use reviews on web sites to help users differentiate good files from bad ones. This last category *might* be vulnerable.
I honestly don't think this kind of attack is really useful, despite what anyone might say. It cannot be applied to contracts, because in order for the contract to be useful it would have to be possible to produce the original digital file that was signed in court. Anyone reasonably competent examining this file could easily see that the text of both documents is in there -- this alone would be enough to throw doubt on the contract, and whoever had produced the contract would almost certainly lose the case.
The only other use I've seen usggested is for generating two certificates (or any equivalent) with different public keys. But what would be the use in that since it would have to be the same person generating both certificates? Congratulations Mr. Hacker, you can generate two certificates with different keys that both appear to come from Mr. Hacker.
If the attack could be made to work (which it can't in its current form) then you could use it to persuade the issuer to sign a certificate they wouldn't usually sign -- e.g., you own example1.com, while somebody else you want to attack owns example2.com; if you can produce a certificate request that looks like it is for example1.com but has the same hash code as a valid certificate request for example2.com, then you could submit the one for example1.com, take the signature returned to you and apply it to example2.com.
But the attack doesn't work like that -- it relies on being able to use effectively random changes to a small and otherwise meaningless chunk of the file in order to switch the meaning of the document between two extremes. This requires the format of the document to have some very advanced capabilities (in the case of the attack presented, they're using the general programming capabilities of postscript to choose between two different documents), which certificate signing requests don't.
I mention that P2P networks might be vulnerable; here's how an attack on one of those would work:
You have a piece of software that would be popular on a P2P network (say the latest version of a popular free software project). You want to include a trojan horse program in it.
The P2P network has a review site where trusted people evaluate software available on it and check whether there are any trojans, etc, in the package. They do this by closely monitoring the behaviour of the programs in a set of tests that you know little about. They're good at spotting trojans; you're pretty sure that if you released your software with the trojan in it, they'd spot it and would recommend users didn't download the file, destroying the effectiveness of your plan. If however they were to evaluate your file and not spot the trojan, thousands of people would be infected...
You produce a program that, during startup, checks one data block against another (in an identical fashion to the postscript document described above) and starts your trojan thread only if they differ/match/whatever. You release the non-
...I saw it when it first came out in 1977, several times actually, and I distinctly remember seeing the "Episode IV" at the beginning of the space scroll and thinking "what the....episode LV???" (Hey, I was Eight at the time...gimme a break).
I didn't see it until much later (some time around 81, I think), but I've heard this from several sources, who all claim to have seen it with their own eyes -- the original release did *not* have "Episode IV" or "A New Hope" in it.
I don't think he meant Vader to be Father as I think George was writing 4-6 as he was going along ... it wasn't all pre-planned from the beginning.
My understanding is that he came up with outlines for the plots of all the films that have been made between the release of "Star Wars" (later retitled "Star Wars: Episode IV, A New Hope") and the release of "Empire Strikes Back". How closely he's stuck to that outline is impossible to know.
This doesn't affect your point, though.