There's definitely been work on this. There's alot of financial incentive to get this to happen, since cell phones not working indoors is a massive problem, and except for Nextel, no carrier will let you throw up their base stations. They're happy to let you throw up 802.11 stations, though, and not use their radio frequency space to complete calls (as long as they're still making some cash on completing the call).
This isn't secret or anything -- it's just pretty damn cool:-)
First of all, full disclosure: I work at Avaya, for their security practice. What I'm about to say may seem pretty self-serving for the company, but I can only hope my posting history establishes me as some sort of credible source.
Second warning -- I'm actually raving about my own company's gear here. I'm way more likely to get in trouble over this, but heh -- can't let an entire nascent industry get tarred over a temporary generation of *ahem* lesser performing equipment.
So, warnings aside -- I was at Hivercon last year. Hivercon's a fun show, set in the middle of Dublin, Ireland (which, btw, is a fantastic city.) I'm sitting there, on:
1) My laptop 2) Wireless 2.1)HOTEL wireless 3) VPN (IPSec w/ 50% packet overhead!) 4) An international link 5) VoIP into a conference call
By all rights, the quality should have been awful. I mean, it had every right to be...
Now, we have VoIP at home too -- Vonage, to be specific. Our Vonage link runs over an 1.5mbit SDSL line provided by Speakeasy/COVAD, is QoS'd at our firewall, and connects directly to our home telephone wiring.
The quality on the international, wireless, IPSec'd, laptop'd conference call through my Avaya softphone exceeded what I was used to from our home VoIP provider. It was basically landline equivalent -- yes, it was even better than my cell phone.
I was _shocked_. I remember PowWow, FreeSpeak, and all those other systems that ran VoIP over Modem lines. In what alternate universe did VoIP become a quality leader under difficult network conditions?
Turns out that implementation matters. I went and harassed some of the people who worked on the phone equipment (heh Brian) and asked how this system could possibly be working at all. Apparently Avaya got a bunch of the people from Bell Labs (it came from Lucent, which came from AT&T, which itself came from Ma Bell), so there was all this knowledge lying around already in how to manage reliable communications like lives depended on it. The big things being used were:
1) Error Concealment 2) Dynamic Jitter Buffers
Error concealment is simple -- there's necessarily 50 packets per second on a 20ms-latency link (1000ms / 50 packets per second = 20ms of audio per packet), and speech is massively redundant. So rather than simply dropping out when packets were missing, the voice client was "filling in the gaps" with neighboring content. Since the overall frequency profile was kept relatively consistent, short term drops were kept outside the range of human perception. Neat -- obvious, and not entirely unique to this particularly implementation (there's direct support for concealment in some of the G.72x codecs), but neat.
The dynamic jitter buffers are cooler. The basic idea here is that some links are high quality and others are less so, and sometimes the quality of the link will change in the middle of a call. As a response, the Avaya architecture will negotiate a longer buffer for packets to be stored before they're output to the listener to be heard. This buffer starts at ~10ms and can scale up to ~300ms -- distracting, but users have been accustomed to higher latency through their love of cell phones (sad, but true). The key is that the human auditory system can't easily detect speed changes at subsecond resolutions, so you simply execute a non-pitch-shifting slowdown of output speech over a second or two and now you've got a jitter buffer far more tolerant of inclement network conditions. Mind you, this is an absolute nightmare for automated testing equipment, which expects time to be constant, but it's great for everything else -- even TTY's! You'd think a 150bps modem could travel over any link, but apparently not...
Anyway, we keep hearing about how Motorola and Avaya are putting out some kind of VoIP phone, so I'm actually pretty hopeful that we'll see a GOOD VoIP/WiFi solution sometime in my lifetime. I can say this much, though -- simply spurting ulaw on the wire and calling it VoIP ain't my idea of a good time.
Mike, please email me at dan@doxpara.com. I have a working, uber-efficient implementation (I write Internet-scale scanners) and you deserve as much credit for it as I do.
Really? I'd very much like to see you transfer cash anonymously to someone more than a couple hundred miles away. Flights are audited, roads are bottlenecked, trains require ID, there aren't walkways, etc.
Electronic cash transfers are massively monitored. (It's also rather expensive.)
Aha, but I outnitpick you! You see, I specifically wrote that it was easier to drop a letter on the floor, due to its mass -- not that it was impossible to drop a photon.
And objects have mass, not weight. Weight is an environmental factor, not an inherent one. Various environments will imbue a different weight upon an object, but its mass is an inherent part of its nature. It is this mass that is attracted to the prototypical floor with The Earth below it.
If every book at Barnes and Noble suddenly has sheets of paper advertising Borders thrown inside, I promise you that Borders would be investigated.
Spam is not prosecuted because there's alot of fear regarding regulating the Internet -- justified, perhaps, but problematic in this instance. We can't solve this problem no matter how we innovate, because we built a network where it's not solvable. But the financial and criminal investigatory systems can help.
I'm telling you, this isn't a technically solvable problem. Your approach -- open proxy scanning -- utterly fails against botnets, which (as the story describes) are becoming _the_ source of spam. But no matter what is tried, most spammers want money from 0.01% of customers (not the stock spammers, but they're in a different category). Follow the money and investigate the subject. A couple people will get framed, but a couple people are always framed. Prosecute the obviously guilty and help solve the problem.
Step Two: Follow the money. Step Three: Follow the money. Step Four: Take a wild guess.
I'm just going to keep on saying this, year after year, as it becomes more and more clear that those engaging in spam are operating outrageously criminal enterprises: If you want to stop spam, FOLLOW THE MONEY.
Find some Viagra spam. Buy some Viagra. Trace the shipment to you, trace the cash transfer from you, arrest. It's not that hard. It's just not very geeky. People, there's no magic technical solution to this -- there's increasingly illegal stunts being pulled, and the only people out there with the IP-layer mechanisms for tracing the attackers really can't afford to release that data as it would compromise rather more important investigations. But -- we've got a very mature infrastructure for tracing financial and mail fraud. We just need the political will to use it against Spam.
Well, with large chunks of printer control living in the driver, you can at least do everything from Photoshop and do it inside the printer driver. Of course, this makes it rather problematic to print from Linux or any other uncontrolled OS.
Now that you make me think about it, printers don't store a full image in RAM -- they stream their actions from the upstream driver. To be barriers to printing, they'd have to have _alot_ more memory, or receive their data in some semi-low resolution full page view...ack.
But smart cards aren't cash. Dude, credit and debit cards have won for retailer microtransactions. I have literally hundreds of $5 purchases with my credit card in the past year. Whatever the cost is, it's low enough now.
But I can't give five bucks to my roommate with a credit card, a smart card, or anything else -- except maybe a check. Cash is critical for large portions of society. Are you aware that there are large neighborhoods with no banks, just check cashing services?
In order to win your point, you'd have to successfully argue that the flexible nature of web programming has not directly enabled previously scarce or unknown forms or modalities of speech. Given the massive political will that discussion blogs are expressing at the present time -- from FreeRepublic to Daily Kos -- that argument is not likely to succeed.
You're right -- science still works via written journals. If I had to write to you via a journal, I would not write to you, and more importantly, literally could not write this specific message to you. Ergo, speech suppressed via infrastructure.
You realize the first amendment specifically protects assembly too, right? Banning the technological means of assembling for discussion would get laughed out of court.
The more we discuss, the weaker your case gets, as the more impossible this discussion becomes without dynamic code. It's that simple.
Sure, not by US Supreme Court, but certainly by US Federal Court:
http://laws.lp.findlaw.com/2nd/009185.html
=== Communication does not lose constitutional protection as "speech" simply because it is expressed in the language of computer code. Mathematical formulae and musical scores are written in "code," i.e., symbolic notations not comprehensible to the uninitiated, and yet both are covered by the First Amendment. If someone chose to write a novel entirely in computer object code by using strings of 1's and 0's for each letter of each word, the resulting work would be no different for constitutional purposes than if it had been written in English. The "object code" version would be incomprehensible to readers outside the programming community (and tedious to read even for most within the community), but it would be no more incomprehensible than a work written in Sanskrit for those unversed in that language. The undisputed evidence reveals that even pure object code can be, and often is, read and understood by experienced programmers. And source code (in any of its various levels of complexity) can be read by many more. See Universal I, 111 F. Supp. 2d at 326. Ultimately, however, the ease with which a work is comprehended is irrelevant to the constitutional inquiry. If computer code is distinguishable from conventional speech for First Amendment purposes, it is not because it is written in an obscure language. See Junger v. Daley, 209 F.3d 481, 484 (6th Cir. 2000). ===
And I do believe the Norwegian Supreme Court ruled similarly in favor of DVD-Jon.
While we're on the subject, it's supremely ironic that you're telling me that you don't need a programming language to publish ideas on the web, via a web form dependent upon Perl! Not to put too fine a point on it, but you required a dynamic web programming language to tell me that you didn't require a dynamic web programming language. I do believe the appropriate response is, "Oops."
You're right. Making a scanner is actually not atrociously difficult (photodiodes 'n light, basically), but making a printer of any quality is. Printers will always be the critical line of defense.
Ha. Right. PHP compiles, and can easily manipulate imagery as well (through GD, Imagemagick, etc.) Sure, go ahead and license web programming. Lets see that survive 1st amendment review:-)
Ewww. I failed to point out that I performed my tests on Euro notes, is what I meant to say. Anyway, I actually started on the Euro bills, then moved to greenbacks because I could get JPEGs of them easier.
My sincerest apologies. I failed to point out that my tests on a wide range of European banknotes as well. I'm not the only one doing this kind of work; see this presentation for details.
OK. The last time this came up, it consumed about twelve straight hours of hackery. You can go ahead and play with some of the black boxed code using the demo version of Paint Shop Pro (or the latest Photoshops). Let me tell you: This has nothing to do with the circles. I was actually quite saddened by this fact, as I was planning to print up a "secure t-shirt" that would be unphotographable and unprintable by modern image manipulators. (It'd be a great excuse to talk at Black Hat wearing a T-Shirt *laughs*).
Alas, such adventures were not to be had. Experimenting with copy/paste between an unprotected app and the demo PSP, it quickly became clear that while some old copiers might indeed trigger on the inter-circle distances, counterfeiters now had a vastly more difficult system to fight. What there seems to be is some sort of size and position invariant image fingerprint function, probably wavelet based, that receives the full image after every large scale image transform, executes a fingerprint matching vs. a confidence value, and returns true or false depending on what the confidence threshold is set to. It's not perfect -- Stirmark does seem to cause the algorithm to occasionally stumble, though not consistently (see this gallery for details) -- but it's very good work nonetheless.
Certainly, it does not appear possible to manipulate the watermarking system to create new and unique images that appear, computationally, to still be money. That's a very good thing. And while it's somewhat problematic to have code refusing to obey its controller, the integrity of the financial system really is an important thing. Remember the privacy case for cash -- if paper money becomes something we all distrust, what exactly are we left with? The fault with the RFID approach is that it forces us to carry a reader to validate funds. If we cannot self-validate, we cannot trust (notably, the biggest weakness with the metal strip approach is that we cannot quickly notice that the metal strip has been removed -- the wealth is actually thus represented not by the bill but by an invisible strip of iron and plastic!).
I do not think that image manipulation software is the right place to put this code, specifically because it's too easy to write an image editor from scratch (what are you going to do, ban compilers?). Scanners and printers are however sufficiently single sourced that they're far superior places to trust that anti-counterfeiting logic will be in place. But then, that's just IMHO.
So people keep things "just working". When this becomes a problem, we'll see things change. That's how it actually works in security -- be the problem dozens of open daemons on Unix hosts, canary-less stacks in executable code, or a lack of significant checking for airline contraband, the problem is not addressed until it's exploited. When people start getting hacked through their open wireless, we'll see open wireless shut down. For the moment, they'll worry about real problems, like worms and spyware (aka corporate virii).
Ironically enough, it was bluetooth's security model that made it such a nightmare to work with -- the whole pairing process increased the setup load by several orders of magnitude. They're finally going to fix this with Near Field, but it'll take a while for them to get it out (have they even admitted it's for secure key exchange yet?).
Note, I've never said this is how things should be. Ought is not is.
The farther you get from an endpoint, the harder it is to actually reassemble the stream. This is because packets can take multiple routes to their destination -- if not through load balancing, then through asymmetric routes (i.e. the packets from the client to the server are taking a wildly different network route from the path taken from server to client.)
Asymmetric routing always seems to confuse people. It shouldn't -- the traffic on the freeways isn't symmetrical in each direction, and sometimes it makes sense to take one highway to work and another back.
Upshot of all this is that, while all the long haul fiber lines actually are probably tapped by someone or other, it's an enormously tricky problem to integrate the data accurately, and you ultimately still don't get as good results as having a direct feed a hop or two up from the endpoint being monitored.
Now, there have been tools for quite some time to do realtime stream monitoring -- Driftnet is a cheap (and occasionally very scary) one, but there have been solutions floating around the corporate space that basically reassemble a browser screen in realtime. I imagine the gov space has even nicer stuff.
You know, "tcpbust" (a sniffer with integrated safe reassembly, third party cryptographically signed timestamps, and a pony) would probably be a really interesting thing to write...
Except that floppies can only store 1.4MB per disc, while there are cameras that will capture more than that per photo. Even if not more, people will down-res their photos so that they can fit more pics per floppy.
Unless you have family or you're an international-class executive, you have no idea as an American how to dial overseas, because you have almost no need to and it's horrifyingly expensive to do using stock long distance service.
I did a press junket around Europe last year... lets just say the hour-long planning sessions through MCI Neighborhood were a very painful lesson in the above. Unlimited long distance my ass...
Well, to use the scientific term, "it depends". I've been thinking about this (like about ten thousand other crypto people) throughout the day. Certainly, Brumley and Boneh's attack will work (and probably better, because 1/44,100 is microsecond resolution): http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
We do have more data than just time, too -- we have instruction profiles. If it's possible to absolutely know the input to the RSA signing function, and it's possible to alter that input while still knowing the (probably hashed) result, then you can get a set that looks like:
Shamir, once again pointing out something absolutely brilliant and (in retrospect) totally obvious, did forget to include something rather important in his announcement:
The particular pattern of CPU operations executed while an RSA private key is executed varies depending on that RSA private key. Given a rough estimate of the pattern of CPU operations executed, the set of possible RSA private keys is greatly reduced. So it becomes much, much easier -- possibly trivial, particularly if you have a chosen plaintext scenario -- to extract a private key from an otherwise secure system. Consider an e-voting machine with an audio system for handicapped access -- with nothing but a very sensitive microphone in the booth, you might be able to determine the private key used to sign votes (and thus gain the capability to spoof votes elsewhere).
And of course, this would be a very, very successful attack against an RSA private key embedded within a trusted computing environment. Processors -- even those encased in epoxy -- still need power, and variable amounts depending on what they're doing. The brilliance here is that rather than needing some very expensive analog energy drain measurement equipment, you just need a sound card. It's a side channel attack for the masses.
Slashdot Mirror
http://www.networkitweek.co.uk/Analysis/1138234
:-)
There's definitely been work on this. There's alot of financial incentive to get this to happen, since cell phones not working indoors is a massive problem, and except for Nextel, no carrier will let you throw up their base stations. They're happy to let you throw up 802.11 stations, though, and not use their radio frequency space to complete calls (as long as they're still making some cash on completing the call).
This isn't secret or anything -- it's just pretty damn cool
--Dan
First of all, full disclosure: I work at Avaya, for their security practice. What I'm about to say may seem pretty self-serving for the company, but I can only hope my posting history establishes me as some sort of credible source.
Second warning -- I'm actually raving about my own company's gear here. I'm way more likely to get in trouble over this, but heh -- can't let an entire nascent industry get tarred over a temporary generation of *ahem* lesser performing equipment.
So, warnings aside -- I was at Hivercon last year. Hivercon's a fun show, set in the middle of Dublin, Ireland (which, btw, is a fantastic city.) I'm sitting there, on:
1) My laptop
2) Wireless
2.1)HOTEL wireless
3) VPN (IPSec w/ 50% packet overhead!)
4) An international link
5) VoIP into a conference call
By all rights, the quality should have been awful. I mean, it had every right to be...
Now, we have VoIP at home too -- Vonage, to be specific. Our Vonage link runs over an 1.5mbit SDSL line provided by Speakeasy/COVAD, is QoS'd at our firewall, and connects directly to our home telephone wiring.
The quality on the international, wireless, IPSec'd, laptop'd conference call through my Avaya softphone exceeded what I was used to from our home VoIP provider. It was basically landline equivalent -- yes, it was even better than my cell phone.
I was _shocked_. I remember PowWow, FreeSpeak, and all those other systems that ran VoIP over Modem lines. In what alternate universe did VoIP become a quality leader under difficult network conditions?
Turns out that implementation matters. I went and harassed some of the people who worked on the phone equipment (heh Brian) and asked how this system could possibly be working at all. Apparently Avaya got a bunch of the people from Bell Labs (it came from Lucent, which came from AT&T, which itself came from Ma Bell), so there was all this knowledge lying around already in how to manage reliable communications like lives depended on it. The big things being used were:
1) Error Concealment
2) Dynamic Jitter Buffers
Error concealment is simple -- there's necessarily 50 packets per second on a 20ms-latency link (1000ms / 50 packets per second = 20ms of audio per packet), and speech is massively redundant. So rather than simply dropping out when packets were missing, the voice client was "filling in the gaps" with neighboring content. Since the overall frequency profile was kept relatively consistent, short term drops were kept outside the range of human perception. Neat -- obvious, and not entirely unique to this particularly implementation (there's direct support for concealment in some of the G.72x codecs), but neat.
The dynamic jitter buffers are cooler. The basic idea here is that some links are high quality and others are less so, and sometimes the quality of the link will change in the middle of a call. As a response, the Avaya architecture will negotiate a longer buffer for packets to be stored before they're output to the listener to be heard. This buffer starts at ~10ms and can scale up to ~300ms -- distracting, but users have been accustomed to higher latency through their love of cell phones (sad, but true). The key is that the human auditory system can't easily detect speed changes at subsecond resolutions, so you simply execute a non-pitch-shifting slowdown of output speech over a second or two and now you've got a jitter buffer far more tolerant of inclement network conditions. Mind you, this is an absolute nightmare for automated testing equipment, which expects time to be constant, but it's great for everything else -- even TTY's! You'd think a 150bps modem could travel over any link, but apparently not...
Anyway, we keep hearing about how Motorola and Avaya are putting out some kind of VoIP phone, so I'm actually pretty hopeful that we'll see a GOOD VoIP/WiFi solution sometime in my lifetime. I can say this much, though -- simply spurting ulaw on the wire and calling it VoIP ain't my idea of a good time.
--Dan
Mike, please email me at dan@doxpara.com. I have a working, uber-efficient implementation (I write Internet-scale scanners) and you deserve as much credit for it as I do.
Really? I'd very much like to see you transfer cash anonymously to someone more than a couple hundred miles away. Flights are audited, roads are bottlenecked, trains require ID, there aren't walkways, etc.
Electronic cash transfers are massively monitored. (It's also rather expensive.)
--Dan
Aha, but I outnitpick you! You see, I specifically wrote that it was easier to drop a letter on the floor, due to its mass -- not that it was impossible to drop a photon.
And objects have mass, not weight. Weight is an environmental factor, not an inherent one. Various environments will imbue a different weight upon an object, but its mass is an inherent part of its nature. It is this mass that is attracted to the prototypical floor with The Earth below it.
Black holes, by contrast, don't have floors.
--Dan
Hmmm. Really? The majority of spamdrops throwing traffic my way have proxy ports open on 1080?
If every book at Barnes and Noble suddenly has sheets of paper advertising Borders thrown inside, I promise you that Borders would be investigated.
Spam is not prosecuted because there's alot of fear regarding regulating the Internet -- justified, perhaps, but problematic in this instance. We can't solve this problem no matter how we innovate, because we built a network where it's not solvable. But the financial and criminal investigatory systems can help.
I'm telling you, this isn't a technically solvable problem. Your approach -- open proxy scanning -- utterly fails against botnets, which (as the story describes) are becoming _the_ source of spam. But no matter what is tried, most spammers want money from 0.01% of customers (not the stock spammers, but they're in a different category). Follow the money and investigate the subject. A couple people will get framed, but a couple people are always framed. Prosecute the obviously guilty and help solve the problem.
--Dan
Spam is all about mass market.
Mass market totally lacks any mechanism for avoiding easy to track, long distance transactions (cash doesn't work over distance).
People are actually receiving these penis enlargement pills...I mean, they're filled with dust, but they arrive.
--Dan
Step Two: Follow the money.
Step Three: Follow the money.
Step Four: Take a wild guess.
I'm just going to keep on saying this, year after year, as it becomes more and more clear that those engaging in spam are operating outrageously criminal enterprises: If you want to stop spam, FOLLOW THE MONEY.
Find some Viagra spam. Buy some Viagra. Trace the shipment to you, trace the cash transfer from you, arrest. It's not that hard. It's just not very geeky. People, there's no magic technical solution to this -- there's increasingly illegal stunts being pulled, and the only people out there with the IP-layer mechanisms for tracing the attackers really can't afford to release that data as it would compromise rather more important investigations. But -- we've got a very mature infrastructure for tracing financial and mail fraud. We just need the political will to use it against Spam.
It's just not that hard.
--Dan
Snail mail just can't drop packets on the floor as easily...
;-)
Quite the contrary; it's far easier to drop a letter on the floor. A letter has mass.
Well, with large chunks of printer control living in the driver, you can at least do everything from Photoshop and do it inside the printer driver. Of course, this makes it rather problematic to print from Linux or any other uncontrolled OS.
Now that you make me think about it, printers don't store a full image in RAM -- they stream their actions from the upstream driver. To be barriers to printing, they'd have to have _alot_ more memory, or receive their data in some semi-low resolution full page view...ack.
But smart cards aren't cash. Dude, credit and debit cards have won for retailer microtransactions. I have literally hundreds of $5 purchases with my credit card in the past year. Whatever the cost is, it's low enough now.
But I can't give five bucks to my roommate with a credit card, a smart card, or anything else -- except maybe a check. Cash is critical for large portions of society. Are you aware that there are large neighborhoods with no banks, just check cashing services?
--Dan
In order to win your point, you'd have to successfully argue that the flexible nature of web programming has not directly enabled previously scarce or unknown forms or modalities of speech. Given the massive political will that discussion blogs are expressing at the present time -- from FreeRepublic to Daily Kos -- that argument is not likely to succeed.
You're right -- science still works via written journals. If I had to write to you via a journal, I would not write to you, and more importantly, literally could not write this specific message to you. Ergo, speech suppressed via infrastructure.
--Dan
You realize the first amendment specifically protects assembly too, right? Banning the technological means of assembling for discussion would get laughed out of court.
The more we discuss, the weaker your case gets, as the more impossible this discussion becomes without dynamic code. It's that simple.
Sure, not by US Supreme Court, but certainly by US Federal Court:
http://laws.lp.findlaw.com/2nd/009185.html
===
Communication does not lose constitutional protection as "speech" simply because it is expressed in the language of computer code. Mathematical formulae and musical scores are written in "code," i.e., symbolic notations not comprehensible to the uninitiated, and yet both are covered by the First Amendment. If someone chose to write a novel entirely in computer object code by using strings of 1's and 0's for each letter of each word, the resulting work would be no different for constitutional purposes than if it had been written in English. The "object code" version would be incomprehensible to readers outside the programming community (and tedious to read even for most within the community), but it would be no more incomprehensible than a work written in Sanskrit for those unversed in that language. The undisputed evidence reveals that even pure object code can be, and often is, read and understood by experienced programmers. And source code (in any of its various levels of complexity) can be read by many more. See Universal I, 111 F. Supp. 2d at 326. Ultimately, however, the ease with which a work is comprehended is irrelevant to the constitutional inquiry. If computer code is distinguishable from conventional speech for First Amendment purposes, it is not because it is written in an obscure language. See Junger v. Daley, 209 F.3d 481, 484 (6th Cir. 2000).
===
And I do believe the Norwegian Supreme Court ruled similarly in favor of DVD-Jon.
While we're on the subject, it's supremely ironic that you're telling me that you don't need a programming language to publish ideas on the web, via a web form dependent upon Perl! Not to put too fine a point on it, but you required a dynamic web programming language to tell me that you didn't require a dynamic web programming language. I do believe the appropriate response is, "Oops."
--Dan
You're right. Making a scanner is actually not atrociously difficult (photodiodes 'n light, basically), but making a printer of any quality is. Printers will always be the critical line of defense.
--Dan
Ha. Right. PHP compiles, and can easily manipulate imagery as well (through GD, Imagemagick, etc.) Sure, go ahead and license web programming. Lets see that survive 1st amendment review :-)
--Dan
Ewww. I failed to point out that I performed my tests on Euro notes, is what I meant to say. Anyway, I actually started on the Euro bills, then moved to greenbacks because I could get JPEGs of them easier.
--Dan
My sincerest apologies. I failed to point out that my tests on a wide range of European banknotes as well. I'm not the only one doing this kind of work; see this presentation for details.
--Dan
*laughs*
OK. The last time this came up, it consumed about twelve straight hours of hackery. You can go ahead and play with some of the black boxed code using the demo version of Paint Shop Pro (or the latest Photoshops). Let me tell you: This has nothing to do with the circles. I was actually quite saddened by this fact, as I was planning to print up a "secure t-shirt" that would be unphotographable and unprintable by modern image manipulators. (It'd be a great excuse to talk at Black Hat wearing a T-Shirt *laughs*).
Alas, such adventures were not to be had. Experimenting with copy/paste between an unprotected app and the demo PSP, it quickly became clear that while some old copiers might indeed trigger on the inter-circle distances, counterfeiters now had a vastly more difficult system to fight. What there seems to be is some sort of size and position invariant image fingerprint function, probably wavelet based, that receives the full image after every large scale image transform, executes a fingerprint matching vs. a confidence value, and returns true or false depending on what the confidence threshold is set to. It's not perfect -- Stirmark does seem to cause the algorithm to occasionally stumble, though not consistently (see this gallery for details) -- but it's very good work nonetheless.
Certainly, it does not appear possible to manipulate the watermarking system to create new and unique images that appear, computationally, to still be money. That's a very good thing. And while it's somewhat problematic to have code refusing to obey its controller, the integrity of the financial system really is an important thing. Remember the privacy case for cash -- if paper money becomes something we all distrust, what exactly are we left with? The fault with the RFID approach is that it forces us to carry a reader to validate funds. If we cannot self-validate, we cannot trust (notably, the biggest weakness with the metal strip approach is that we cannot quickly notice that the metal strip has been removed -- the wealth is actually thus represented not by the bill but by an invisible strip of iron and plastic!).
I do not think that image manipulation software is the right place to put this code, specifically because it's too easy to write an image editor from scratch (what are you going to do, ban compilers?). Scanners and printers are however sufficiently single sourced that they're far superior places to trust that anti-counterfeiting logic will be in place. But then, that's just IMHO.
--Dan
WiFi without security "just works".
WiFi with security is a configuration nightmare.
So people keep things "just working". When this becomes a problem, we'll see things change. That's how it actually works in security -- be the problem dozens of open daemons on Unix hosts, canary-less stacks in executable code, or a lack of significant checking for airline contraband, the problem is not addressed until it's exploited. When people start getting hacked through their open wireless, we'll see open wireless shut down. For the moment, they'll worry about real problems, like worms and spyware (aka corporate virii).
Ironically enough, it was bluetooth's security model that made it such a nightmare to work with -- the whole pairing process increased the setup load by several orders of magnitude. They're finally going to fix this with Near Field, but it'll take a while for them to get it out (have they even admitted it's for secure key exchange yet?).
Note, I've never said this is how things should be. Ought is not is.
--Dan
The farther you get from an endpoint, the harder it is to actually reassemble the stream. This is because packets can take multiple routes to their destination -- if not through load balancing, then through asymmetric routes (i.e. the packets from the client to the server are taking a wildly different network route from the path taken from server to client.)
Asymmetric routing always seems to confuse people. It shouldn't -- the traffic on the freeways isn't symmetrical in each direction, and sometimes it makes sense to take one highway to work and another back.
Upshot of all this is that, while all the long haul fiber lines actually are probably tapped by someone or other, it's an enormously tricky problem to integrate the data accurately, and you ultimately still don't get as good results as having a direct feed a hop or two up from the endpoint being monitored.
Now, there have been tools for quite some time to do realtime stream monitoring -- Driftnet is a cheap (and occasionally very scary) one, but there have been solutions floating around the corporate space that basically reassemble a browser screen in realtime. I imagine the gov space has even nicer stuff.
You know, "tcpbust" (a sniffer with integrated safe reassembly, third party cryptographically signed timestamps, and a pony) would probably be a really interesting thing to write...
--Dan
Except that floppies can only store 1.4MB per disc, while there are cameras that will capture more than that per photo. Even if not more, people will down-res their photos so that they can fit more pics per floppy.
Bottom line, he wasn't exactly wrong.
Unless you have family or you're an international-class executive, you have no idea as an American how to dial overseas, because you have almost no need to and it's horrifyingly expensive to do using stock long distance service.
... lets just say the hour-long planning sessions through MCI Neighborhood were a very painful lesson in the above. Unlimited long distance my ass...
I did a press junket around Europe last year
--Dan
Well, to use the scientific term, "it depends". I've been thinking about this (like about ten thousand other crypto people) throughout the day. Certainly, Brumley and Boneh's attack will work (and probably better, because 1/44,100 is microsecond resolution): http://crypto.stanford.edu/~dabo/papers/ssl-timing .pdf
...
We do have more data than just time, too -- we have instruction profiles. If it's possible to absolutely know the input to the RSA signing function, and it's possible to alter that input while still knowing the (probably hashed) result, then you can get a set that looks like:
RSA(Known_Hash_1, Unknown_RSA_Private) = Known_CPU_Profile1
RSA(Known_Hash_2, Unknown_RSA_Private) = Known_CPU_Profile2
RSA(Known_Hash_3, Unknown_RSA_Private) = Known_CPU_Profile3
RSA(Known_Hash_N, Unknown_RSA_Private) = Known_CPU_ProfileN
So you're solving for Unknown_RSA, based on the differentials in CPU profiles. Not trivial, mind you -- but absolutely fascinating.
--Dan
Shamir, once again pointing out something absolutely brilliant and (in retrospect) totally obvious, did forget to include something rather important in his announcement:
The particular pattern of CPU operations executed while an RSA private key is executed varies depending on that RSA private key. Given a rough estimate of the pattern of CPU operations executed, the set of possible RSA private keys is greatly reduced. So it becomes much, much easier -- possibly trivial, particularly if you have a chosen plaintext scenario -- to extract a private key from an otherwise secure system. Consider an e-voting machine with an audio system for handicapped access -- with nothing but a very sensitive microphone in the booth, you might be able to determine the private key used to sign votes (and thus gain the capability to spoof votes elsewhere).
And of course, this would be a very, very successful attack against an RSA private key embedded within a trusted computing environment. Processors -- even those encased in epoxy -- still need power, and variable amounts depending on what they're doing. The brilliance here is that rather than needing some very expensive analog energy drain measurement equipment, you just need a sound card. It's a side channel attack for the masses.
Very very cool work. Wow.
--Dan