My opinion, as someone who has both solved and organized several challenges of this sort, is that the challenge is neither hard (at least by the standards of the ones I've dealt with) nor well designed. In fact, it kind of degenerates: it starts out OK but the ending is terrible.
Stage 1 is interesting: it combines recognizing executable code (the first thing I thought when I stared at that hex dump is "this looks like x86 code", but being able to recognize binary architectures is a valuable skill) combined with some steganography (fishing out the rest of the required data from the PNG. Fair enough, and OK for a first round.
Stage 2 starts out well: virtual machines are used for obfuscation and make fun challenges. However, the execution is backwards. Being given VM bytecode and a specificiation to implement a VM isn't a hacking or reverse engineering challenge; it's just work ("go implement this for me"). A much better challenge would be to be given either the spec or (preferably) code that implements it, and then have to reverse engineer the bytecode itself to solve the puzzle. That involves writing a custom disassembler, which is a much more interesting task.
Stage 3 is a clusterfuck. It's just an executable that checks for a few constants in a file and then builds a URL out of the rest of it. There's a hash (old-school DES crypt() salted password) that the input has to match, but even though it's crackable using a dictionary, you don't even have to do that because the URL includes the hash (which is in the executable), not the plaintext! The rest of the URL isn't checked, and it's basically a guessing game where you have to fish out constants from previous levels. It's just a glorified way of saying "okay, now take a wild guess as to what numbers to stick in the URL". It's not realistic in the slightest.
Anyone interested in a "better stage 2" might want to check out a level that I put together for the Hack-It competition at the 18th Euskal Encounter (2010). Your goal is to figure out the 64-bit input key that works (if you don't know what "works" means, compile and run the code and it should be obvious). The full set of challenges can be found here: 20102011 (unfortunately, the website / problem statements are in Spanish, but I'm sure you can work it out with a bit of copy/pasting into Google Translate - if there's enough interest I'll translate them to English).
The kernel doesn't parse fonts. A userspace program parses the fontfile (which could easily be TrueType if someone feels like supporting that, though it would have to be monospaced). The kernel only gets a raw monochrome bitmap data array for the characters, a width and height, and optionally a character map. No parsing is done in the kernel.
KDFONTOP ioctl arguments: struct console_font_op {
unsigned int op;/* KD_FONT_OP_* */
unsigned int flags;/* KD_FONT_FLAG_* */
unsigned int width, height;
unsigned int charcount;
unsigned char *data;/* font data with height fixed to 32 */ };
fbcon blitting rectangular blobs onto the screen doesn't even remotely qualify as "parsing fonts". Doing TrueType in the kernel, which is what Windows does here, is patently insane.
Even if we assume your interpretation, you're still horribly confused. You're mixing up 16-bit indexed images (16 bits per palette index), which pretty much don't exist (and which GIMP doesn't support - if you actually try what you just described you'll see that GIMP clamps the number of colors down to 256) and 16-bit RGB images (RGB 5-6-5), which do exist in many embedded devices, and which as far as I can tell GIMP has no support for either (other than perhaps via a plugin). I had to dither/quantize a PNG down to 16-bit RGB565 color recently and I ended up having to resort to an ImageMagick recipe, because GIMP couldn't do it. I also suspect you might also be confusing all of this with 16-color (4-bit) images, given that you mentioned bootloaders (grub1 bootloader backgrounds are 14-color images, i.e. 16 colors minus two reserved colors, that *can* in fact be made using GIMP's indexed mode).
16 bits per channel RGB != 16-bit indexed != 16-bit RGB565 != 16-color (4-bit) indexed. Get them straight.
Figuring out how to pair your Wii mote via bluetooth, not so much.
Johnny Lee didn't actually hack the Wiimote; what he did was pull off a very cool hack using the Wiimote. The original reverse engineering was done by other people, myself included. He is indeed more of a modder (though he very much deserves the praise - anyone can play around with devices, but it takes someone special to envision and develop the applications that he did).
The article is pretty silly though. Big corporations hire all the time, and most of the people they hire you've never heard of. Why is it news that they also happen to hire hackers? I know plenty of hackers with day jobs at big companies; it's not exactly unheard of or weird. Newsflash: most hackers are good developers and companies like hiring good developers.
The bigger question is whether the hackers want to be employed by big companies. Some do, some don't.
It's called a Plenoptic Camera. You put a bunch of microlenses on top of a regular sensor. Each lens is the equivalent of a single 2D image pixel, but the many sensor pixels under it capture several variations of that pixel in the light field. Then you can apply different mapping algorithms to go from that sub-array to the final pixel, refocusing the image, changing the perspective slightly, etc. So color-wise it's just a regular camera. What you get is an extra two spatial dimensions (the image contains 4 dimensions of information instead of 2).
Of course, the drawback is that you lose a lot of spatial resolution since you're dividing down the sensor resolution by a constant. I doubt they can do anything interesting with less than 6x5 pixels per lens, so a 25 megapixel camera suddenly takes 1 megapixel images at best. The Wiki article does mention a new trick that overcomes this to some extent though, so I'm not sure what the final product will be capable of.
Playing DVDs isn't measurably more stressful than playing games. In fact, quite the opposite: DVDs play linearly and at a lower data rate than games. I've heard this myth several times but never with an actual report of it happening. As far as I'm concerned, it's an urban legend.
You can't track the money specifically, though. You can see what accounts it was sent to, but any money coming out of those accounts becomes suspect. There is no connection between the money coming into an account and the money coming out of an account. If the thief does his laundering right, eventually the money will fan out to accounts that also process legitimate transactions and you'll lose track of where it went. Once the money reaches an account that already has a balance, it becomes indistinguishable from the rest of that balance.
Of course, if all the thief does is break up the money into hundreds of different single-purpose accounts only to send it all to the same place in the end, then yes, you can reconstruct the transaction graph and track him down.
There was no filesystem support. When I said that the Wii had DVD support, I meant it had the software and hardware infrastructure in place to read sectors from a DVD-Video/DVD-R (as well as handle the CSS key area and other details). Pirated games don't use ISO9660 either, they're just raw image copies of the original (which uses a custom Wii filesystem). The filesystem code is actually part of the game executable. A hypothetical "DVD Channel" would've had to include ISO9660/UDF filesystem code, the CSS support, and the actual MPEG2 video player and DVD menu support. In other words, exactly the same things that homebrew DVD players implement.
It would be entirely possible (even easy) to use a USB optical drive to play copied games in DVD-R form, but quite useless since you might as well just load them from a USB hard drive at that point.
Recent Wiis can't play DVDs with or without extra software. They removed that feature from the drive firmware (to stop piracy tools that redirected "read game" commands to "read DVD" commands to play pirated games without any hardware mods, from DVD-Rs). I'd expect them to do the same thing with the WiiU and never have the drive firmware support to do that in the first place.
Of course, on the Wii, the drive firmware is in ROM. Maybe the WiiU will use Flash firmware, which would open it up to all kinds of hacks (including 360-like drive firmware flashing...)
Didn't work for the Wii (business-wise, for unknown reasons). They had it set up exactly like that, where they could've released a "DVD Channel" on WiiWare at any time. All of the system and firmware support for DVD-Video playback was in there. But they never did.
Thaa was different: the Wii drive _was_ capable of reading DVDs, _deliberately_, and Nintendo had all of the software infrastructure in place to read DVDs. They just never used it.
They nuked the physical DVD support in the last batch of drives in order to stop softmod piracy (not that that did anything, since everyone uses USB loaders these days). You can't run the DVD-using homebrew on those Wiis, nor will you ever be able to. The drive firmware just lost the capability to read DVD-format discs entirely.
What possible reason is there to use something that costs more and needs more cooling, as well as being an older architecture anyway?
None, but Nintendo likes stupid engineering like that. Case in point: the 3DS. Using ARM11 when Cortex-A8 has been out for a long time now, at better performance and lower power usage. And people wonder why the 3DS's battery life sucks.
The Wii could read DVDs from the beginning. The SDK even had DVD functions and the graphics chip has the requisite Macrovision crap to legally enable DVD playback. The system firmware has a flag for enabling DVD mode. They could've released a "DVD Channel" on the WiiWare store to enable DVD playback. If they didn't, it was a business decision, not a technical one.
Newer Wii hardware nixed DVD playback because it was being used to pirate games (if you can read DVDs, you can read DVD-Rs; if you can read DVD-Rs, you can patch system firmware to make games transparently read DVD-Rs as if they were originals).
That's basically what makes them "leaders of Anonymous", according to the police. Supposedly one of them ran an IRC server at home and the three were IRC operators. That's all. There's even a hilarious police screenshot featuring an IRC client and three huge red arrows. Because everyone knows that huge red arrows means they're the Bad Guys.
They're blaming some of the playstation store DDoS attacks on them (which Anonymous did take responsibility for), as well as DDoSing the SGAE (spanish RIAA) and some government websites as a response to recent legislation and social unrest. None of this has nothing to do with the PSN breach, it was just the usual Anonymous DDoS modus operandi.
New IRC server up in three, two,... oh, wait, they probably set one up within minutes, certainly before Slashdot managed to pick up the story.
All of this seems to be a useless operation just so they can claim that they got *someone* for some of the DDoS attacks on government sites. Even the police knows this isn't going to stop anything, they're just making it look like some big breakthrough to appease the "victims" of the attacks.
They're charging them with a violation that could get them one to three years in prison. So, for now they're free (you don't get preventative imprisonment for that kind of charge), and I'd say there's a pretty good chance they'll end up dropping the charges due to lack of evidence.
Sony used a real RNG, they just had the brilliant idea of using it once and storing the output as a constant. Seriously. The random nonces were different for each keyset, but the same for each signature made with a specific key - they were storing the nonces as part of the private key, as far as we can tell.
That's an interesting idea. Unfortunately it wouldn't work with PBKDF2, because the output of PBKDF2 isn't equivalent to an intermediate step (you can't hash it further to increase the strength and come up with the equivalent of running PBKDF2 with a larger number of iterations to begin with). Of course, you could just rehash passwords as people enter them to log in, but chances are a significant portion of your database (people with abandoned accounts) will keep using the old hash, unless you regularly purge those accounts.
What you suggest would work with PBKDF1, which is probably sufficient for password hashing purposes (you could use a simple SHA-2 extension of PBKDF1 to increase security, since PBKDF1 usually uses SHA-1).
There's a reason why PBKDF2 doesn't work (by design). Quoting from the RFC:
Note. The construction of the function F follows a "belt-and-suspenders" approach. The iterates U_i are computed recursively to remove a degree of parallelism from an opponent; they are exclusive-ored together to reduce concerns about the recursion degenerating into a small set of values.
With PBKDF1 you lose the XORs, so you lose a certain degree of protection against problems with the underlying hash function, but you gain the ability to increase the iteration count of the hash after the fact.
Crypt::SaltedHash is significantly less secure than PBKDF2. It doesn't iterate the hash, which is a very good idea for password hashes, as it significantly increases the cracking time (very important for not-so-good passwords). Hashes are meant to be fast, so deliberately slowing down the algorithm helps a lot. Going from 10000000 cracking attempts per second to 10 cracking attempts per second is going to stop a lot of attacks, and all it takes is using a properly designed algorithm instead of just sticking the password and a salt into a hash (which is what SaltedHash does).
Inventing your own method of hashing passwords (based on a standard hashing algorithm) counts as making up your own cryptosystem (sadly, the vast majority of web programmers seem to fall into this trap). You should be using a standard password hashing mechanism, such as PBKDF2 (RFC2898). Although the name implies symmetric key derivation (Password-Based Key Derivation Function 2), it works just as well for hashing a password before storing it in a database, and it's much better than 99% of the schemes in use out there.
Sony was using pretty much every modern cryptographic algorithm in every possible way. All at once. And that is why they failed miserably.
People who think cryptosystems are made of buzzwords like AES and SHA and ECDSA and numbers of bits are doomed to create insecure pieces of crap. To make a secure cryptosystem you only need a couple good algorithms and, most importantly, one or more professional cryptographers to design the overall system for you. Or do the sane thing, and use an existing cryptosystem correctly instead of even thinking about rolling your own.
You can probably come up with a very secure scheme, but if no one's browser can handle it, you'll be playing with yourself!
Quite the opposite. The chances of someone coming up with something nontrivial that is more secure than SSL on their own are practically zero. Inventing your own cryptosystem is a sure-fire way to end up with something insecure. Don't do it.
To the original asker:
Calling SHA-512 (a cryptographically secure hash) "encryption" is your first clue that you need to either 1) calm down, learn about moderm crypto, about what all of those funky acronyms and bit sizes mean in practice, or 2) hire someone who does. There is no "shortcut". If you plan to use SSL, at the very least you need to know the difference between a cipher and a hash, and some vital information about the different choices that you can make.
And please, please, please don't invent workarounds, hacks, wrappers, tricks, or anything else on top of SSL or any other cryptosystem, like that multiple stream thing (and don't even think about implementing your own from scratch). These systems were (hopefully) designed by experts in cryptography who know the implications of their design decisions, which can be devastating for security if done wrong. They don't need wrappers or workarounds to stay secure, and they certainly don't need to be reinvented. "Shotgun cryptography" (throw every buzzword and algorithm in there, because more bits and more layers is more secure!!1) is exactly what made the PS3 a cryptographic laughingstock and gave everyone Sony's private keys. Don't make that kind of mistake. SSL works just fine as is, and you can almost certainly make it do whatever you actually need without having to hack around it.
I could write a few lines attempting to answer your questions about SHA-512, the SHA-1 attacks, etc., but I won't, because the questions are wrong to begin with. Start by understanding what you're asking first, then you'll be able to ask relevant questions. You don't need blind instructions that are ultimately going to lead you somewhere without really knowing where you're going; what you need to do is get a map and figure out where you are and where you want to go first.
Slashdot Mirror
My opinion, as someone who has both solved and organized several challenges of this sort, is that the challenge is neither hard (at least by the standards of the ones I've dealt with) nor well designed. In fact, it kind of degenerates: it starts out OK but the ending is terrible.
Stage 1 is interesting: it combines recognizing executable code (the first thing I thought when I stared at that hex dump is "this looks like x86 code", but being able to recognize binary architectures is a valuable skill) combined with some steganography (fishing out the rest of the required data from the PNG. Fair enough, and OK for a first round.
Stage 2 starts out well: virtual machines are used for obfuscation and make fun challenges. However, the execution is backwards. Being given VM bytecode and a specificiation to implement a VM isn't a hacking or reverse engineering challenge; it's just work ("go implement this for me"). A much better challenge would be to be given either the spec or (preferably) code that implements it, and then have to reverse engineer the bytecode itself to solve the puzzle. That involves writing a custom disassembler, which is a much more interesting task.
Stage 3 is a clusterfuck. It's just an executable that checks for a few constants in a file and then builds a URL out of the rest of it. There's a hash (old-school DES crypt() salted password) that the input has to match, but even though it's crackable using a dictionary, you don't even have to do that because the URL includes the hash (which is in the executable), not the plaintext! The rest of the URL isn't checked, and it's basically a guessing game where you have to fish out constants from previous levels. It's just a glorified way of saying "okay, now take a wild guess as to what numbers to stick in the URL". It's not realistic in the slightest.
Anyone interested in a "better stage 2" might want to check out a level that I put together for the Hack-It competition at the 18th Euskal Encounter (2010). Your goal is to figure out the 64-bit input key that works (if you don't know what "works" means, compile and run the code and it should be obvious). The full set of challenges can be found here: 2010 2011 (unfortunately, the website / problem statements are in Spanish, but I'm sure you can work it out with a bit of copy/pasting into Google Translate - if there's enough interest I'll translate them to English).
The kernel doesn't parse fonts. A userspace program parses the fontfile (which could easily be TrueType if someone feels like supporting that, though it would have to be monospaced). The kernel only gets a raw monochrome bitmap data array for the characters, a width and height, and optionally a character map. No parsing is done in the kernel.
KDFONTOP ioctl arguments: /* KD_FONT_OP_* */ /* KD_FONT_FLAG_* */ /* font data with height fixed to 32 */
struct console_font_op {
unsigned int op;
unsigned int flags;
unsigned int width, height;
unsigned int charcount;
unsigned char *data;
};
fbcon blitting rectangular blobs onto the screen doesn't even remotely qualify as "parsing fonts". Doing TrueType in the kernel, which is what Windows does here, is patently insane.
Use symlinks. Yes, they exist in all three major OSes.
Even if we assume your interpretation, you're still horribly confused. You're mixing up 16-bit indexed images (16 bits per palette index), which pretty much don't exist (and which GIMP doesn't support - if you actually try what you just described you'll see that GIMP clamps the number of colors down to 256) and 16-bit RGB images (RGB 5-6-5), which do exist in many embedded devices, and which as far as I can tell GIMP has no support for either (other than perhaps via a plugin). I had to dither/quantize a PNG down to 16-bit RGB565 color recently and I ended up having to resort to an ImageMagick recipe, because GIMP couldn't do it. I also suspect you might also be confusing all of this with 16-color (4-bit) images, given that you mentioned bootloaders (grub1 bootloader backgrounds are 14-color images, i.e. 16 colors minus two reserved colors, that *can* in fact be made using GIMP's indexed mode).
16 bits per channel RGB != 16-bit indexed != 16-bit RGB565 != 16-color (4-bit) indexed. Get them straight.
Johnny Lee didn't actually hack the Wiimote; what he did was pull off a very cool hack using the Wiimote. The original reverse engineering was done by other people, myself included. He is indeed more of a modder (though he very much deserves the praise - anyone can play around with devices, but it takes someone special to envision and develop the applications that he did).
The article is pretty silly though. Big corporations hire all the time, and most of the people they hire you've never heard of. Why is it news that they also happen to hire hackers? I know plenty of hackers with day jobs at big companies; it's not exactly unheard of or weird. Newsflash: most hackers are good developers and companies like hiring good developers.
The bigger question is whether the hackers want to be employed by big companies. Some do, some don't.
It's called a Plenoptic Camera. You put a bunch of microlenses on top of a regular sensor. Each lens is the equivalent of a single 2D image pixel, but the many sensor pixels under it capture several variations of that pixel in the light field. Then you can apply different mapping algorithms to go from that sub-array to the final pixel, refocusing the image, changing the perspective slightly, etc. So color-wise it's just a regular camera. What you get is an extra two spatial dimensions (the image contains 4 dimensions of information instead of 2).
Of course, the drawback is that you lose a lot of spatial resolution since you're dividing down the sensor resolution by a constant. I doubt they can do anything interesting with less than 6x5 pixels per lens, so a 25 megapixel camera suddenly takes 1 megapixel images at best. The Wiki article does mention a new trick that overcomes this to some extent though, so I'm not sure what the final product will be capable of.
Playing DVDs isn't measurably more stressful than playing games. In fact, quite the opposite: DVDs play linearly and at a lower data rate than games. I've heard this myth several times but never with an actual report of it happening. As far as I'm concerned, it's an urban legend.
You can't track the money specifically, though. You can see what accounts it was sent to, but any money coming out of those accounts becomes suspect. There is no connection between the money coming into an account and the money coming out of an account. If the thief does his laundering right, eventually the money will fan out to accounts that also process legitimate transactions and you'll lose track of where it went. Once the money reaches an account that already has a balance, it becomes indistinguishable from the rest of that balance.
Of course, if all the thief does is break up the money into hundreds of different single-purpose accounts only to send it all to the same place in the end, then yes, you can reconstruct the transaction graph and track him down.
Going from ARM7/9 to ARM11 isn't significantly less compatible than going from ARM7/9 to Cortex-A8.
There was no filesystem support. When I said that the Wii had DVD support, I meant it had the software and hardware infrastructure in place to read sectors from a DVD-Video/DVD-R (as well as handle the CSS key area and other details). Pirated games don't use ISO9660 either, they're just raw image copies of the original (which uses a custom Wii filesystem). The filesystem code is actually part of the game executable. A hypothetical "DVD Channel" would've had to include ISO9660/UDF filesystem code, the CSS support, and the actual MPEG2 video player and DVD menu support. In other words, exactly the same things that homebrew DVD players implement.
It would be entirely possible (even easy) to use a USB optical drive to play copied games in DVD-R form, but quite useless since you might as well just load them from a USB hard drive at that point.
Recent Wiis can't play DVDs with or without extra software. They removed that feature from the drive firmware (to stop piracy tools that redirected "read game" commands to "read DVD" commands to play pirated games without any hardware mods, from DVD-Rs). I'd expect them to do the same thing with the WiiU and never have the drive firmware support to do that in the first place.
Of course, on the Wii, the drive firmware is in ROM. Maybe the WiiU will use Flash firmware, which would open it up to all kinds of hacks (including 360-like drive firmware flashing...)
Didn't work for the Wii (business-wise, for unknown reasons). They had it set up exactly like that, where they could've released a "DVD Channel" on WiiWare at any time. All of the system and firmware support for DVD-Video playback was in there. But they never did.
Thaa was different: the Wii drive _was_ capable of reading DVDs, _deliberately_, and Nintendo had all of the software infrastructure in place to read DVDs. They just never used it.
They nuked the physical DVD support in the last batch of drives in order to stop softmod piracy (not that that did anything, since everyone uses USB loaders these days). You can't run the DVD-using homebrew on those Wiis, nor will you ever be able to. The drive firmware just lost the capability to read DVD-format discs entirely.
None, but Nintendo likes stupid engineering like that. Case in point: the 3DS. Using ARM11 when Cortex-A8 has been out for a long time now, at better performance and lower power usage. And people wonder why the 3DS's battery life sucks.
The Wii could read DVDs from the beginning. The SDK even had DVD functions and the graphics chip has the requisite Macrovision crap to legally enable DVD playback. The system firmware has a flag for enabling DVD mode. They could've released a "DVD Channel" on the WiiWare store to enable DVD playback. If they didn't, it was a business decision, not a technical one.
Newer Wii hardware nixed DVD playback because it was being used to pirate games (if you can read DVDs, you can read DVD-Rs; if you can read DVD-Rs, you can patch system firmware to make games transparently read DVD-Rs as if they were originals).
The coliseum icon is Nero Burning ROM.
I wouldn't be surprised one bit if they warezed mIRC.
Judging by the uTorrent icon, my guess is they didn't.
They're already free - the charges they're pushing aren't enough to warrant preventative imprisonment.
That's basically what makes them "leaders of Anonymous", according to the police. Supposedly one of them ran an IRC server at home and the three were IRC operators. That's all. There's even a hilarious police screenshot featuring an IRC client and three huge red arrows. Because everyone knows that huge red arrows means they're the Bad Guys.
They're blaming some of the playstation store DDoS attacks on them (which Anonymous did take responsibility for), as well as DDoSing the SGAE (spanish RIAA) and some government websites as a response to recent legislation and social unrest. None of this has nothing to do with the PSN breach, it was just the usual Anonymous DDoS modus operandi.
New IRC server up in three, two, ... oh, wait, they probably set one up within minutes, certainly before Slashdot managed to pick up the story.
All of this seems to be a useless operation just so they can claim that they got *someone* for some of the DDoS attacks on government sites. Even the police knows this isn't going to stop anything, they're just making it look like some big breakthrough to appease the "victims" of the attacks.
They're charging them with a violation that could get them one to three years in prison. So, for now they're free (you don't get preventative imprisonment for that kind of charge), and I'd say there's a pretty good chance they'll end up dropping the charges due to lack of evidence.
Sony used a real RNG, they just had the brilliant idea of using it once and storing the output as a constant. Seriously. The random nonces were different for each keyset, but the same for each signature made with a specific key - they were storing the nonces as part of the private key, as far as we can tell.
That's an interesting idea. Unfortunately it wouldn't work with PBKDF2, because the output of PBKDF2 isn't equivalent to an intermediate step (you can't hash it further to increase the strength and come up with the equivalent of running PBKDF2 with a larger number of iterations to begin with). Of course, you could just rehash passwords as people enter them to log in, but chances are a significant portion of your database (people with abandoned accounts) will keep using the old hash, unless you regularly purge those accounts.
What you suggest would work with PBKDF1, which is probably sufficient for password hashing purposes (you could use a simple SHA-2 extension of PBKDF1 to increase security, since PBKDF1 usually uses SHA-1).
There's a reason why PBKDF2 doesn't work (by design). Quoting from the RFC:
With PBKDF1 you lose the XORs, so you lose a certain degree of protection against problems with the underlying hash function, but you gain the ability to increase the iteration count of the hash after the fact.
Crypt::SaltedHash is significantly less secure than PBKDF2. It doesn't iterate the hash, which is a very good idea for password hashes, as it significantly increases the cracking time (very important for not-so-good passwords). Hashes are meant to be fast, so deliberately slowing down the algorithm helps a lot. Going from 10000000 cracking attempts per second to 10 cracking attempts per second is going to stop a lot of attacks, and all it takes is using a properly designed algorithm instead of just sticking the password and a salt into a hash (which is what SaltedHash does).
Inventing your own method of hashing passwords (based on a standard hashing algorithm) counts as making up your own cryptosystem (sadly, the vast majority of web programmers seem to fall into this trap). You should be using a standard password hashing mechanism, such as PBKDF2 (RFC2898). Although the name implies symmetric key derivation (Password-Based Key Derivation Function 2), it works just as well for hashing a password before storing it in a database, and it's much better than 99% of the schemes in use out there.
Sony was using pretty much every modern cryptographic algorithm in every possible way.
All at once.
And that is why they failed miserably.
People who think cryptosystems are made of buzzwords like AES and SHA and ECDSA and numbers of bits are doomed to create insecure pieces of crap. To make a secure cryptosystem you only need a couple good algorithms and, most importantly, one or more professional cryptographers to design the overall system for you. Or do the sane thing, and use an existing cryptosystem correctly instead of even thinking about rolling your own.
Quite the opposite. The chances of someone coming up with something nontrivial that is more secure than SSL on their own are practically zero. Inventing your own cryptosystem is a sure-fire way to end up with something insecure. Don't do it.
To the original asker:
Calling SHA-512 (a cryptographically secure hash) "encryption" is your first clue that you need to either 1) calm down, learn about moderm crypto, about what all of those funky acronyms and bit sizes mean in practice, or 2) hire someone who does. There is no "shortcut". If you plan to use SSL, at the very least you need to know the difference between a cipher and a hash, and some vital information about the different choices that you can make.
And please, please, please don't invent workarounds, hacks, wrappers, tricks, or anything else on top of SSL or any other cryptosystem, like that multiple stream thing (and don't even think about implementing your own from scratch). These systems were (hopefully) designed by experts in cryptography who know the implications of their design decisions, which can be devastating for security if done wrong. They don't need wrappers or workarounds to stay secure, and they certainly don't need to be reinvented. "Shotgun cryptography" (throw every buzzword and algorithm in there, because more bits and more layers is more secure!!1) is exactly what made the PS3 a cryptographic laughingstock and gave everyone Sony's private keys. Don't make that kind of mistake. SSL works just fine as is, and you can almost certainly make it do whatever you actually need without having to hack around it.
I could write a few lines attempting to answer your questions about SHA-512, the SHA-1 attacks, etc., but I won't, because the questions are wrong to begin with. Start by understanding what you're asking first, then you'll be able to ask relevant questions. You don't need blind instructions that are ultimately going to lead you somewhere without really knowing where you're going; what you need to do is get a map and figure out where you are and where you want to go first.