PAX Concerts were incredible
on
PAX05 Writeup
·
· Score: 5, Informative
OK, seriously, _you_ show me another concert that starts out with classical piano, moves onto nerdcore hiphop, and finishes up with metal -- with the audience equally pleased with all three.
Now have two of them, two nights in a row. Rawk.
Couple amusing highlights:
Bawls is going hardcore. They had a...brace for it...Bawls Slurpee Machine. And It Was Good. As if that was not enough...there were some sort of caffeinated yet vaguely carbonated Bawls Pillform spawned in a pitcher that would be poured into confused but curious hands. Yum.
Take Defcon. Swap Hackers for Gamers. Swap Hot Vegas for Overcast Washington. Swap Feds for...I dunno...Nintendo? Still, the entire thing had the feel of an Alternate Reality Defcon, replete with everyone just so damn happy to be around so many other people who understood them. I mean, just look at Phil here. Happy! (A wink to anyone who sees the very subtle Defcon reference.)
At Penny Arcade Expo, cosplay girl photograph YOU (in Defcon T-Shirt).
Still, I cannot get over the concerts. Before the Saturday night show began, it was unveiled that there'd be a special act...see, there was this huge gaming competition called the Omegathon, and a mystery game had been decided upon...Karaoke Revolution...with 1700 geeks assembled to watch.
Bet Konami never planned for this.
For those not familiar with Karaoke Revolution, it's basically a game where you're scored on how well your pitch matches what the game tells you you're supposed to be singing. Now, gamers generally do not sing, but it's 2005 and it's time to expand the market (and the eyeballs of these poor geeks that just want to win every NES game ever released). With 1700 people cheering on, we watched...
Two possible reactions:
1) Complete withdrawl 2) Complete insanity
The second was entertaining in its own right, but the first was best represented by...Leroy. Now, these are gaming geeks. Gamers + Leroy = LeeeeROYYYYYYYY!. To say he was cheered on would be an understatement...and to say he didn't take it so well...so the guy's about three fourth through the round, and hasn't managed to sing a single note right. Finally, after much struggling, he gets...one note right. He's on the board! Applause thunders through the audience!
LEEEEEEEEEEROY!
OK. Maybe you had to be there. But it was a truly magical moment.
But about the actual concerts.
Both the Video Game Pianist and Connie Lin were incredible, and MC Chris was more insane than I had any right to expect...but the real surprise, for me anyway, was MC Frontalot. I'd say all sorts of stuff about him, but just grab the single. His CD is great, try not to get it off Bittorrent. Cool guy, too.
It wasn't all hype and noise. Actually just sitting down with a random geek and playing Soul Caliber 2 for the first time in ages was just pure fun. And seeing the faces of all these kids see
Both attacks are based on the idea that the algorithms are necessarily fuzzy, and as such emit not just an oracular "match/not match" but a weighting regarding how accurate the matching is. As such, you basically can perturb the underlying data slightly, run it through the algorithm, and then see if you got closer or farther from the source biometric.
Fingerprint reversal already creates viable (if not completely accurate) candidates. Faces? Well, see the PDF, but they can be made recognizable. (You just, widen the brow, shrink the nose, widen the mouth, whatever incrementally until you achieve match.)
Now, suppose you add a warping factor to faces. Does this help? The stored biometric must contain the warping parameters (since the incoming image must be similarly modified), so we're left with two possibilities:
1) The warping is severe -- not only does the resulting image bear no resemblance to a human face, but so much pixel intermixing has occurred that it'd be near meaningless to invert the warp vectors to try to get back to a meaningful face.
2) The warping isn't so severe, and you can just invert the stored vectors.
Case 1 is what they're implying, but Case 1 doesn't allow for significant features above and beyond what's created by the vector field itself. In other words, almost any face would match, if the warp vectors were irreversable. Put another way -- if the face detection algorithm is able to find a feature, we're able to reverse back to what the feature looks like, and if we're not able to reverse back, we almost certainly can't have a face detector find the feature.
My assumption, then -- and again, this is without seeing detailed research (I happily discount the examples CNN provided...it can't be _that_ bad) -- is that this technique doesn't work against hot/cold style attacks against the biometric algorithm. If the researchers care to clarify -- please mail me, or respond!
Basically, everyone's holding up their games for Christmas, because why release in August if you can sell three times as much in November?
This has really wiped out the PSP as a platform for the time being, though. Lumines is great but it's not $300 great, and there's nothing else I want, even a little.
They really should have done the mass-portage, best of PS1/PS2, and dribbled the stuff out until Christmas.
Get into the real world, of detailed data though -- suddenly, all the detailed data is in the literature. We must find a way to expose that data to the new mechanisms of search -- searching indices of books in the Dewey Decimal System is over, and it's now a matter of factual extinction vs. getting the data out there.
The original question was, why is Whirlpool an AES *variant* (and thus, not hardware accelerable using the same equipment) and not AES itself?
The answer, which I've found while talking with you, is that AES was only deeply audited at that 128 bit level, and 128 bits is an insufficient cipher strength. This leaves two options for remediation:
1) Alter the cipher, such that instead of 128 bits of output, it emits 512, or
2) Alter the mode, so that the 128 bit cipher emits a 512 bit authentication block.
The advantage of the latter is you get to use existing hardware, and the strength of your system should theoretically equal the strength of your block cipher (given an appropriate mode). I do not see an advantage to the former, except that it's arguably more elegant to have all your security in the cipher, rather than partially in the cipher and partially in the mode. But since ultimately you always have a split between cipher and mode, that doesn't seem great either.
Most of those MAC's can be used with an arbitrary block cipher (like, for example, genuine AES). A MAC with a known, fixed key degrades to a cryptographic hash, and doesn't require anything but genuine AES.
"There should be a firewall on every desktop" done "Patches should just show up one day, stupid users shouldn't have to think to install them" done "Damn compiler shouldn't allow buffer overflows" done (to the degree to which it's possible)
All these exploits are against a five year old OS. XP's moved on.
"However, Whirlpool, SHA-256, SHA-384, and SHA-512 are newly designed primitives which have undergone only limited evaluation by the crytpographic community so far."
Cryptosystems are fragile things. Whereas I can construct a hash out of Rijndael proper, what is my justification for instead using this variant -- one that did not pass the brutal AES audit?
Moving target. Yes, second preimage resistance (given md5(x), make y such that md5(y) = md5(x)) is important, but right now we have "given x and y, alter both such that md5(x) = md5(y)" and that flat out violates "computationally infeasible to find two files with the same hash".
Dude, I was making an oblique reference to Whirlpool:) I don't think it specifically will be selected as the next hash mechanism though, because though it's *similar* to AES, it's *not*, and that means the AES hardware accelerators probably can't be made to execute it.
I've not seen a good public explanation for the differences between its design and that of Rijndael. Any light you can shed?
It's broken, because it doesn't meet its design constraint ("computationally infeasible to find two files with the same hash"). We can fix the problem by moving to a non-broken hash. Unfortunately all the popular hashing algorithms are based on a similar mechanism, and they're all falling to Wang's modular differential attack. Best I can tell, we'll have some AES-as-hash variant get named as the next big hash mechanism.
You could easily use HTML to display different images, but a basic forensic analysis would show that. The only situation we were able to find where an MD5 collision would be undetectable (until it was too late) involved using the colliding files directly as primes seeding a cryptographic function. Supposing two matched files, X and Y, with X being integer-parseable as a prime and Y not, you could show X in a Diffie-Helman system as the prime you claimed to use, but Y as the one you actually did -- and there'd be no way, after the fact, to detect that you actually used the non-prime (and thus crackable) output. There'd also likely be no way to see, just having X, that a Y existed elsewhere.
The irony is, if you're sitting there with a botnet of 100,000 hosts, you don't care about blocking -- you're big enough to disperse your traffic across too many hosts.
Networks are alot better at defending against Protoss than Zerg, it seems:(
I'll know how many zones allow full crawling sometime this month or next. Did you know any DNSSEC zone can be crawled? Huge bug. Oops.
Basically, in 2004 Xiaoyun Wang released two different files with the same MD5 hash. This has been predicted since around 1996, when Hans Dobbertin showed the hash was broken -- but it took a while for the actual attack to show up.
Alot of people said there were _no_ applied uses. Not true. For instance, the following two pages have the same hash:
What's important to realize about the above content is that both web pages are included in both links; the difference between the source files (which MD5 is blind to) is just used to determine which page is displayed. What that means is that, for forensic purposes, it's trivial to rule out the best known attack against MD5 -- just look at the content being hashed.
Thats not to say we should keep using MD5. It's broken, we need to move on. But attempts to claim that MD5 is broken, so we have no idea of any link between hashed content and real material -- that's just ridiculous. We have plenty of idea, especially with human-guided forensic operations.
That being said -- if you can doctor a photo, you can doctor a hash. This is one of the things that makes files hosted on a single server w/ MD5 hashes "verifying" them a little silly...if you can alter the file, you can alter the.md5 file as well. (Files on multiple servers are a little different, because you can go elsewhere to see the deviating MD5 hash.)
For the most part, credible security researchers follow some variant of this document. Given that:
"1. You should be able to fix this in two days"
No, the document says you need to communicate with the researcher within five days. Microsoft has managed to get responses back to people within twenty four hours -- you can at least talk to people within five times that.
"2. The more notorious I am, the more business I will get"
Frankly, there are absolutely awful security advisories. (That "Monad can be used to write worms" garbage is probably the single most embarassing announcement in the history of our industry, though Secunia's DHS advisory that somehow implied a vuln in LibTiff was remote-critical was pretty bad too). If it's this bad when people talk, imagine how bad it can be from people who don't even try to have a public presence.
That being said -- burning vendors is good for nobody, and I have no particular sympathy for those who ignore the rules and just try to embarass people. But lets be honest -- both parties in the equation can embarass themselves, and the system that's evolved has managed to create the otherwise non-existent cost pressure to solve the problem.
How much money did Oracle make from calling themselves "Unbreakable"? Implies there was a rather significant market desire for what security researchers independently establish.
"3. I should always get credit for vulnerabilities I find"
If you release something you know is bad, and do it anyway because you figure the cost of releasing the product is less than the cost of fixing it -- well, the auto industry has a long and colorful history of doing that, and look at the legislative recall framework that evolved out of that.
Why hasn't similar legislation hit the tech world? Because the community of experts who would normally be calling for it has been otherwise co-opted. Good job, keep it up.
At some point, credit can be for forcing a fault to get fixed, not just for finding the fault. I've been in the large corporate environment -- hell, I've found remote roots in deployed products directly because of Oracle 8's broken TNS listener -- that *someone* in your organization found something is never, ever as compelling a reason to address the fault as someone *outside* the company finding something. Credit is more than just finding the flaw, it's finding it without sufficient internal documentation to know where to look. And the threat -- to be very explicit -- is if someone outside your organization, with no source code, can find the problem, so can a malicious attacker.
Security researchers represent hackers who behave as the malicious might but instead work with a vendor. There are inevitably tweaks necessary to the process -- but the process itself is critical, lest we experience its legislative opposite.
Yeah, great paper Luis. Check out my slides from this year to see how I used similar methods to divine interrelationships. Hell, you're directly named in last year's slides. Really good work.
The 1999-2000 era of DNS poisoning focused on exploits. Then we had Kashpureff force the hand of BIND to implement all that complex bailiwick verification stuff, so a query for foo.com couldn't return glue for google.com (though the protocol really wants you to be able to do that). The recent stuff focuses on a situation where bailiwicks are ignored, i.e. forwarders. It was considered to be an obscure situation...I had NO IDEA there was so much forwarding going on.
Slashdot Mirror
Now have two of them, two nights in a row. Rawk.
Couple amusing highlights:
Still, I cannot get over the concerts. Before the Saturday night show began, it was unveiled that there'd be a special act...see, there was this huge gaming competition called the Omegathon, and a mystery game had been decided upon...Karaoke Revolution...with 1700 geeks assembled to watch.
Bet Konami never planned for this.
For those not familiar with Karaoke Revolution, it's basically a game where you're scored on how well your pitch matches what the game tells you you're supposed to be singing. Now, gamers generally do not sing, but it's 2005 and it's time to expand the market (and the eyeballs of these poor geeks that just want to win every NES game ever released). With 1700 people cheering on, we watched...
Two possible reactions:
1) Complete withdrawl
2) Complete insanity
The second was entertaining in its own right, but the first was best represented by...Leroy. Now, these are gaming geeks. Gamers + Leroy = LeeeeROYYYYYYYY!. To say he was cheered on would be an understatement...and to say he didn't take it so well...so the guy's about three fourth through the round, and hasn't managed to sing a single note right. Finally, after much struggling, he gets...one note right. He's on the board! Applause thunders through the audience!
LEEEEEEEEEEROY!
OK. Maybe you had to be there. But it was a truly magical moment.
But about the actual concerts.
Both the Video Game Pianist and Connie Lin were incredible, and MC Chris was more insane than I had any right to expect...but the real surprise, for me anyway, was MC Frontalot. I'd say all sorts of stuff about him, but just grab the single. His CD is great, try not to get it off Bittorrent. Cool guy, too.
It wasn't all hype and noise. Actually just sitting down with a random geek and playing Soul Caliber 2 for the first time in ages was just pure fun. And seeing the faces of all these kids see
First of all, lets link to the research on how hashes are reversed:
0 3/adler-2003-fr-templates.pdf
Fingerprint Readers: http://chris.fornax.net/biometrics.html
Face Recognizers
http://www.site.uottawa.ca/~adler/publications/20
Both attacks are based on the idea that the algorithms are necessarily fuzzy, and as such emit not just an oracular "match/not match" but a weighting regarding how accurate the matching is. As such, you basically can perturb the underlying data slightly, run it through the algorithm, and then see if you got closer or farther from the source biometric.
Fingerprint reversal already creates viable (if not completely accurate) candidates. Faces? Well, see the PDF, but they can be made recognizable. (You just, widen the brow, shrink the nose, widen the mouth, whatever incrementally until you achieve match.)
Now, suppose you add a warping factor to faces. Does this help? The stored biometric must contain the warping parameters (since the incoming image must be similarly modified), so we're left with two possibilities:
1) The warping is severe -- not only does the resulting image bear no resemblance to a human face, but so much pixel intermixing has occurred that it'd be near meaningless to invert the warp vectors to try to get back to a meaningful face.
2) The warping isn't so severe, and you can just invert the stored vectors.
Case 1 is what they're implying, but Case 1 doesn't allow for significant features above and beyond what's created by the vector field itself. In other words, almost any face would match, if the warp vectors were irreversable. Put another way -- if the face detection algorithm is able to find a feature, we're able to reverse back to what the feature looks like, and if we're not able to reverse back, we almost certainly can't have a face detector find the feature.
My assumption, then -- and again, this is without seeing detailed research (I happily discount the examples CNN provided...it can't be _that_ bad) -- is that this technique doesn't work against hot/cold style attacks against the biometric algorithm. If the researchers care to clarify -- please mail me, or respond!
--Dan
Basically, everyone's holding up their games for Christmas, because why release in August if you can sell three times as much in November?
This has really wiped out the PSP as a platform for the time being, though. Lumines is great but it's not $300 great, and there's nothing else I want, even a little.
They really should have done the mass-portage, best of PS1/PS2, and dribbled the stuff out until Christmas.
For tech subjects, there's nothing like Google.
For tech subjects.
Get into the real world, of detailed data though -- suddenly, all the detailed data is in the literature. We must find a way to expose that data to the new mechanisms of search -- searching indices of books in the Dewey Decimal System is over, and it's now a matter of factual extinction vs. getting the data out there.
Synli--
Ahem.
The original question was, why is Whirlpool an AES *variant* (and thus, not hardware accelerable using the same equipment) and not AES itself?
The answer, which I've found while talking with you, is that AES was only deeply audited at that 128 bit level, and 128 bits is an insufficient cipher strength. This leaves two options for remediation:
1) Alter the cipher, such that instead of 128 bits of output, it emits 512, or
2) Alter the mode, so that the 128 bit cipher emits a 512 bit authentication block.
The advantage of the latter is you get to use existing hardware, and the strength of your system should theoretically equal the strength of your block cipher (given an appropriate mode). I do not see an advantage to the former, except that it's arguably more elegant to have all your security in the cipher, rather than partially in the cipher and partially in the mode. But since ultimately you always have a split between cipher and mode, that doesn't seem great either.
--Dan
http://csrc.nist.gov/CryptoToolkit/modes/proposedm odes/ProposedModesPage.html
Most of those MAC's can be used with an arbitrary block cipher (like, for example, genuine AES). A MAC with a known, fixed key degrades to a cryptographic hash, and doesn't require anything but genuine AES.
Thank XP SP2.
I'm serious, look at it for a sec:
"There should be a firewall on every desktop" done
"Patches should just show up one day, stupid users shouldn't have to think to install them" done
"Damn compiler shouldn't allow buffer overflows" done (to the degree to which it's possible)
All these exploits are against a five year old OS. XP's moved on.
I personally submitted the error report.
I've personally mailed Hemos about things like this.
Hate to say it, but nobody's wearing the Daddypants around here...
--Dan
Synli--
a bles/decision-final.pdf
"However, Whirlpool, SHA-256, SHA-384, and SHA-512 are newly designed primitives which have undergone only limited evaluation by the crytpographic community so far."
https://www.cosic.esat.kuleuven.be/nessie/deliver
--Dan
You know, if I listen closely I can hear the laughter of thousands upon thousands of Korean engineers, and I'm in Seattle.
Cryptosystems are fragile things. Whereas I can construct a hash out of Rijndael proper, what is my justification for instead using this variant -- one that did not pass the brutal AES audit?
--Dan
What != Why. "We needed a larger block size" isn't enough of an answer.
That's what's funny about it...only six bits different between the files, but that's all it takes.
AC--
Moving target. Yes, second preimage resistance (given md5(x), make y such that md5(y) = md5(x)) is important, but right now we have "given x and y, alter both such that md5(x) = md5(y)" and that flat out violates "computationally infeasible to find two files with the same hash".
--Dan
Synli--
:) I don't think it specifically will be selected as the next hash mechanism though, because though it's *similar* to AES, it's *not*, and that means the AES hardware accelerators probably can't be made to execute it.
Dude, I was making an oblique reference to Whirlpool
I've not seen a good public explanation for the differences between its design and that of Rijndael. Any light you can shed?
--Dan
It's broken, because it doesn't meet its design constraint ("computationally infeasible to find two files with the same hash"). We can fix the problem by moving to a non-broken hash. Unfortunately all the popular hashing algorithms are based on a similar mechanism, and they're all falling to Wang's modular differential attack. Best I can tell, we'll have some AES-as-hash variant get named as the next big hash mechanism.
You could easily use HTML to display different images, but a basic forensic analysis would show that. The only situation we were able to find where an MD5 collision would be undetectable (until it was too late) involved using the colliding files directly as primes seeding a cryptographic function. Supposing two matched files, X and Y, with X being integer-parseable as a prime and Y not, you could show X in a Diffie-Helman system as the prime you claimed to use, but Y as the one you actually did -- and there'd be no way, after the fact, to detect that you actually used the non-prime (and thus crackable) output. There'd also likely be no way to see, just having X, that a Y existed elsewhere.
fo0--
:(
The irony is, if you're sitting there with a botnet of 100,000 hosts, you don't care about blocking -- you're big enough to disperse your traffic across too many hosts.
Networks are alot better at defending against Protoss than Zerg, it seems
I'll know how many zones allow full crawling sometime this month or next. Did you know any DNSSEC zone can be crawled? Huge bug. Oops.
--Dan
OK, I'm partially responsible for people seeing applied attack against MD5, so I'll comment for a second.
.md5 file as well. (Files on multiple servers are a little different, because you can go elsewhere to see the deviating MD5 hash.)
Basically, in 2004 Xiaoyun Wang released two different files with the same MD5 hash. This has been predicted since around 1996, when Hans Dobbertin showed the hash was broken -- but it took a while for the actual attack to show up.
Alot of people said there were _no_ applied uses. Not true. For instance, the following two pages have the same hash:
Lockheed Martin
Boeing
What's important to realize about the above content is that both web pages are included in both links; the difference between the source files (which MD5 is blind to) is just used to determine which page is displayed. What that means is that, for forensic purposes, it's trivial to rule out the best known attack against MD5 -- just look at the content being hashed.
Thats not to say we should keep using MD5. It's broken, we need to move on. But attempts to claim that MD5 is broken, so we have no idea of any link between hashed content and real material -- that's just ridiculous. We have plenty of idea, especially with human-guided forensic operations.
That being said -- if you can doctor a photo, you can doctor a hash. This is one of the things that makes files hosted on a single server w/ MD5 hashes "verifying" them a little silly...if you can alter the file, you can alter the
For the most part, credible security researchers follow some variant of this document. Given that:
"1. You should be able to fix this in two days"
No, the document says you need to communicate with the researcher within five days. Microsoft has managed to get responses back to people within twenty four hours -- you can at least talk to people within five times that.
"2. The more notorious I am, the more business I will get"
Frankly, there are absolutely awful security advisories. (That "Monad can be used to write worms" garbage is probably the single most embarassing announcement in the history of our industry, though Secunia's DHS advisory that somehow implied a vuln in LibTiff was remote-critical was pretty bad too). If it's this bad when people talk, imagine how bad it can be from people who don't even try to have a public presence.
That being said -- burning vendors is good for nobody, and I have no particular sympathy for those who ignore the rules and just try to embarass people. But lets be honest -- both parties in the equation can embarass themselves, and the system that's evolved has managed to create the otherwise non-existent cost pressure to solve the problem.
How much money did Oracle make from calling themselves "Unbreakable"? Implies there was a rather significant market desire for what security researchers independently establish.
"3. I should always get credit for vulnerabilities I find"
If you release something you know is bad, and do it anyway because you figure the cost of releasing the product is less than the cost of fixing it -- well, the auto industry has a long and colorful history of doing that, and look at the legislative recall framework that evolved out of that.
Why hasn't similar legislation hit the tech world? Because the community of experts who would normally be calling for it has been otherwise co-opted. Good job, keep it up.
At some point, credit can be for forcing a fault to get fixed, not just for finding the fault. I've been in the large corporate environment -- hell, I've found remote roots in deployed products directly because of Oracle 8's broken TNS listener -- that *someone* in your organization found something is never, ever as compelling a reason to address the fault as someone *outside* the company finding something. Credit is more than just finding the flaw, it's finding it without sufficient internal documentation to know where to look. And the threat -- to be very explicit -- is if someone outside your organization, with no source code, can find the problem, so can a malicious attacker.
Security researchers represent hackers who behave as the malicious might but instead work with a vendor. There are inevitably tweaks necessary to the process -- but the process itself is critical, lest we experience its legislative opposite.
--Dan Kaminsky
Yeah, great paper Luis. Check out my slides from this year to see how I used similar methods to divine interrelationships. Hell, you're directly named in last year's slides. Really good work.
--Dan
Yeah. And I went to the TCP/IP drinking game _after_ that.
The 1999-2000 era of DNS poisoning focused on exploits. Then we had Kashpureff force the hand of BIND to implement all that complex bailiwick verification stuff, so a query for foo.com couldn't return glue for google.com (though the protocol really wants you to be able to do that). The recent stuff focuses on a situation where bailiwicks are ignored, i.e. forwarders. It was considered to be an obscure situation...I had NO IDEA there was so much forwarding going on.
--Dan
73,000 of the 230,000 are hosts I'm specifically worried about.
230,000 IP addresses forward to BIND8. They may BE that same host, though, with an alternate address. Or they may be other BIND8 systems.
60,000 hosts forward to BIND8, but are not themselves running BIND8. I don't know about every single other host.
13,000 are Windows systems forwarding to BIND8. This is verboten explicitly.
Things are made much harder by the fact that I'm reticent to actually exploit this many hosts.