<b orn1986> why the fuck isn't my disc drive working <born1986> i fucking worked on that essay for three friggin' hours in school <born1986> i now i cant finish it 'cos my fuckin drive ain't working <Z00ass> you got the right drivers? <born1986> hell yes <born1986> it was working fine yesterday <born1986> why does this shit always happen to me? <Z00ass> maybe that little clip on the side is i nthe wrong position <born1986> i havent touched it since school <born1986> i'm growing impatient <born1986> ANGRY even <Z00ass> throw that shit out tha window
. ..
<born1986> OMG i fuckin did it!!! <born1986> FUCK!!!!! <Z00ass> it works? <born1986> no, i threw it out the window <Z00ass> the disk? <born1986> NO the whole drive <born1986> i live on the 6th floor, made a nice *smash* <Z00ass>:D <born1986> FUCK SHIT FUCK <born1986> THE DISK WAS STILL INSIDE <born1986> brb
. ..
<born1986> shit <Z00ass> what? did ya break it? <born1986> well i couldn't open the drive <born1986> so i had to pound it against a rock <Z00ass>:o <born1986> quite HARD <born1986> and you know what? <born1986> that fucking disk wasnt even there <Z00ass> ??? <born1986> i got so mad i threw the remaiders of the drive on to the freeway <born1986> and when i got back upstairs i foud the disk inside my bag <Z00ass> lol <born1986> I NEVER EVEN PUT IT IN THE DRIVE <born1986> i'm actually cryin right now
. ..
<born1986> wonder if i could make that drive work again <born1986> brb
SHA-1 also uses a Merkle-Damgard construction, so yes, if we find a SHA-1 collision, it'll be appendable.
SHA-1 has a much stronger design. It's starting to show cracks, though, so I don't recommend anything. Something based on AES will come, though -- maybe AES-OMAC, maybe Whirlpool. At the core of almost every hashing algorithm is just a block cipher anyway...
I've been doing some analysis on MD5 collision announced by Wang et al. Short version: Yes, Virginia, there is no such thing as a safe hash collision -- at least in a function that's specified to be cryptographically secure. The full details may be acquired at the following link:
http://www.doxpara.com/md5_someday.pdf
A tool, Stripwire, has been assembled to demonstrate some of the attacks described in the paper. It may be acquired at the following address:
http://www.doxpara.com/stripwire-1.1.tar.gz
Incidentally, the expectations management is by no means accidental -- the paper's titled "MD5 To Be Considered Harmful Someday" for a reason. Some people have said there's no applied implications to Joux and Wang's research. They're wrong; arbitrary payloads can be successfully integrated into a hash collision. But the attacks are not wildly practical, and in most cases exposure remains thankfully limited, for now. But the risks are real enough that responsible engineers should take note: This is not merely an academic threat, systems designed with MD5 now need to take far more care than they would if they were employing an unbroken hashing algorithm, and the problems are only going to get worse.
Some highlights from the paper:
* The attack itself is pretty limited -- essentially, we can create "doppelganger" blocks (my term) anywhere inside a file that may be swapped out, one for another, without altering the final MD5 hash. This lets us create any number of binary-inequal files with the same md5sum.
* MD5 uses an appendable cascade construction -- in other words, if you happen to find yourself with two files that MD5 to the same hash, an arbitrary payload can be applied to both files and they'll still have the same hash. This leads to...
* Attacks are possible using only the proof of concept test vectors released by Wang -- the actual attack is not necessary.
* Stripwire emits two binary packages. They both contain an arbitrary payload, but the payload is encrypted with AES. Only one of the packages ("Fire") is decryptable and thus dangerous; the other ("Ice") shields its data behind AES. Both files share the same MD5 hash.
* Digital Signature systems are vulnerable, as they almost always sign a hashed representation of data rather than the data itself.
* This is an excellent vector for malicious developers to get unsafe code past a group of auditors, perhaps to acquire a required third party signature. Alternatively, build tools themselves could be compromised to embed safe versions of dangerous payloads in each build. At some later point, the embedded payload could be safely "activated", without the MD5 changing. This has implications for Tripwire, DRM, and several package management architectures.
* HMAC's invulnerability has been slightly overstated. It's definitely possible, given the key, to create two datasets with the same HMAC. Attacker possession of the key violates MAC presumptions, so the impact of this is particularly questionable.
* Very interesting possibilities open up once the full attack is made available -- among other things, we can create self-decrypting executables (fire.exe and ice.exe) that exhibit differential behavior based on their internal colliding payloads. They'll still have the same MD5 hash.
* Several doppelgangers may (relatively quickly, as per Joux) be computed within a single multicollision-friendly block. As such, the particular selection of doppelganger sets within a file can itself be made to represent data. It's relatively straightforward to embed a 128 bit signature inside an arbitrary file, in such a way that no matter the value of the signature, a constant MD5 hash is maintained. This is curiously steganographic.
* Many popular P2P networks (and innumerable distributed content databases) use MD5 hashes as both a reliable search handle and a mechanism to ensure file integrity. This makes them blind to any sign
So, I was in college. Santa Clara University, freshman year, to be precise. I was living in the dorms, had two PC's (a gaming system and a file server), and a 27" TV I had won for possessing some ungodly obscure knowledge about a Pontiac Grand Prix.
The PC's had been in non-stop use through the entire month of February. The TV hadn't been turned on, even once.
A 20 year old college male with zero hours of TV watching in an entire month has been a non-existent demographic for almost forty years. That's when I realized that perhaps things were a little different today.
I personally saw the 3D TV, it used 16 cameras. It was...OK. Really only impressive because it was semi-realtime (5 second lag). The lenticular approach is nice because we really, really want autostereoscopy, but that's about it. None of the displays impute more than a couple inches of depth, and it hurts your eyes when you move your head.
The polarized light projectors work really well. It'd be very cool if polarized contacts could work. Past that, though, it's all very very overrated.
Even holograms, in the interference-pattern-on-metal-film sense, are wuldly overrated. They're not Princess Leia out of R2-D2, they're not even close.
Yeah, gaim-e uses gpg, which is not exactly the cleanest piece of code to API through (as in, there is no API, everything passes through the command line, and the interface dies if you look at it funny). Plus, there's a whole "no software to install" model David's working towards right now -- gaim-e requires not only software, but not using the genuine AOL/Yahoo/MSN client.
Well, first of all there's only about 1.3 bits per byte of english text. So that 150TB/yr figure goes down to about 25TB.
Second of all, my friend used to *run* the AOL datacenter. What was that he said? "We just passed a petabyte." That was in around '98 or '99. I don't think you understand how big AOL is...his exact words to me were, "We cache the web every two hours."
Third, AOL ain't the only big fish in Virginia. That's all I'm going to say about that, except maybe that it's relatively common knowledge that IRC's been logged for at least the last decade and probably longer.
There's this great quote: "If you think it, don't say it. If you say it, don't write it. If you write it, don't be surprised." Expressing yourself means that others will register your expression -- some for good, others not. The goal is that the positive aspects of being social will exceed the negatives aspects of it. You ask, why trust IMSmarter? I change that to -- why trust the dozen or so routers between you and AOL? Why trust AOL itself? Why communicate with anyone?
Because there's value in human communication. IMSmarter is being built by a very smart friend of mine who's working to increase that value. It's neat:)
Bug AOL, Yahoo, and MSN about encrypted sessions... if any of their clients supported SOCKS over SSL, IMSmarter would have been happy to have worked with it. David and I have actually discussed adding crypto to the mix; lack of client support and necessary CPU resources (SSL negotiation is very expensive) is hampering that effort.
So this is what's really evil about Gator et al -- they make *actual* innovators look bad. David's a geek, a damn cool one, and he's genuinely trying to make a really useful service even better, through liberal application of mind-bogglingly cool hackery.
This should be cool, right?
So I used to live with David. I'm a moderately well known packet hacker type, and around the time I was living with him, I put together this hack for SSH called Dynamic Forwarding. SSH has the ability to forward TCP-based services, like email and such. But you used to need to pre-specify all your forwards before connecting. Dynamic Forwarding put a SOCKS server in the SSH client, so any application that could speak SOCKS could gain access to the cryptographically encrypted channel.
David had a much more expansive vision -- rather than just encrypt the chat session, why not add new features to it? IM is this brutally efficient communications medium where all sorts of otherwise superfluous communication artifacts are dispensed with; perhaps this efficiency could be used as an appropriate channel to organize one's life?
So -- no joke, he marshalled his savings, quit his job, and became this total guru of instant messaging protocols so he could explore the potential of this (very good) idea. No VC's, no ulterior motives, and when he's talking about security engineers who some day might need to examine the system to validate his architecture -- well, that'd probably include me, and seriously, I don't want to know anything about your life thank you very much:)
Honestly, it's a bit ridiculous to talk about IMSmarter as creating any serious alteration to IM privacy. You're using an unencrypted channel to a centralized messaging clearing house that, in AOL's case, is located in Virginia. Ahem. I'm not saying privacy isn't important -- just that David's got way more interesting things to worry about than who you've got a crush on. Ultimately, his service isn't a very good place to spy from anyway, because he doesn't get all messages from all people, just those that are intentionally routed through him. And as anyone will tell you, global views trump self-selection any day of the week.
Honestly -- he's pulling some really cool protocol tricks, and I'm happy to see his wonky-as-hell hack actually become something my mom could use. I know there's alot of creepy corporate virus vendors who are doing some truly nasty things -- someday I want to find the guy who replaces people's TCP/IP stacks and replace a few of his vertebrae -- but David's not one of 'em. Good guy with cool code -- he deserves to be encouraged.
Well, the 96 bit ID sort of rules out RF Smart Cards, in the sense that a fixed ID transmission tends to rule out digital signatures on a random nonce or even challenge/response. And fundamentally there are real issues that aren't going away with surreptitious reading of the RFID device.
Cloth does not block RFID. There are contexts in which we'd expect it to.
Yes, because only the tag sold by the original manufacturer can emit AM radio at 13.57mhz.
Don't believe the hype.
Incidentally, there happen to be difficult to clone designs for RFID's, but none of them are getting funding, because you'll deploy crap anyway and think it works. It's a little analogous to the whole voting machine problem... I mean, everyone in computer security knows its a mess, but the stuff still gets certified.
Look. In a few years, everyone's going to be shocked -- SHOCKED -- that someone could possibly walk by the executive on the New York subway and acquire his ten digit HID code, granting them full access to the building. And then all the gear gets ripped out. Like I said, Deadpool.
They're a 10 digit number emitted over RF at 13.57mhz. RFID ain't magic, it's just barcode over AM radio.
Even the physical security guys are starting to realize that perhaps moving all access control to this tech was a profoundly questionable move. Something like a deadpool is forming for the first time someone walks by a TSA agent and electronically pickpockets access to the entire airport. Convenience, eh?
Jittered cameras basically have affine transformations (the camera angle shifting), parallax (objects farther away shifting nonlinear amounts), and of course, the subject moving around over time. Still, there's alot that stays the same from frame to frame. I'd like to see this paper -- please post the link.
With regards to your first description, you are describing a temporal mechanism informally referred to as "drizzling". This method was pioneered by NASA for astronomical imagery. While this is one way to merge several images, it's by no means the only way. Among other things, it does require a rather cooperative camera operator -- not TV. Many webcams will stack photos and average them in an attempt to eliminate high frequency noise, which quite arguably reduces true resolution below the simple bounding box. Then there are the algorithms that do stacking with warping, i.e. they attempt to allow stacking despite areas of the images changing or the camera moving. Long story short -- more than one way to integrate lots of images, and ALE supports more than a few of them.
I hadn't considered the forensic implications of example-based superresolution. One could argue that as long as the network hadn't been trained with any particular bias (say, a large number of face components for a hazy blob off a bank camera) if the objective reassembly looked like the defendent, that should be taken into account. Interesting thinking.
There's actually a whole host of algorithms that go well beyond the junk they throw at us for "digital zoom". The two most applicable algorithms for this particular problem -- increasing the resolution of video above and beyond the source data available in a particular frame -- are temporal integration (collecting data across multiple frames) and superresolution by example (automatically associating and recalling high resolution imagery when a low resolution equivalent is shown). Some example code:
Temporal Integration: ALE Superresolution by Example: Image Analogies -- not automated, but remains one of the cooler pieces of code ever shown at SIGGRAPH.
From the article, I'm guessing it's another ALE style stacker. They probably needed to write one for their cameras anyway.
Alot of MS mail environments don't send mail like SPF envisions. Sender-ID basically makes life easier for MS customers. MS is coming to SPF people, saying, heh, can you modify your protocol to be a bit more friendly to our implementations?
And, since there are actually users behind those mail servers, SPF folks say, sure. Lets talk. Lets see how we can better adapt to your architecture.
Then MS turns around and says, oh, you want to adapt to us? You'll have to sign these forms.
At which point, SPF people walk away. They've already got a great way to tell eachother what they need to say, and while they're willing to work with MS, really, Sender-ID really helps MS more than it helps anyone else. A fate where exchange deployments need to either alter their topology or risk getting their mail dropped isn't one that's beneficial to the company.
Indeed, there are these people called customers that'll handle any intransigence on the part of their vendor. Which, uh, is about what's happening right now.
I'm not saying this is exactly what's going on. Neither side is monolithic. But this is, at least from the outside, what appears to be happening. Someone on the inside should feel free to correct me.
Slashdot Mirror
The definite story:
.
:D
.
:o
.
http://www.bash.org/?416857
===
<b orn1986> why the fuck isn't my disc drive working
<born1986> i fucking worked on that essay for three friggin' hours in school
<born1986> i now i cant finish it 'cos my fuckin drive ain't working
<Z00ass> you got the right drivers?
<born1986> hell yes
<born1986> it was working fine yesterday
<born1986> why does this shit always happen to me?
<Z00ass> maybe that little clip on the side is i nthe wrong position
<born1986> i havent touched it since school
<born1986> i'm growing impatient
<born1986> ANGRY even
<Z00ass> throw that shit out tha window
. .
<born1986> OMG i fuckin did it!!!
<born1986> FUCK!!!!!
<Z00ass> it works?
<born1986> no, i threw it out the window
<Z00ass> the disk?
<born1986> NO the whole drive
<born1986> i live on the 6th floor, made a nice *smash*
<Z00ass>
<born1986> FUCK SHIT FUCK
<born1986> THE DISK WAS STILL INSIDE
<born1986> brb
. .
<born1986> shit
<Z00ass> what? did ya break it?
<born1986> well i couldn't open the drive
<born1986> so i had to pound it against a rock
<Z00ass>
<born1986> quite HARD
<born1986> and you know what?
<born1986> that fucking disk wasnt even there
<Z00ass> ???
<born1986> i got so mad i threw the remaiders of the drive on to the freeway
<born1986> and when i got back upstairs i foud the disk inside my bag
<Z00ass> lol
<born1986> I NEVER EVEN PUT IT IN THE DRIVE
<born1986> i'm actually cryin right now
. .
<born1986> wonder if i could make that drive work again
<born1986> brb
Pretty amazing seeing what happens to those in politics who cross Diebold.
Apparently our Governator has taken sides. Pity.
Kazaa uses MD5, in a moderately broken mode no less. See:
c k- devel/2004-February/000023.html
https://lists.berlios.de/pipermail/gift-fasttra
--Dan
SHA-1 also uses a Merkle-Damgard construction, so yes, if we find a SHA-1 collision, it'll be appendable.
SHA-1 has a much stronger design. It's starting to show cracks, though, so I don't recommend anything. Something based on AES will come, though -- maybe AES-OMAC, maybe Whirlpool. At the core of almost every hashing algorithm is just a block cipher anyway...
--Dan
File size remains constant between Fire and Ice. Good thinking, though.
The solution is to not use MD5.
It's also safe to truncate 40 byte SHA-1 down to 32 byte if need be.
[This is the author]
I've been doing some analysis on MD5 collision announced by Wang et al. Short version: Yes, Virginia, there is no such thing as a safe hash collision -- at least in a function that's specified to be cryptographically secure. The full details may be acquired at the following link:
http://www.doxpara.com/md5_someday.pdf
A tool, Stripwire, has been assembled to demonstrate some of the attacks described in the paper. It may be acquired at the following address:
http://www.doxpara.com/stripwire-1.1.tar.gz
Incidentally, the expectations management is by no means accidental -- the paper's titled "MD5 To Be Considered Harmful Someday" for a reason. Some people have said there's no applied implications to Joux and Wang's research. They're wrong; arbitrary payloads can be successfully integrated into a hash collision. But the attacks are not wildly practical, and in most cases exposure remains thankfully limited, for now. But the risks are real enough that responsible engineers should take note: This is not merely an academic threat, systems designed with MD5 now need to take far more care than they would if they were employing an unbroken hashing algorithm, and the problems are only going to get worse.
Some highlights from the paper:
* The attack itself is pretty limited -- essentially, we can create "doppelganger" blocks (my term) anywhere inside a file that may be swapped out, one for another, without altering the final MD5 hash. This lets us create any number of binary-inequal files with the same md5sum.
* MD5 uses an appendable cascade construction -- in other words, if you happen to find yourself with two files that MD5 to the same hash, an arbitrary payload can be applied to both files and they'll still have the same hash. This leads to...
* Attacks are possible using only the proof of concept test vectors released by Wang -- the actual attack is not necessary.
* Stripwire emits two binary packages. They both contain an arbitrary payload, but the payload is encrypted with AES. Only one of the packages ("Fire") is decryptable and thus dangerous; the other ("Ice") shields its data behind AES. Both files share the same MD5 hash.
* Digital Signature systems are vulnerable, as they almost always sign a hashed representation of data rather than the data itself.
* This is an excellent vector for malicious developers to get unsafe code past a group of auditors, perhaps to acquire a required third party signature. Alternatively, build tools themselves could be compromised to embed safe versions of dangerous payloads in each build. At some later point, the embedded payload could be safely "activated", without the MD5 changing. This has implications for Tripwire, DRM, and several package management architectures.
* HMAC's invulnerability has been slightly overstated. It's definitely possible, given the key, to create two datasets with the same HMAC. Attacker possession of the key violates MAC presumptions, so the impact of this is particularly questionable.
* Very interesting possibilities open up once the full attack is made available -- among other things, we can create self-decrypting executables (fire.exe and ice.exe) that exhibit differential behavior based on their internal colliding payloads. They'll still have the same MD5 hash.
* Several doppelgangers may (relatively quickly, as per Joux) be computed within a single multicollision-friendly block. As such, the particular selection of doppelganger sets within a file can itself be made to represent data. It's relatively straightforward to embed a 128 bit signature inside an arbitrary file, in such a way that no matter the value of the signature, a constant MD5 hash is maintained. This is curiously steganographic.
* Many popular P2P networks (and innumerable distributed content databases) use MD5 hashes as both a reliable search handle and a mechanism to ensure file integrity. This makes them blind to any sign
So, I was in college. Santa Clara University, freshman year, to be precise. I was living in the dorms, had two PC's (a gaming system and a file server), and a 27" TV I had won for possessing some ungodly obscure knowledge about a Pontiac Grand Prix.
The PC's had been in non-stop use through the entire month of February. The TV hadn't been turned on, even once.
A 20 year old college male with zero hours of TV watching in an entire month has been a non-existent demographic for almost forty years. That's when I realized that perhaps things were a little different today.
I personally saw the 3D TV, it used 16 cameras. It was...OK. Really only impressive because it was semi-realtime (5 second lag). The lenticular approach is nice because we really, really want autostereoscopy, but that's about it. None of the displays impute more than a couple inches of depth, and it hurts your eyes when you move your head.
The polarized light projectors work really well. It'd be very cool if polarized contacts could work. Past that, though, it's all very very overrated.
Even holograms, in the interference-pattern-on-metal-film sense, are wuldly overrated. They're not Princess Leia out of R2-D2, they're not even close.
Yeah, gaim-e uses gpg, which is not exactly the cleanest piece of code to API through (as in, there is no API, everything passes through the command line, and the interface dies if you look at it funny). Plus, there's a whole "no software to install" model David's working towards right now -- gaim-e requires not only software, but not using the genuine AOL/Yahoo/MSN client.
Well, first of all there's only about 1.3 bits per byte of english text. So that 150TB/yr figure goes down to about 25TB.
:)
Second of all, my friend used to *run* the AOL datacenter. What was that he said? "We just passed a petabyte." That was in around '98 or '99. I don't think you understand how big AOL is...his exact words to me were, "We cache the web every two hours."
Third, AOL ain't the only big fish in Virginia. That's all I'm going to say about that, except maybe that it's relatively common knowledge that IRC's been logged for at least the last decade and probably longer.
There's this great quote: "If you think it, don't say it. If you say it, don't write it. If you write it, don't be surprised." Expressing yourself means that others will register your expression -- some for good, others not. The goal is that the positive aspects of being social will exceed the negatives aspects of it. You ask, why trust IMSmarter? I change that to -- why trust the dozen or so routers between you and AOL? Why trust AOL itself? Why communicate with anyone?
Because there's value in human communication. IMSmarter is being built by a very smart friend of mine who's working to increase that value. It's neat
--Dan
Bug AOL, Yahoo, and MSN about encrypted sessions ... if any of their clients supported SOCKS over SSL, IMSmarter would have been happy to have worked with it. David and I have actually discussed adding crypto to the mix; lack of client support and necessary CPU resources (SSL negotiation is very expensive) is hampering that effort.
--Dan
So this is what's really evil about Gator et al -- they make *actual* innovators look bad. David's a geek, a damn cool one, and he's genuinely trying to make a really useful service even better, through liberal application of mind-bogglingly cool hackery.
:)
This should be cool, right?
So I used to live with David. I'm a moderately well known packet hacker type, and around the time I was living with him, I put together this hack for SSH called Dynamic Forwarding. SSH has the ability to forward TCP-based services, like email and such. But you used to need to pre-specify all your forwards before connecting. Dynamic Forwarding put a SOCKS server in the SSH client, so any application that could speak SOCKS could gain access to the cryptographically encrypted channel.
David had a much more expansive vision -- rather than just encrypt the chat session, why not add new features to it? IM is this brutally efficient communications medium where all sorts of otherwise superfluous communication artifacts are dispensed with; perhaps this efficiency could be used as an appropriate channel to organize one's life?
So -- no joke, he marshalled his savings, quit his job, and became this total guru of instant messaging protocols so he could explore the potential of this (very good) idea. No VC's, no ulterior motives, and when he's talking about security engineers who some day might need to examine the system to validate his architecture -- well, that'd probably include me, and seriously, I don't want to know anything about your life thank you very much
Honestly, it's a bit ridiculous to talk about IMSmarter as creating any serious alteration to IM privacy. You're using an unencrypted channel to a centralized messaging clearing house that, in AOL's case, is located in Virginia. Ahem. I'm not saying privacy isn't important -- just that David's got way more interesting things to worry about than who you've got a crush on. Ultimately, his service isn't a very good place to spy from anyway, because he doesn't get all messages from all people, just those that are intentionally routed through him. And as anyone will tell you, global views trump self-selection any day of the week.
Honestly -- he's pulling some really cool protocol tricks, and I'm happy to see his wonky-as-hell hack actually become something my mom could use. I know there's alot of creepy corporate virus vendors who are doing some truly nasty things -- someday I want to find the guy who replaces people's TCP/IP stacks and replace a few of his vertebrae -- but David's not one of 'em. Good guy with cool code -- he deserves to be encouraged.
Yours Truly,
Dan Kaminsky
Well, the 96 bit ID sort of rules out RF Smart Cards, in the sense that a fixed ID transmission tends to rule out digital signatures on a random nonce or even challenge/response. And fundamentally there are real issues that aren't going away with surreptitious reading of the RFID device.
Cloth does not block RFID. There are contexts in which we'd expect it to.
Yes, because only the tag sold by the original manufacturer can emit AM radio at 13.57mhz.
... I mean, everyone in computer security knows its a mess, but the stuff still gets certified.
Don't believe the hype.
Incidentally, there happen to be difficult to clone designs for RFID's, but none of them are getting funding, because you'll deploy crap anyway and think it works. It's a little analogous to the whole voting machine problem
Look. In a few years, everyone's going to be shocked -- SHOCKED -- that someone could possibly walk by the executive on the New York subway and acquire his ten digit HID code, granting them full access to the building. And then all the gear gets ripped out. Like I said, Deadpool.
What? You mean Armani suits don't block 13.57mhz?
Why would they be hard to copy?
They're a 10 digit number emitted over RF at 13.57mhz. RFID ain't magic, it's just barcode over AM radio.
Even the physical security guys are starting to realize that perhaps moving all access control to this tech was a profoundly questionable move. Something like a deadpool is forming for the first time someone walks by a TSA agent and electronically pickpockets access to the entire airport. Convenience, eh?
Unfortunately, nobody can be told what Halo is...you have to see it, for yourself.
And for what it's worth, vehicles were really quite awful pre-Halo. This is long before Battlefield, after all.
http://www.doxpara.com/apps/cdcygssh
(in ie, non sp2)
Ugh. Not the best written Slashdot entry.
:-)
Larry Osterman -- former Microsoft guy; someone forwarded him a post to Bugtraq.
Michael Zalewski -- absurdly brilliant security engineer out of Poland. Did the pioneering work on visualizing randomness of network stacks, passively identifying operating systems on networks, and way way more.
Nothing bad against Larry. But this is all Zalewski
--Dan
Uh, I'd prepay for a Sam 'n Max 2. Like, right now. And I'm not the only one.
--Dan
You do realize that the longer the half life, the slower it's breaking down, so the less radioactive the object is, right?
Right?
Ah.
--Dan
Jittered cameras basically have affine transformations (the camera angle shifting), parallax (objects farther away shifting nonlinear amounts), and of course, the subject moving around over time. Still, there's alot that stays the same from frame to frame. I'd like to see this paper -- please post the link.
AC--
With regards to your first description, you are describing a temporal mechanism informally referred to as "drizzling". This method was pioneered by NASA for astronomical imagery. While this is one way to merge several images, it's by no means the only way. Among other things, it does require a rather cooperative camera operator -- not TV. Many webcams will stack photos and average them in an attempt to eliminate high frequency noise, which quite arguably reduces true resolution below the simple bounding box. Then there are the algorithms that do stacking with warping, i.e. they attempt to allow stacking despite areas of the images changing or the camera moving. Long story short -- more than one way to integrate lots of images, and ALE supports more than a few of them.
I hadn't considered the forensic implications of example-based superresolution. One could argue that as long as the network hadn't been trained with any particular bias (say, a large number of face components for a hazy blob off a bank camera) if the objective reassembly looked like the defendent, that should be taken into account. Interesting thinking.
--Dan
It's superresolution!
There's actually a whole host of algorithms that go well beyond the junk they throw at us for "digital zoom". The two most applicable algorithms for this particular problem -- increasing the resolution of video above and beyond the source data available in a particular frame -- are temporal integration (collecting data across multiple frames) and superresolution by example (automatically associating and recalling high resolution imagery when a low resolution equivalent is shown). Some example code:
Temporal Integration: ALE
Superresolution by Example: Image Analogies -- not automated, but remains one of the cooler pieces of code ever shown at SIGGRAPH.
From the article, I'm guessing it's another ALE style stacker. They probably needed to write one for their cameras anyway.
--Dan
It's basically like this:
Alot of MS mail environments don't send mail like SPF envisions. Sender-ID basically makes life easier for MS customers. MS is coming to SPF people, saying, heh, can you modify your protocol to be a bit more friendly to our implementations?
And, since there are actually users behind those mail servers, SPF folks say, sure. Lets talk. Lets see how we can better adapt to your architecture.
Then MS turns around and says, oh, you want to adapt to us? You'll have to sign these forms.
At which point, SPF people walk away. They've already got a great way to tell eachother what they need to say, and while they're willing to work with MS, really, Sender-ID really helps MS more than it helps anyone else. A fate where exchange deployments need to either alter their topology or risk getting their mail dropped isn't one that's beneficial to the company.
Indeed, there are these people called customers that'll handle any intransigence on the part of their vendor. Which, uh, is about what's happening right now.
I'm not saying this is exactly what's going on. Neither side is monolithic. But this is, at least from the outside, what appears to be happening. Someone on the inside should feel free to correct me.
--Dan