I thought there had been. I have one of their games, and had always been miffed that I couldn't skip past the Fox logo at the beginning.
But it's always hard for me to figure out the roles of the different game companies. Case in point: that web site has Vivendi and Fox Interactive logos. The support link leads to Sierra. And the first review I found points at Eurocom Entertainment as the developers. (Mutant Enemy was also involved, I'd guess.)
So what were their roles, and what role does Rupert see his company being in? It might be that Fox Interactive played a different role in its games than whatever company Rupert's scoping out.
Shouldn't that be 1200 kb/s? 150 KB/s * 8 = 1200 kb/s, right? Or is the 150 KB/s figure I'm using incorrect (I could have sworn that was the 1x CD speed)?
Data CDs are 150 KB/s at 1x, but you're missing an important difference between data and audio CDs.
CD sectors are 2352 bytes (I'm ignoring subchannels here). Data CDs have 2048 data bytes, plus 304 bytes of error-correction data, so every bit comes off perfectly. Audio CDs have no error correction, so they use all 2352 bytes for audio data (on the assumption that a few bits missed won't hurt). That means that audio data is moved 14.8% faster (in b/s) than 9660 data. 1200*1.148 = 1378.
Another calculation you can use instead: 44100 samples/sec * 2 channels/sample * 16 bits/channel = 1411200 bits/sec, or 1378 K/s.
Also, most call logging systems have a section for "Technician comments", which can be anything from "customer follows directions well" to "customer is an asshole". This can influence greatly the way you are treated by future technicians.
About halfway through my stint in tech support, we all got a reminder from management that those records can accidently be included in call logs sent to the customer... or subpoenaed... or otherwise put in a position by which the company could get in hot water.
They're still used, of course, but I just want to remind tech support folks to watch what you say in those "internal viewing only" comment blocks.
After looking at this discussion, it looks like there's several of us on/. with sleep disorders. (I myself recently started CPAP therapy.) It may be nice to have a forum where we can share what works, what doesn't, and what to expect.
To this end, I've created the Sleepgeek mailing list. Subscribe by visiting http://mail.piquan.org/mailman/listinfo/sleepgeek, or a "subscribe" email to sleepgeek-request at (my-user-name) dot org. For the spam-conscious, posting rights and the list roster are only available to list members.
dolo666, you've offered to have private email discussions with several people on this thread. Feel free to send them this info, since they may not read this thread again. Of course, anybody should feel free to invite others to the list.
I just got back from celebrating my nephew's third birthday. He takes after me in a lot of ways, and so I'm guessing he'll have fun with programming.
For Christmas and his birthday, I got him a KidzMouse (icky website, great product) and some non-computer stuff. The KidzMouse was because his hands can't use his Mom and Dad's mouse, so he has to have Mom do all his mousing when he plays games. I felt that this interface might discourage him from exploring on his own; hence the KidzMouse.
I've been thinking about him learning a lot lately. Buffy fans remember what she said to her kid sister in "Grave": "I don't want to protect you from the world. I want to show it to you." That's how I feel about my nephew. I want him to be able to experience art, and music, and science, and nature, and-- of course-- technology. I'm not going to shove anything down his throat, but by golly I'll make sure he has the tools he needs to discover them on his own.
That's shaped my choices of gifts for him a lot. I'm trying to stay on the topic of computers here, so the KidzMouse is one example. (I also set up video conferencing, mostly because I'm tired of only seeing him once or twice a year.) I think that this is the most important thing you can do: make sure that the kid has the tools to explore, and learn whatever they want on their own.
So here's what I see as needs. First off, an interactive environment: you should be able to give a command, and immediately see the results. Second, no file editor, no IDE, none of that mess. He should be able to concentrate on playing with the environment, instead of learning the editor (and the associated problem of saving from the editor and loading into the program). You should be ready to introduce an editor, but wait until his programs get long enough that the editor becomes a programming aid, not a necessary step.
You can easily set up a.bash_profile or.xsession to launch a programming environment, and exit when it's done. That can spare him from bash. (Again, remove everything that's not an actual aid to programming at this stage!) But which environment?
Python is probably the closest thing you'll get to our old ROM BASIC. It's fast and easy, and pygame sets the stage for much fun. But without a save or list facility, Python may have some problems. I'm not aware of any way to save an entire Python state, a la Lisp, but you could probably write it based on unexec. You can use this idea to implement a "save" command, and just use exec for "load". It's probably pretty simple to write in a kludge to save functions for listings.
The other problem with Python is that it's difficult to edit programs in the interactive mode. You can redefine functions, but you have to retype the whole thing. The one good thing about line-numbered BASIC was that you could quickly make a simple change to a routine.
So you might prefer StarLogo or the like. Many of us started on LOGO or Pilot before we got into BASIC, and I think it's a good environment. Also look at Squeak, which I think has great potential in teaching to program. If I were in your shoes, I'd probably focus on Squeak, unless you're scared of Smalltalk. StarLogo and Squeak deal with the editor issue pretty well.
You will need to provide him with some starting points for exploration. Our generation learned by typing in listings, and then modifying them. I can't really think of a better way. Programming books are too linear; they don't tend to encourage as much exploration. Certainly, have some books available, but I think that "let's play with this and see what we can do" is much, much more important than "let's proceed along these lessons in this order". I'm teaching a friend of mine how to program, and I'm always thrilled when he starts going down his own path instead of staying on my lesson plan. (Well, al
That would be a bad idea, a number of "Chat-bots" have been programmed specifically to pass the turing test and some have been quite successful.
The people communicating with chatbots are predisposed to believing they're talking to other humans. In a Turing Test, the judge is aware that there is a computer on one of his two terminals.
Pretty much, each cypher block is signed. If, during decryption, you see an invalid signature, then you ignore that block.
Now, when you encrypt, you (randomly) multiplex the blocks of your super-secret message, several dummy messages, and many random blocks.
It's obvious that your system does this. That's why you include several dummy messages (make 'em plausible!) and also many random blocks. They can demand another key all they want, but they have no way of telling whether or not you've given them all your keys.
Of course, to encode N different messages of M length requires a file of approximately N*M bytes (compression notwithstanding). This is a natural consequence of anything other than an OTP, because of the pigeonhole principle. Filesystems based on this principle are larger than N*M, but this is expected for filesystems: you make filesystems based on future size, not present. So you might be able to plausibly deny that there's more than one thing on the filesystem. But for messages, it's pretty obvious.
I'd forgotten how far along PearPC was, so I looked at the web site, and found this gem:
Because the author has only access to a little-endian machine, PearPC will most likely only run on little-endian architectures.
Am I the only one that finds something hideously wrong with this sentence? I mean, isn't the whole point of this project to give the author access to a little-endian machine?
Hell, even Windows has 'event viewer' and kernel dumps.
How long does it take to analyze that core dump? The first thing you have is just a message like "page fault in kernel mode"... how long between when you get a core event and you know what the actual problem is? How long before you're sure enough to tell the entire world that you know what the problem is?
I, for one, don't want hasty engineering here. I want somebody looking closely, double-checking their assumptions, and somebody else double-checking him. I don't want somebody to jump to a hasty conclusion.
I wonder if there's any general custom for people on the same LAN to find a common server. That is, could somebody start up a multiplayer Quake (or whatever), and everybody else finds it on the LAN without needing to coordinate IPs?
I guess I'm describing Rendezvous, but that's pretty narrowly-implemented right now, and doesn't have much gaming support AFAIK.
Doesn't a CPU emulator also implement the specification of the CPU?
Yes, and so does the native CPU. I wouldn't say that implementing a foo is sufficient to say that it's emulating a foo.
I suppose it comes down to a definition question, but here's the basic rule-of-thumb I might tend to work from (and it's just off the top of my head):
An emulator:
Implements a particular interface (whether it's a well-documented interface or not). So an x86 emulator would need to implement the MOV, JMP, etc instructions.
Is implemented on another platform. An x86 emulator has to run on a real computer with an OS etc.
Takes responsibility for maintaining the complete state of the device it's emulating, insofar as it affects the result. An x86 emulator would need to maintain the registers itself, although not the "virtual" temperature.
Wine meets the first criterion: it implements the Win32 API. It also meets the second. However, it does not meet the third, because it doesn't track much state. It doesn't need to track file descriptors, or TCP/IP connections, etc, because it can leave that to the underlying OS.
Generally, I call something meeting 1, 2, and 3 an emulator. If it meets 1 and 2, I tend to refer to it as a "compatibility layer". Wine is an example. So is the Linux compatibility layer of FreeBSD (which is sometimes informally referred to as the "linuxulator", but this is taken as a fun name rather than a formal description). I'm writing a compatibility layer for a project at work now, to translate $myproj v1 API calls to $myproj v2 for-- you guessed it-- backwards compatibility. But the v2 portion tracks all the state.
I don't generally refer to things as an emulator unless they meet all three. Bochs is an emulator. So are SPIM and WABI. VMware is an interesting case: it emulates most of the hardware, but only a little bit of the CPU; the bulk of the CPU work is done natively.
If you don't consider Nitfol or a JVM as emulators, you may want to add the criterion that the interface they implement must primarily exist in a non-emulating implementation. I probably would include that criterion, but that would mean I'd have to go back and edit this post.
Ah, but you forgot about Chuck. Whenever Alice and Bob around around, Chuck's always lurking behind the next IP packet to screw everything up. Damn that Chuck!...
Usually, if someone's trying to screw things up, it's Mallory.
There's actually a good reason to use the canonical names. It makes it easy to remember who's trying to do what. If I see "Joe and Jill are exchanging messages, and Jack is trying to read them..." then I have to remember their roles instead of concentrating on the protocol. If I see, "Jack sends Jill the hash he computed," then I may think that this is part of the normal flow rather than data injection, because I forgot that Jack is the evildoer.
But after reading 50 papers about Alice, Bob, Eve, Mallory, and the rest of the gang, you have everybody's motives down and can concentrate on the data flow instead, which is the point.
I vaguely remember that the short key ID used a flimsy hash, but to avoid that you only had to verify the key length.
If you and I are remembering the same thing, that was under a different attack. IIRC, that wasn't even an attack on the hash, but just on the way that fingerprints were generated. But it's been a long time, so I may be misremembering.
Wang's attack, the one in the article-- which doesn't, AFAICT, permit this sort of attack (when I mentioned GPG I was talking about a different type of attack that Sheetrock hypothesized)-- does use same-length data.
Looking around, MD5 looked dubious in 1997, and alternatives - like SHA1 and RIPEMD-160 - got incorporated to PGP.
Yes, although many legacy keys are still around-- mostly because people kept using PGP 2.6.2 for so long. My keyring is 10% legacy keys. Since PGP encourages you to get lots of signatures on your keys, then you have a decent chance of any given key having signatures that you can (under this sort of attack) subvert. And if it doesn't, then try to subvert up the keychain some; you have to swap out more keys, but there's more keys to choose from.
It doesn't work this way at all. If all you have is the MD5, this 'attack' is useless. You must have a complete copy of the original, non-hashed input to generate a file that would have the same MD5.
Traditionally, yes, and that's the point of using MD5 in password files. But I was specifically working under Sheetrock's scenario:
He can create a file that MD5sum's to the same result as a legitimate file,
Sheetrock felt that this sort of attack on MD5 would not have any significant impact, and I was disagreeing.
Now, I'm not saying that the attack in the article allows this to happen. I haven't studied the attack in question closely, but it looks like it only allows "weak" collisions, which we all thought were on the way for MD5 anyhow. The password attack we're discussing here requires "strong" collisions, which it doesn't look like Wang's attack allows.
Finding a collision is one thing. Finding a collision that happens to be a member of a valid GPG keypair is quite another.
This is true. I added the GPG bit at the last minute, and didn't give it due thought. I should have put this in the "speculations" paragraph, since I'm rather out-of-date on GPG.
that doesn't net you a private key that matches it, or a way to make one
If I were going to investigate this further, I'd consider whether a randomly-generated public key could easily be made into a private key. Specifically, the strength of a public key is in the difficulty of factoring (at least under RSA; I haven't kept up with what's being used). While factoring the product of two large primes is difficult, the more general case of factoring random numbers is much easier. Perhaps this could be exploited to replace a public key with one that can be easily factored. Again, I haven't kept up with the technology, so this is still just speculation, but I think it's a valid line of inquiry.
More generally, you don't have to substitute the key with one that you create. Just substitute it with a weaker key.
Being able to substitute public keys changes the threat model significantly, and in a way that the designers didn't account for. I still think that it seems entirely possible that this would be something that could generate a GPG attack.
He can create a file that MD5sum's to the same result as a legitimate file, but does not have full control over the content or size of the result (making this a mostly useless avenue of exploitation except for people who want to spread trash on P2P networks -- I.E. it shouldn't particularly bother anyone except people who already don't care about security).
Suppose you're storing passwords as encrypted hashes, so that intercepting the hashes doesn't tell you what the password is. But if you can generate a password to match that MD5...
You know that GPG keys are identified and signed by their MD5 hashes? Suppose that I can generate a GPG key that would be identified as yours, and distributed it.
Or he can create two files that MD5sum to the same result. But he has to have control over both files, which offers effectively no advantage to someone who is trying to spread malware or tamper with existing archives that have been MD5summed.
There's a coin-flipping protocol that goes as follows. Suppose that Alice and Bob want to flip a coin (over the Internet), but they don't trust each other.
Alice generates a file with random data.
Alice sends Bob the MD5 hash of the file.
Bob picks a bit in the file, and whether he thinks it's a 0 or a 1.
Bob wins if and only if he picked right.
To verify, Alice sends Bob the file she generated at the beginning.
Now, suppose that Alice generated multiple files in step 1. When Bob makes his guess, she tries to pick a file that will make her win. If she generated only two files, completely randomly, this would let Alice win 75% of the time.
These are just the first ideas I thought of. If I were looking for other problems, I'd think about undeniable signatures, keysigning (which as GPG and X.509 SSL are heavily based on) and other specialized signature systems. In particular, I expect that the first type of crack could cause issues with SSH keys, both user keys (used for authentication) and host keys (to prevent man-in-the-middle attacks).
Digital signatures are used for much more than just testing for file tampering.
Slashdot Mirror
I thought there had been. I have one of their games, and had always been miffed that I couldn't skip past the Fox logo at the beginning.
But it's always hard for me to figure out the roles of the different game companies. Case in point: that web site has Vivendi and Fox Interactive logos. The support link leads to Sierra. And the first review I found points at Eurocom Entertainment as the developers. (Mutant Enemy was also involved, I'd guess.)
So what were their roles, and what role does Rupert see his company being in? It might be that Fox Interactive played a different role in its games than whatever company Rupert's scoping out.
Shouldn't that be 1200 kb/s? 150 KB/s * 8 = 1200 kb/s, right? Or is the 150 KB/s figure I'm using incorrect (I could have sworn that was the 1x CD speed)?
Data CDs are 150 KB/s at 1x, but you're missing an important difference between data and audio CDs.
CD sectors are 2352 bytes (I'm ignoring subchannels here). Data CDs have 2048 data bytes, plus 304 bytes of error-correction data, so every bit comes off perfectly. Audio CDs have no error correction, so they use all 2352 bytes for audio data (on the assumption that a few bits missed won't hurt). That means that audio data is moved 14.8% faster (in b/s) than 9660 data. 1200*1.148 = 1378.
Another calculation you can use instead: 44100 samples/sec * 2 channels/sample * 16 bits/channel = 1411200 bits/sec, or 1378 K/s.
So, what, is Disney finding the public domain well starting to get a bit dry, and they have to dip into their own stories?
Computers had a lot different feel in the early 80s, and Tron really did hook into that feel. I don't see it working today.
Also, most call logging systems have a section for "Technician comments", which can be anything from "customer follows directions well" to "customer is an asshole". This can influence greatly the way you are treated by future technicians.
About halfway through my stint in tech support, we all got a reminder from management that those records can accidently be included in call logs sent to the customer... or subpoenaed... or otherwise put in a position by which the company could get in hot water.
They're still used, of course, but I just want to remind tech support folks to watch what you say in those "internal viewing only" comment blocks.
After looking at this discussion, it looks like there's several of us on /. with sleep disorders. (I myself recently started CPAP therapy.) It may be nice to have a forum where we can share what works, what doesn't, and what to expect.
To this end, I've created the Sleepgeek mailing list. Subscribe by visiting http://mail.piquan.org/mailman/listinfo/sleepgeek, or a "subscribe" email to sleepgeek-request at (my-user-name) dot org. For the spam-conscious, posting rights and the list roster are only available to list members.
dolo666, you've offered to have private email discussions with several people on this thread. Feel free to send them this info, since they may not read this thread again. Of course, anybody should feel free to invite others to the list.
But because of where that 4% falls, it can be significant in a heavily-used network; see this writeup.
Of course, that writeup was mostly written considering office buildings (where the users/AP ratio is much higher), but it's still worth consideration.
I just got back from celebrating my nephew's third birthday. He takes after me in a lot of ways, and so I'm guessing he'll have fun with programming.
For Christmas and his birthday, I got him a KidzMouse (icky website, great product) and some non-computer stuff. The KidzMouse was because his hands can't use his Mom and Dad's mouse, so he has to have Mom do all his mousing when he plays games. I felt that this interface might discourage him from exploring on his own; hence the KidzMouse.
I've been thinking about him learning a lot lately. Buffy fans remember what she said to her kid sister in "Grave": "I don't want to protect you from the world. I want to show it to you." That's how I feel about my nephew. I want him to be able to experience art, and music, and science, and nature, and-- of course-- technology. I'm not going to shove anything down his throat, but by golly I'll make sure he has the tools he needs to discover them on his own.
That's shaped my choices of gifts for him a lot. I'm trying to stay on the topic of computers here, so the KidzMouse is one example. (I also set up video conferencing, mostly because I'm tired of only seeing him once or twice a year.) I think that this is the most important thing you can do: make sure that the kid has the tools to explore, and learn whatever they want on their own.
So here's what I see as needs. First off, an interactive environment: you should be able to give a command, and immediately see the results. Second, no file editor, no IDE, none of that mess. He should be able to concentrate on playing with the environment, instead of learning the editor (and the associated problem of saving from the editor and loading into the program). You should be ready to introduce an editor, but wait until his programs get long enough that the editor becomes a programming aid, not a necessary step.
You can easily set up a .bash_profile or .xsession to launch a programming environment, and exit when it's done. That can spare him from bash. (Again, remove everything that's not an actual aid to programming at this stage!) But which environment?
Python is probably the closest thing you'll get to our old ROM BASIC. It's fast and easy, and pygame sets the stage for much fun. But without a save or list facility, Python may have some problems. I'm not aware of any way to save an entire Python state, a la Lisp, but you could probably write it based on unexec. You can use this idea to implement a "save" command, and just use exec for "load". It's probably pretty simple to write in a kludge to save functions for listings.
The other problem with Python is that it's difficult to edit programs in the interactive mode. You can redefine functions, but you have to retype the whole thing. The one good thing about line-numbered BASIC was that you could quickly make a simple change to a routine.
So you might prefer StarLogo or the like. Many of us started on LOGO or Pilot before we got into BASIC, and I think it's a good environment. Also look at Squeak, which I think has great potential in teaching to program. If I were in your shoes, I'd probably focus on Squeak, unless you're scared of Smalltalk. StarLogo and Squeak deal with the editor issue pretty well.
You will need to provide him with some starting points for exploration. Our generation learned by typing in listings, and then modifying them. I can't really think of a better way. Programming books are too linear; they don't tend to encourage as much exploration. Certainly, have some books available, but I think that "let's play with this and see what we can do" is much, much more important than "let's proceed along these lessons in this order". I'm teaching a friend of mine how to program, and I'm always thrilled when he starts going down his own path instead of staying on my lesson plan. (Well, al
That would be a bad idea, a number of "Chat-bots" have been programmed specifically to pass the turing test and some have been quite successful.
The people communicating with chatbots are predisposed to believing they're talking to other humans. In a Turing Test, the judge is aware that there is a computer on one of his two terminals.
It's called chaffing and winnowing.
Pretty much, each cypher block is signed. If, during decryption, you see an invalid signature, then you ignore that block.
Now, when you encrypt, you (randomly) multiplex the blocks of your super-secret message, several dummy messages, and many random blocks.
It's obvious that your system does this. That's why you include several dummy messages (make 'em plausible!) and also many random blocks. They can demand another key all they want, but they have no way of telling whether or not you've given them all your keys.
Of course, to encode N different messages of M length requires a file of approximately N*M bytes (compression notwithstanding). This is a natural consequence of anything other than an OTP, because of the pigeonhole principle. Filesystems based on this principle are larger than N*M, but this is expected for filesystems: you make filesystems based on future size, not present. So you might be able to plausibly deny that there's more than one thing on the filesystem. But for messages, it's pretty obvious.
I'd forgotten how far along PearPC was, so I looked at the web site, and found this gem:
Am I the only one that finds something hideously wrong with this sentence? I mean, isn't the whole point of this project to give the author access to a little-endian machine?
Hell, even Windows has 'event viewer' and kernel dumps.
How long does it take to analyze that core dump? The first thing you have is just a message like "page fault in kernel mode"... how long between when you get a core event and you know what the actual problem is? How long before you're sure enough to tell the entire world that you know what the problem is?
I, for one, don't want hasty engineering here. I want somebody looking closely, double-checking their assumptions, and somebody else double-checking him. I don't want somebody to jump to a hasty conclusion.
Nope. I've had my Mac for a little less than a month, got it new from Apple, and it also has the same problem.
I wonder if there's any general custom for people on the same LAN to find a common server. That is, could somebody start up a multiplayer Quake (or whatever), and everybody else finds it on the LAN without needing to coordinate IPs?
I guess I'm describing Rendezvous, but that's pretty narrowly-implemented right now, and doesn't have much gaming support AFAIK.
Our company got a cease and desist from Google for using another company's name in our keywords.
In your AdWords keywords, or your site's META keywords?
As soon as I started the torrent it hit 129 KB/s... get on it while it's hot!
Fujitsu will make something that works.
And PARC will make something.
Doesn't a CPU emulator also implement the specification of the CPU?
Yes, and so does the native CPU. I wouldn't say that implementing a foo is sufficient to say that it's emulating a foo.
I suppose it comes down to a definition question, but here's the basic rule-of-thumb I might tend to work from (and it's just off the top of my head):
An emulator:
Wine meets the first criterion: it implements the Win32 API. It also meets the second. However, it does not meet the third, because it doesn't track much state. It doesn't need to track file descriptors, or TCP/IP connections, etc, because it can leave that to the underlying OS.
Generally, I call something meeting 1, 2, and 3 an emulator. If it meets 1 and 2, I tend to refer to it as a "compatibility layer". Wine is an example. So is the Linux compatibility layer of FreeBSD (which is sometimes informally referred to as the "linuxulator", but this is taken as a fun name rather than a formal description). I'm writing a compatibility layer for a project at work now, to translate $myproj v1 API calls to $myproj v2 for-- you guessed it-- backwards compatibility. But the v2 portion tracks all the state.
I don't generally refer to things as an emulator unless they meet all three. Bochs is an emulator. So are SPIM and WABI. VMware is an interesting case: it emulates most of the hardware, but only a little bit of the CPU; the bulk of the CPU work is done natively.
If you don't consider Nitfol or a JVM as emulators, you may want to add the criterion that the interface they implement must primarily exist in a non-emulating implementation. I probably would include that criterion, but that would mean I'd have to go back and edit this post.
So what you're saying is it emulates an API. Right?
No more than my car emulates a mode of transportation employing paved streets, or Mentat's MPS emulates SVR4 STREAMS (or even BSD sockets).
Wine implements the API.
I tried going to mirrordot, but they didn't have his house mirrored.
Ah, but you forgot about Chuck. Whenever Alice and Bob around around, Chuck's always lurking behind the next IP packet to screw everything up. Damn that Chuck! ...
Usually, if someone's trying to screw things up, it's Mallory.
There's actually a good reason to use the canonical names. It makes it easy to remember who's trying to do what. If I see "Joe and Jill are exchanging messages, and Jack is trying to read them..." then I have to remember their roles instead of concentrating on the protocol. If I see, "Jack sends Jill the hash he computed," then I may think that this is part of the normal flow rather than data injection, because I forgot that Jack is the evildoer.
But after reading 50 papers about Alice, Bob, Eve, Mallory, and the rest of the gang, you have everybody's motives down and can concentrate on the data flow instead, which is the point.
Okay, now we're going to have to limit you to two all-caps words too.
I vaguely remember that the short key ID used a flimsy hash, but to avoid that you only had to verify the key length.
If you and I are remembering the same thing, that was under a different attack. IIRC, that wasn't even an attack on the hash, but just on the way that fingerprints were generated. But it's been a long time, so I may be misremembering.
Wang's attack, the one in the article-- which doesn't, AFAICT, permit this sort of attack (when I mentioned GPG I was talking about a different type of attack that Sheetrock hypothesized)-- does use same-length data.
Looking around, MD5 looked dubious in 1997, and alternatives - like SHA1 and RIPEMD-160 - got incorporated to PGP.
Yes, although many legacy keys are still around-- mostly because people kept using PGP 2.6.2 for so long. My keyring is 10% legacy keys. Since PGP encourages you to get lots of signatures on your keys, then you have a decent chance of any given key having signatures that you can (under this sort of attack) subvert. And if it doesn't, then try to subvert up the keychain some; you have to swap out more keys, but there's more keys to choose from.
It doesn't work this way at all. If all you have is the MD5, this 'attack' is useless. You must have a complete copy of the original, non-hashed input to generate a file that would have the same MD5.
Traditionally, yes, and that's the point of using MD5 in password files. But I was specifically working under Sheetrock's scenario:
Sheetrock felt that this sort of attack on MD5 would not have any significant impact, and I was disagreeing.
Now, I'm not saying that the attack in the article allows this to happen. I haven't studied the attack in question closely, but it looks like it only allows "weak" collisions, which we all thought were on the way for MD5 anyhow. The password attack we're discussing here requires "strong" collisions, which it doesn't look like Wang's attack allows.
Finding a collision is one thing. Finding a collision that happens to be a member of a valid GPG keypair is quite another.
This is true. I added the GPG bit at the last minute, and didn't give it due thought. I should have put this in the "speculations" paragraph, since I'm rather out-of-date on GPG.
that doesn't net you a private key that matches it, or a way to make one
If I were going to investigate this further, I'd consider whether a randomly-generated public key could easily be made into a private key. Specifically, the strength of a public key is in the difficulty of factoring (at least under RSA; I haven't kept up with what's being used). While factoring the product of two large primes is difficult, the more general case of factoring random numbers is much easier. Perhaps this could be exploited to replace a public key with one that can be easily factored. Again, I haven't kept up with the technology, so this is still just speculation, but I think it's a valid line of inquiry.
More generally, you don't have to substitute the key with one that you create. Just substitute it with a weaker key.
Being able to substitute public keys changes the threat model significantly, and in a way that the designers didn't account for. I still think that it seems entirely possible that this would be something that could generate a GPG attack.
He can create a file that MD5sum's to the same result as a legitimate file, but does not have full control over the content or size of the result (making this a mostly useless avenue of exploitation except for people who want to spread trash on P2P networks -- I.E. it shouldn't particularly bother anyone except people who already don't care about security).
Suppose you're storing passwords as encrypted hashes, so that intercepting the hashes doesn't tell you what the password is. But if you can generate a password to match that MD5...
You know that GPG keys are identified and signed by their MD5 hashes? Suppose that I can generate a GPG key that would be identified as yours, and distributed it.
Or he can create two files that MD5sum to the same result. But he has to have control over both files, which offers effectively no advantage to someone who is trying to spread malware or tamper with existing archives that have been MD5summed.
There's a coin-flipping protocol that goes as follows. Suppose that Alice and Bob want to flip a coin (over the Internet), but they don't trust each other.
Now, suppose that Alice generated multiple files in step 1. When Bob makes his guess, she tries to pick a file that will make her win. If she generated only two files, completely randomly, this would let Alice win 75% of the time.
These are just the first ideas I thought of. If I were looking for other problems, I'd think about undeniable signatures, keysigning (which as GPG and X.509 SSL are heavily based on) and other specialized signature systems. In particular, I expect that the first type of crack could cause issues with SSH keys, both user keys (used for authentication) and host keys (to prevent man-in-the-middle attacks).
Digital signatures are used for much more than just testing for file tampering.